Apache OpenOffice (AOO) Bugzilla – Issue 15640
Tools/Options/External applications - string not translatable
Last modified: 2004-06-03 09:37:16 UTC
Hi, the strings in officecfg/registry/data/org/openoffice/Office/Common.xcu like "KMail 1.2 or later" can not be translated in localized versions. So even in Czech/German version, we will have the text " or later". This is unfortunate. I suggest to remove the text " or later" and something similar with "(Option 1)". This must be fixed before 1.1RC.
Created attachment 6900 [details] Screenshot of Czech version to show where the problem is
Reassigned to Oliver.
First of all: It is not acceptable that this string cannot be translated! This is a must to fix. Second: I assume that we not only have this problem with this one entry but rather with all of them, right? Thus e.g. "Option" will also not be translated. Third: To do a temporary fix I suggest to replace "KMail 1.2 or later" with "KMail 1.2 - 1.x" Please note that this *must* be temporary and that translating all string is a must for the next possible version!
Yes, this is a must-fix for 1.1. We should solve it temporarily for 1.1, when it is solved in 1.1 we can set the target to 2.0 and solve it properly.
cp->ft: Known issue. All configurations *are* translatable in principle except Common.xcu. Just have a look at iBis-100249 and check with NF about a possible solution.
mh->pavel: please commit the suggested string "KMail 1.2 - 1.x".
Done fo KMail. What should we do with Netscape profiles? There is the string "Option". What about this: --- Common.xcu.~1.12.4.1.~ 2003-06-24 13:27:48.000000000 +0200 +++ Common.xcu 2003-06-24 13:30:09.000000000 +0200 @@ -124,7 +124,7 @@ </node> <node oor:name="ExternalMailer"> <node oor:name="Profiles"> - <node oor:name="Netscape 6.x - 7.0 (Option 1)" oor:op="replace"> + <node oor:name="Netscape 6.x - 7.0 (1)" oor:op="replace"> <node oor:name="FormatStrings"> <prop oor:name="base"> <value>-compose "%s"</value> @@ -166,7 +166,7 @@ </prop> </node> </node> - <node oor:name="Netscape 6.x - 7.0 (Option 2)" oor:op="replace"> + <node oor:name="Netscape 6.x - 7.0 (2)" oor:op="replace"> <node oor:name="FormatStrings"> <prop oor:name="base"> <value>-compose %s</value> @@ -208,7 +208,7 @@ </prop> </node> </node> - <node oor:name="Mozilla 1.x (Option 1)" oor:op="replace"> + <node oor:name="Mozilla 1.x (1)" oor:op="replace"> <node oor:name="FormatStrings"> <prop oor:name="base"> <value>-compose "%s"</value> @@ -250,7 +250,7 @@ </prop> </node> </node> - <node oor:name="Mozilla 1.x (Option 2)" oor:op="replace"> + <node oor:name="Mozilla 1.x (2)" oor:op="replace"> <node oor:name="FormatStrings"> <prop oor:name="base"> <value>-compose %s</value> Why do we have two options for Mozilla and Netscape?
mh->ft: please review
We will live with "Option". Please do not change. Thx.
OK, I will not change it in CVS - I will change it for Czech and Slovak builds. Option is not Czech nor Slovak word! I have notified dev@native-lang to take care about this word properly for 1.1. Changing target to 2.0 to get this fixed properly.
Created attachment 7281 [details] Patch to remove word Option which will be part of Czech and Slovak builds
SBA->NF: As described in IBIS 100249, a final solution to get the content of common.xcu into the "translatable mass" is still needed.
Even if we change the behaviour and enable Common.xcu for localization (which leads to different other issues), entries like the "KMail ..." item will not be localized. This items are simply within the oor:name node, which is not localizable. Entries to be localized have to be reflected to <value xml:lang...>. NF->TPF: We have to discuss how to deal with this issue.
As Nils already mentioned: The originally mentioned string "KMail 1.2 or later" is the value of an oor:name attribute. Such attributes will _never_ be internationalized nor translated as this attributes are used to provide the unique path to an config item. This paths are used by the developers to access the items via code. It's obvious that I18N would be a bad idea here. If strings like "KMail 1.2 or later" will be displayed on the screen (= they need translation) they need to be relocated into a prop element's value. Properies can be translated. I reassign this bug to OBR as he is listed as author for this config items.
Well, all this stuff needs rework anyway - the original spec did not say a word about translatable specifiers. Thomas, what would be an appropriate place for UI strings to live in ?
The specification describing how the "Send as E-mail" configuration will be reworked can be found at http://specs.openoffice.org/appwide/desktop_integration/send_as_email.sxw. The plan is to replace the combo box containing the non-translatable strings by a auto-detection algorithm, which will also fix this issue.
Since the strings in question have been removed entirely, I'll close this bug as WONTFIX.
Closed.