Apache OpenOffice (AOO) Bugzilla – Issue 102816
DialogStrings_xx_XX.default not recognized by OOo as default
Last modified: 2013-02-24 21:00:35 UTC
The dialog strings with default flag, for example, DialogStrings_en_US.default, are not default. In the Basic module, the default is the first language in the list, in fact. For example, when there are English and Russian traslations, the default is Russian. When there are English, Russian and French, the default is French. Check the attachment below on any OOo localization different from Russian and English. Run the macro by going Tools-->Add-Ons-->Issue102817 menu. There are two translations: Russian and English. The English is supposed to be default. However, actually, Russian is default. This is known for sure to affect versions from 3.0.1 to 3.1.0 on Linux and Windows. When there are these translations, the first in the list is default: French, Ukrainian, German, Italian, Spanish, Russian, Belorussian, English. French is default. English is supposed to be the one. French can't be removed in the Basic module of OOo. But if it is removed manually from extension folder, then here is the list of translations: Ukrainian, German, Italian, Spanish, Russian, Belorussian, English. Ukrainian is default, but English is supposed to be default. If Ukrainian is removed, then: German, Italian, Spanish, Russian, Belorussian, English. German is default, but English is supposed to be default.
Created attachment 63014 [details] Test extension with English as default, but actually Russian as default
ab->deye: Sorry, but I cannot reproduce your problem at all. I've tried OOo 3.0, OOo 3.1 (OOO310m11) and DEV300 m45 (re- spectively the corresponding StarOffice versions) and the extension always worked correctly by showing the English texts on an English system (Window). Is there maybe a misunderstanding what the default mechanism means? In the first place it's used to be the source of copy- ing the resource texts if new languages are added. When the dialogs are used at runtime not the default language, but the current system language is used.
This extension looks fine on English and Russian systems, because it has 2 translations in it: English (default) and Russian. Please, try it on French, German, Spanish (or any other locale other than English and Russian), then you can see what is below.If you add a french translation to it, the French translation becomes default (however, in the dialog, English is still marked as default).
Created attachment 63042 [details] French and Spanish systems
BTW, ab wrote: >Is there maybe a misunderstanding what the default mechanism means? In the first place it's used to be the source of copy- ing the resource texts if new languages are added. If you add a new translation to that test extension attached above, for example Italian, a new file named DialogStrings_it_IT.properties is created in the extension folder. However, it does not copy the default language strings to that file. It is only 41 byte and contains only this line: <code># Strings for Dialog Library issue102816</code> and nothig else. However, this is a different issue. BTW, the Italian translation becomes default too. I mean an extension with three translations (Italian, Russian and English) on systems other than Italian, Russian and English, has Italian as a default translation. However, English is marked as default.
Created attachment 63149 [details] For testing on English and Russian systems.
Look at the extension I just attached. You can use it on English and Russian systems. It has Italian and Romanian translation (no English or Russian). Romanian is default: DialogStrings_ro_RO.default . 1. If you open the dialog (Tools->Add-ons->) you see Italian. 2. Even if you assume this DialogStrings_ro_RO.default is only for developers of extensions, try to add new translation to this extension. No strings are copied to the new DialogStrings_xx_XX.properties . If you set Italian as default, then string indeed are copied to the new DialogStrings_xx_XX.properties .
Same as Issue 88470 reported 15 months ago. The default language really displayed is not the designed one. This is a real annoyance for producers of multi-lingual extensions! Please correct the bug.
Can this issue be connected with the difference between small and capital letters in file names for Linux and Windows? It seems that this extension http://www.openoffice.org/nonav/issues/showattachment.cgi/63149/issue102816-1.1.oxt works as expected on Windows (Romanian is default), but not on Linux. On Linux the dialog appears in Italian. Can this be due to DialogStrings_ro_RO.dafault is recognized on Windows and not on Linux because there is a lower case reference to it? However, this issue affect Windows too. This extension http://www.openoffice.org/nonav/issues/showattachment.cgi/53028/MultiPages.oxt ( issue 88470 ) shows French on Linux and Spanish on Windows (with OOO310m11) , but English has the default flag: DialogStrings_en_US.default
Please let us use unambiguous terms. Otherwise the discussion becomes unnecessarily difficult. So let us only name a language the library's "Default language" if the corresponding flag file DialogStrings_xx_XX.default file exists and the language is mar- ked accordingly in the IDE. So if you, deye, write "If you add a french translation to it, the French translation becomes default (however, in the dialog, English is still marked as default)." you mean that French is displayed at runtime although English still is the default lan- guage in the sense of my definition above. Right? And of course you are right: Even in the "Manage User Interface Languages" dialog is described that the default language should be displayed at runtime if none of the languages match with the UI language. I've only focussed on the meaning for extension de- velopers so far. Anyway, I've tried to reproduce this again with a StarOffice dev300 m52 with UI set to German. Using deye's English/Russian extension I got the dialog displayed in English, so no issue. Using deye's Italian/Romanian extension I got the dialog dis- played in Italian, so here finally I can reproduce the problem. But obviously also some random mechanisms are involved here. Concerning the copying problem I still cannot reproduce any- thing. Deye, when you add a language and find no strings co- pied to the new DialogStrings_xx_XX.properties file, did you make sure that the library already has been saved? And are also empty strings shown in the IDE if you select the new language there instead of the Default Language strings? First I will have a look now, why the default language is not used in the Italian/Romanian I can reproduce. STARTED
A fallback to the default language was missing in the StringRe- source implementation in case no match could be found for the current UI language. This was leading to a random behaviour as the language was used that has been found "first" on the disk which is not specified. I want to limit this issue to exactly this problem. So if anyone still has other problems, e.g. when adding a new language, please submit another issue for this. FIXED, -> cws ab74
Thank you! I was going to post you a way to reproduce the issue when strings are not copied when new languages are added. This seems to be the same issue or should this be filed as a separate issue? Is it fixed automatically? Anyway. How to reproduce. ---- [1] Install an extension (attachment below) and make sure displayed language does not match the default language (Italian - marked "default" in IDE). [1a] If displayed language does not match default then this is the case we need. Go to [2]. [1b] If diplayed language match default then in IDE choose another language as default, repack extension and install it. Go to [2]. [2] Go to Basic IDE and add a new language. No strings are copied. You can see it in IDE: &7.D.Label1.Label and &5.D.Title displayed. ---- This issue with strings (different or the same as initial issue?) is reproduced only when displayed language differs from default language (in case [1a]), that is, when for example you on dev300 m52 with UI set to German were using Italian/Romanian extension and got the dialog displayed in Italian. On different systems the order of languages in IDE was different. On two different linux systems the same extension gave different displayed languages.
Created attachment 63651 [details] A new version of extension with more languages to more easily reproduce the issue
ab->deye: Thanks for your detailed description. Indeed this is another bug. It seems to be fixed together with the first one, but only at the first look. I found out that it hasn't been made sure that the default langugage gets loaded from the .pro- perties file before copying the strings for the new locale. In case none of the extension languages matches the Office UI language (first bug scenario) this doesn't occur any more after the first fix because the default language is used as fallback and loaded of course before displaying the dialog or when acti- vating the IDE. But if you run your Italian / Romanian(default) extension on an Italian Office copying the string still fails as the default language hasn't been used/loaded before copying as Italian matches the Office UI language. Probably this pro- blem hasn't been detected before because only few people use a default language that differs from their Office language. I added another fix to force loading the language resources before copying. As this is a small fix and all discussion took place here we don't need another issue for it. So we have sol- ved two serious problems here. Thanks again for your help. :-) -> OOo 3.2
ab->jsk: Please verify A multi lingual instset is available for unxsols4.pro. I have already installed this set and also a master StarOffice m56 as reference. Please contact me, if you want to use these installations.
.
Tested in DEV300m60.
Close