Issue 54721 - Installers for languages not supported by Windows should force startup locale to be in their own language
Summary: Installers for languages not supported by Windows should force startup locale...
Status: ACCEPTED
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: 3.3.0 or older (OOo)
Hardware: All Windows XP
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks: 72107
  Show dependency tree
 
Reported: 2005-09-17 10:05 UTC by lists
Modified: 2019-09-24 23:07 UTC (History)
11 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Draft of System.xcu to force/mock a system languge (2.01 KB, text/xml)
2006-02-01 11:44 UTC, joerg.barfurth
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description lists 2005-09-17 10:05:49 UTC
Languages that are not supported by Windows can not have a native installer in
their own language. To avoid this problem, installers for these languages are
made bi-lingual with English. Installation takes place in English, but User
interface language and CLT language (if necessary) are in the target language.

Nevertheless, the locale choosen by OpenOffice is the locale of the computer in
which the installation is taking place (to simplify). As in our case the target
language is not supported by Windows, the locale chosen by OpenOffice is never
the locale of the user interface, and therefore not the one that the user wants
or needs.

Desired behaviour is that when the language of the OOo interface is not
supported by Windows (as is the case of 15 localisation projects), then the
locale by default should also be the language of the user interface (target
language).

Not having the correct locale for default means that all installations for these
languages need to be reconfigured after installation (and for each new user of a
computer). This not only produces many many hours of extra work, but requires
that installation instruction be given to all those who will perform
installation, as it is not longer just running the installer, it requires that
documentation be distributed with the installer.

Solving this in 2.0 would save hundreds of hours of work for OOo communities in
the 15 countries affected by this problem, and simplify distribution.

For more information, please see Issue 49581 (Khmer installer for Windows does
not install).
Comment 1 pavel 2005-09-17 19:39:28 UTC
javiersola: do I understand that if you have dual language instset, like
en_US-km, it is both installed as en-US and the language *after* the
installation, in the normal run is also English and not the right language (km
in your case)?
Comment 2 lists 2005-09-18 03:17:44 UTC
No, the run is in Khmer, but with en_US locale values (such as number format).
These two correspond to two different variables within OpenOffice (aprox. "user
interface locale" and "locale settings").

More in detail:

Installation of km-en-US is in English, as expected.

When the program is run for the first time, the user interface is already in
Khmer, which is also desirable... and (in our case for being CTL language) the
CTL language is set to Khmer, also good. Nevertheless, the Openoffice locale is
set to en_US, because this is the result of the procedure that decides what
locale the system should run (it looks at the operating system and other things
for that). The result is a mixed system with user interface in Khmer, but with
en_US locale settings.

In order to use OpenOffice in Khmer correctly (i.e. see local language number
formats), the OpenOffice locale needs to be reconfigured to Khmer in Language
Settings->Language. This is a trivial operation for those who know, but it
duplicates the complexity of installation for those who do not.

From an OpenOffice distributor's point of view, installation should produce a
consistent Openoffice, with all three variables (User interface/locale/CTL
language) related to the same locale (Khmer in our case). Now by default I see
Khmer, but numbers and dates are in US format.
Comment 3 pavel 2005-09-18 09:20:35 UTC
javiersola: So what the user has to do to get all in Khmer? Can you please
describe it in terms of English menu items like Tools -> Options -> ...?

If it is so, it is really great disadvantage for multilingual installation sets...
Comment 4 lists 2005-09-18 11:07:54 UTC
The amount of work to be done by the user/installer is ridiculously small:

Tools->Option->Lenguage Setting->Languages

Change the value of "Locale Settings" to your own language.

That's it.

---------

The problem is that each installation CD that you issue has to have a little
piece of paper (people in third world country do not read "readme" notices
inside the CD) that says what you have to do. Copying disks require copying
papers.. which does not happen. You end up with hundreds of people either saying
that OpenOffice does not work or calling for assistance. What we need is a
full-proof system that is 100% in your own locale. This is what you usually have
when Windows is in your own language (i.e. Spanish installation on a Spanish
Locale Windows yields Spanish locale OpenOffice). Our case is one in which the
usual rules for "desired locale" do not apply, so we would like to have one more
rule added, that makes installations for those countries (who need simple
installations most) just as simple: force locale settings to be the same as user
interface locale.


Comment 5 pavel 2005-09-18 12:50:36 UTC
OK, confirmed. This is really problem.

Changing the component to framework.
Comment 6 joerg.barfurth 2005-09-19 10:08:55 UTC
Ah! It wasn't clear in issue 49581 in the end, that the remaining problem is
about the "locale settings" locale.

Some additional information:
- The current behavior that the default document (Western or CJK or CTL) locale
will be set correctly in this scenario, will be gone in OOo 2.0.1 (see issue
32939) :-(

- issue 49581 was about languages not supported by MSI. In those cases the
'single-language' Windows installation sets have to be bilingual and as a result
of that the pre-selection of GUI language needs to be changed to avoid this
accidental 2nd language.

- This issue really is about all kinds of single-language installation sets. In
ordinary multilingual installers or stock language packs - i.e. in truly
multilingual installations - the system locale settings should prevail. 

- This issue occurs for (single-language) installers on all platforms, where the
desired single locale is not supported as 'system locale' by the operating
environment. (I don't know if this happens on platforms or for locales other
than those affected by issue 49581, but it is possible.)

Suggested fix: Use the same mechanism as used in issue 49581 (a special xcu file
packed only for these single-target-language installers) to spoof the desired
system locale. This should be done by adding a xcu file to force the
org.openoffice.System/L10N/Locale key to the desired value. A
oor:finalized="true" attribute would need to be used to make this override the
value read from the system. I can help with creating that file, if needed. 

[If this doesn't work, a Setup_ForceLocale.xcu file could be used to change the
default for org.openoffice.Setup/L10N/ooSetupSystemLocale directly, but I'd
prefer faking the system locale instead.]

Note: The changed 'UILocale' default can be injected the same way. This would
probably be even better than the solution we have for issue 49581 now (which
affects the org.openoffice.Office.Linguistics/General/DefaultUILocale directly.
Comment 7 lists 2005-09-20 06:38:17 UTC
Jörg,

Sorry for not being clear before. 

I have been looking through issue 32939, and I get the impression that it will
only affect document language when the OOo system locale and CTL language are
set to "default". What we are doing here would set these values to the target
language, maintaining the old behaviour. Is this also your appreciation ?

It would be great if you could create the xcu file that you mention below. Any
chance that you would have time to do it for 2.0?

Thanks !



Comment 8 joerg.barfurth 2005-09-20 08:46:53 UTC
This is issue is *not* about setting the (normal/CTL/CJK) document locale. Those
locales aren't preset and that won't change. Doing that directly also would
complicate the implementation, because we would need to preset a different value
based on the script type of languages at build time.

Thus issue 32939 will affect languages not supported by the system, in that the
appropriate document locale won't be set any more (as it is today), because it
can't be the system locale. 

Also see issue 42730, which is another facet of this "preconfigure stuff
according to some locale" area is covered. 

OTOH if the solution I suggested is implemented that should solve this problem
as well: If we spoof the system locale, instead of attempting to provide
defaults for every setting, then the mechanism implemented for issue 32939 will
work again. 

FYI: I won't take ownership of this issue, so it is not up to me to commit to
any target release. If desired I can help creating a suitable System.xcu, but
that is all I can contribute.

Comment 9 lists 2005-09-20 15:55:24 UTC
Jörg,

Spoofing the system locale would create the desired local settings
(UI/Locale/CTKorCJK), and they can always be altered later, if the user wishes
to. I cannot see any problem with that (for these specific languages). 
What we are installing are localised applications, so the user expect it to work
in the local language. 

Can you please create the file?
Comment 10 lists 2006-01-31 03:06:29 UTC
Jörg,

We are doing massive installations and this is really becoming a problem for us.
I know that you are on a different project now, but it would be great if you
could just create the file that we need for doing the spoofing. We could test it
at Pavel's builds.
Comment 11 joerg.barfurth 2006-02-01 11:44:51 UTC
Created attachment 33755 [details]
Draft of System.xcu to force/mock a system languge
Comment 12 joerg.barfurth 2006-02-01 11:52:16 UTC
I have added a draft for how such a file could look like.

It still contains placeholders (${PRODUCTLANGUAGE}) that have to be replaced
when building the installation set.

The file has to be installed 
EITHER
  named System.xcu
  into $office/share/registry/data/org/openoffice/
OR
  named arbitrarily with .xcu extension (e.g. System-ForceDefaultLanguage.xcu)
  into $office/share/registry/modules/org/openoffice/System/ 
  (that directory doesn't exist currently)

A source file could go into officecfg/registry/data/org/openoffice and be named
System.xcu. 

Disclaimer: This is entirely untested.
Comment 13 Olaf Felka 2006-03-07 14:12:40 UTC
@ jb: How to proceed with this issue?
Comment 14 joerg.barfurth 2006-03-07 15:14:03 UTC
I suggest someone from StarOffice finishes this as I have outlined. Ingo, can
you take over here?

If there is any question about the content of the xcu file I am still there to
help, but I don't have the time to run my own CWS for this.

There should be only one such file be installed, patched correctly for the
desired languge. This should use the same mechanism as the existing
Linguistic-ForceDefaultLanguage file. (I think with this new approach that other
file even becomes obsolete).
Comment 15 ingo.schmidt-rosbiegal 2006-03-07 16:33:24 UTC
Someone knowing the configuration should include this file into officecfg. Then
I can prepare the installation sets. 
-> Carsten, can you include this new file into officecfg?
Comment 16 carsten.driesner 2006-03-08 10:09:33 UTC
cd: Accepted. Must be discussed how to "fix" this problem.
Comment 17 carsten.driesner 2006-03-08 12:26:24 UTC
cd: Accepted.
Comment 18 carsten.driesner 2006-05-15 15:30:55 UTC
cd: Due to time limit for OOo 2.0.3 shifted to 2.0.4.
Comment 19 carsten.driesner 2006-07-04 14:01:35 UTC
cd: Set target to OOo 2.x.
Comment 20 Mathias_Bauer 2007-12-04 16:19:38 UTC
according to release status meeting -> target 3.x