You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by janI <ja...@apache.org> on 2013/02/16 10:26:49 UTC
[discussion/vote] non-translated text in resource files.
Hi.
While I am testing genLang, I stumple across a number of texts in the
resource files, which seems strange. It is not a huge number (at the moment
about 10 entries), but I think it should be corrected.
The patterns I see are as follows (example from .src files):
1) Text "xyz" <- [ en-US ] missing, not extracted to current sdf file
2) Text [ de ] "xyz" <- followed by a [ en-US ] entry, making it
impossible to translate (the translated entry is duplicate and removed)
3) Text [ en-US ] "xyz" duplicated within a control
I propose that I change/commit these entries when I find them (commits will
be commented)
However doing so, means that translations need to be changed (new entries,
or in case with "de", missing entries).
It also means that the User Interface for these texts changes in the
international versions (local language, instead of en-US), which breaks
compatibility.
Due to the current debate on compatibility and changing other peoples code,
I want to be sure that the community is behind this suggested change before
I go ahead and do it.
If there is a reason for especially the non-translated entries, please help
me understand the reason.
Rgds
jan I
Re: [discussion/vote] non-translated text in resource files.
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Sat, Feb 16, 2013 at 08:35:20AM -0300, Ariel Constenla-Haile wrote:
> In short, when you find a string without language, and you think it must
> be marked as translatable, you should do some research in the source
> code, otherwise it will end up breaking stuff (like in the OO Math
> example).
This example is also rather illustrative:
https://issues.apache.org/ooo/show_bug.cgi?id=120341
http://svn.apache.org/viewvc?view=revision&revision=1364473
http://svn.apache.org/viewvc/incubator/ooo/trunk/main/sc/source/ui/src/scstring.src?r1=1364473&r2=1364472&pathrev=1364473
String SCSTR_FIELDSEP should not be translated, that's why it has no
[en-US].
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: [discussion/vote] non-translated text in resource files.
Posted by Andre Fischer <aw...@gmail.com>.
On 16.02.2013 18:38, janI wrote:
> On 16 February 2013 12:35, Ariel Constenla-Haile <ar...@apache.org> wrote:
>
>> On Sat, Feb 16, 2013 at 12:09:41PM +0100, janI wrote:
>>> On Feb 16, 2013 11:59 AM, "Ariel Constenla-Haile" <ar...@apache.org>
>>> wrote:
>>>> On Sat, Feb 16, 2013 at 10:26:49AM +0100, janI wrote:
>>>>> 1) Text "xyz" <- [ en-US ] missing, not extracted to current sdf
>> file
>>>> I don't get what you find wrong with these strings without [en-US], nor
>>>> what you are trying to do with them.
>>> see the examples I posted please. I think they should be translated, and
>>> they are currently not extracted to the sdf file. because of the missing
>>> en-US.
>> In general, you are wrong: a string that has no language is marked by
>> the developer as *not* translatable, so you shouldn't add an [en-US]; of
>> course, there might be rare cases where the missing default language is
>> an error, but I guess that in most cases, this is the desired effect.
>>
>> Examples:
>>
>> All Math commands in
>>
>> http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/starmath/source/commands.src#31
>>
>> The first set of strings without language should not be translated.
>> Adding [en-US] would be a mistake: these are the internal Math commands,
>> a single change in the string will make OO Math not work!
>>
>> The context menu defined in
>>
>> http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/starmath/source/commands.src#228
>> follows the same principle:
>>
>> - strings not supposed to be localized, don't have [en-US]
>> - strings that should be localized, have [en-US]
>>
>> Example:
>> Text [ en-US ] = "~Set Operations" ;
>> but
>> Text = "a in A";
>> shouldn't be translated, even if "in" is an English term.
>>
>> Another example I know (I wrote this):
>>
>> http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/cui/source/dialogs/about.src#69
>>
>> Text = "http://www.openoffice.org/welcome/credits.html";
>>
>> I don't want this string to be translated, that's why it has no [en-US];
>> that page is not localized.
>>
>> I would have marked this link as translatable, if the contributors page
>> had been localized, for example:
>>
>> en: http://www.openoffice.org/welcome/credits.html
>> es: http://www.openoffice.org/es/creditos.html
>> fr: http://www.openoffice.org/fr/credits.html
>>
>>
>> The same applies for strings in configuration files: if a prop is of
>> type "xs:string", the value can be marked as translatable or not
>> translatable:
>>
>> <value xml:lang="en-US"> marks the string as translatable
>>
>> <value> marks the string to be not translatable.
>>
>>
>> In short, when you find a string without language, and you think it must
>> be marked as translatable, you should do some research in the source
>> code, otherwise it will end up breaking stuff (like in the OO Math
>> example).
>>
>> thanks for your as usual very comprensive answer. If I may give you a
> merit, you are the one who have helped me the most understand how aoo works
> internally.
>
> I will use your guidiance, as you write but I must admit I do not
> understand the following:
>
> String RID_STR_ACC_ACTION_SELECT
> {
> Text = "select";
> };
>
> String RID_STR_ACC_NAME_BROWSEBUTTON
> {
> Text [ en-US ] = "Browse";
> };
>
> From accibility, why is "browse" to be translated and "select" not, that
> does not seem correct ?
I did not look into the code but from the name and values of the strings
I would say that the difference is how an AT (assistive technology) tool
(like screen reader or braille terminal) handles the strings.
RID_STR_ACC_NAME_BROWSEBUTTON is probably the name of a button and
visible on the screen. The AT tool will read it to the user unmodified.
RID_STR_ACC_ACTION_SELECT is an action name, an "internal" value that is
interpreted by the AT tool. It has to be machine readable, so to say,
and therefore must not be translated.
-Andre
>
> your examples are quite correct, and I would have no doubt there.
>
> have a nice weekend.
> Jan I
>
>
>> Regards
>> --
>> Ariel Constenla-Haile
>> La Plata, Argentina
>>
Re: [discussion/vote] non-translated text in resource files.
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Sat, Feb 16, 2013 at 06:38:55PM +0100, janI wrote:
> I will use your guidiance, as you write but I must admit I do not
> understand the following:
>
> String RID_STR_ACC_ACTION_SELECT
> {
> Text = "select";
> };
>
> String RID_STR_ACC_NAME_BROWSEBUTTON
> {
> Text [ en-US ] = "Browse";
> };
>
> From accibility, why is "browse" to be translated and "select" not, that
> does not seem correct ?
Searching in OpenGrok, it seems the strings used for getAccessibleName()
are localized, the ones used for getAccessibleActionDescription() are
not translatable. But I have no idea why. You should ask Steve Yin, he
is the accessibility master.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: [discussion/vote] non-translated text in resource files.
Posted by janI <ja...@apache.org>.
On 16 February 2013 12:35, Ariel Constenla-Haile <ar...@apache.org> wrote:
> On Sat, Feb 16, 2013 at 12:09:41PM +0100, janI wrote:
> > On Feb 16, 2013 11:59 AM, "Ariel Constenla-Haile" <ar...@apache.org>
> > wrote:
> > >
> > > On Sat, Feb 16, 2013 at 10:26:49AM +0100, janI wrote:
> > > > 1) Text "xyz" <- [ en-US ] missing, not extracted to current sdf
> file
> > >
> > > I don't get what you find wrong with these strings without [en-US], nor
> > > what you are trying to do with them.
> >
> > see the examples I posted please. I think they should be translated, and
> > they are currently not extracted to the sdf file. because of the missing
> > en-US.
>
> In general, you are wrong: a string that has no language is marked by
> the developer as *not* translatable, so you shouldn't add an [en-US]; of
> course, there might be rare cases where the missing default language is
> an error, but I guess that in most cases, this is the desired effect.
>
> Examples:
>
> All Math commands in
>
> http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/starmath/source/commands.src#31
>
> The first set of strings without language should not be translated.
> Adding [en-US] would be a mistake: these are the internal Math commands,
> a single change in the string will make OO Math not work!
>
> The context menu defined in
>
> http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/starmath/source/commands.src#228
> follows the same principle:
>
> - strings not supposed to be localized, don't have [en-US]
> - strings that should be localized, have [en-US]
>
> Example:
> Text [ en-US ] = "~Set Operations" ;
> but
> Text = "a in A";
> shouldn't be translated, even if "in" is an English term.
>
> Another example I know (I wrote this):
>
> http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/cui/source/dialogs/about.src#69
>
> Text = "http://www.openoffice.org/welcome/credits.html";
>
> I don't want this string to be translated, that's why it has no [en-US];
> that page is not localized.
>
> I would have marked this link as translatable, if the contributors page
> had been localized, for example:
>
> en: http://www.openoffice.org/welcome/credits.html
> es: http://www.openoffice.org/es/creditos.html
> fr: http://www.openoffice.org/fr/credits.html
>
>
> The same applies for strings in configuration files: if a prop is of
> type "xs:string", the value can be marked as translatable or not
> translatable:
>
> <value xml:lang="en-US"> marks the string as translatable
>
> <value> marks the string to be not translatable.
>
>
> In short, when you find a string without language, and you think it must
> be marked as translatable, you should do some research in the source
> code, otherwise it will end up breaking stuff (like in the OO Math
> example).
>
> thanks for your as usual very comprensive answer. If I may give you a
merit, you are the one who have helped me the most understand how aoo works
internally.
I will use your guidiance, as you write but I must admit I do not
understand the following:
String RID_STR_ACC_ACTION_SELECT
{
Text = "select";
};
String RID_STR_ACC_NAME_BROWSEBUTTON
{
Text [ en-US ] = "Browse";
};
>From accibility, why is "browse" to be translated and "select" not, that
does not seem correct ?
your examples are quite correct, and I would have no doubt there.
have a nice weekend.
Jan I
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
>
Re: [discussion/vote] non-translated text in resource files.
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Sat, Feb 16, 2013 at 12:09:41PM +0100, janI wrote:
> On Feb 16, 2013 11:59 AM, "Ariel Constenla-Haile" <ar...@apache.org>
> wrote:
> >
> > On Sat, Feb 16, 2013 at 10:26:49AM +0100, janI wrote:
> > > 1) Text "xyz" <- [ en-US ] missing, not extracted to current sdf file
> >
> > I don't get what you find wrong with these strings without [en-US], nor
> > what you are trying to do with them.
>
> see the examples I posted please. I think they should be translated, and
> they are currently not extracted to the sdf file. because of the missing
> en-US.
In general, you are wrong: a string that has no language is marked by
the developer as *not* translatable, so you shouldn't add an [en-US]; of
course, there might be rare cases where the missing default language is
an error, but I guess that in most cases, this is the desired effect.
Examples:
All Math commands in
http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/starmath/source/commands.src#31
The first set of strings without language should not be translated.
Adding [en-US] would be a mistake: these are the internal Math commands,
a single change in the string will make OO Math not work!
The context menu defined in
http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/starmath/source/commands.src#228
follows the same principle:
- strings not supposed to be localized, don't have [en-US]
- strings that should be localized, have [en-US]
Example:
Text [ en-US ] = "~Set Operations" ;
but
Text = "a in A";
shouldn't be translated, even if "in" is an English term.
Another example I know (I wrote this):
http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/cui/source/dialogs/about.src#69
Text = "http://www.openoffice.org/welcome/credits.html";
I don't want this string to be translated, that's why it has no [en-US];
that page is not localized.
I would have marked this link as translatable, if the contributors page
had been localized, for example:
en: http://www.openoffice.org/welcome/credits.html
es: http://www.openoffice.org/es/creditos.html
fr: http://www.openoffice.org/fr/credits.html
The same applies for strings in configuration files: if a prop is of
type "xs:string", the value can be marked as translatable or not
translatable:
<value xml:lang="en-US"> marks the string as translatable
<value> marks the string to be not translatable.
In short, when you find a string without language, and you think it must
be marked as translatable, you should do some research in the source
code, otherwise it will end up breaking stuff (like in the OO Math
example).
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: [discussion/vote] non-translated text in resource files.
Posted by janI <ja...@apache.org>.
On Feb 16, 2013 11:59 AM, "Ariel Constenla-Haile" <ar...@apache.org>
wrote:
>
> On Sat, Feb 16, 2013 at 10:26:49AM +0100, janI wrote:
> > 1) Text "xyz" <- [ en-US ] missing, not extracted to current sdf file
>
> I don't get what you find wrong with these strings without [en-US], nor
> what you are trying to do with them.
see the examples I posted please. I think they should be translated, and
they are currently not extracted to the sdf file. because of the missing
en-US.
>
>
> > 2) Text [ de ] "xyz" <- followed by a [ en-US ] entry, making it
> > impossible to translate (the translated entry is duplicate and removed)
>
> All these [de] can be safely removed, AFAIK.
>
> > 3) Text [ en-US ] "xyz" duplicated within a control
>
> the same with this.
>
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
Re: [discussion/vote] non-translated text in resource files.
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Sat, Feb 16, 2013 at 10:26:49AM +0100, janI wrote:
> 1) Text "xyz" <- [ en-US ] missing, not extracted to current sdf file
I don't get what you find wrong with these strings without [en-US], nor
what you are trying to do with them.
> 2) Text [ de ] "xyz" <- followed by a [ en-US ] entry, making it
> impossible to translate (the translated entry is duplicate and removed)
All these [de] can be safely removed, AFAIK.
> 3) Text [ en-US ] "xyz" duplicated within a control
the same with this.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: [discussion/vote] non-translated text in resource files.
Posted by janI <ja...@apache.org>.
On 16 February 2013 10:49, Juergen Schmidt <jo...@gmail.com> wrote:
> Am Samstag, 16. Februar 2013 um 10:26 schrieb janI:
> > Hi.
> >
> > While I am testing genLang, I stumple across a number of texts in the
> > resource files, which seems strange. It is not a huge number (at the
> moment
> > about 10 entries), but I think it should be corrected.
> >
> > The patterns I see are as follows (example from .src files):
> >
> > 1) Text "xyz" <- [ en-US ] missing, not extracted to current sdf file
> > 2) Text [ de ] "xyz" <- followed by a [ en-US ] entry, making it
> > impossible to translate (the translated entry is duplicate and removed)
> > 3) Text [ en-US ] "xyz" duplicated within a control
> >
> > I propose that I change/commit these entries when I find them (commits
> will
> > be commented)
> >
> > However doing so, means that translations need to be changed (new
> entries,
> > or in case with "de", missing entries).
> > It also means that the User Interface for these texts changes in the
> > international versions (local language, instead of en-US), which breaks
> > compatibility.
> >
> > Due to the current debate on compatibility and changing other peoples
> code,
> > I want to be sure that the community is behind this suggested change
> before
> > I go ahead and do it.
> >
> > If there is a reason for especially the non-translated entries, please
> help
> > me understand the reason.
> >
> First of all please don't stress the compatibility issue more than
> necessary. In this longer thread and the story behind came more things
> together which should be addressed in some way.
>
> Your changes would be of completely different nature than incompatible
> changes in documents and related calculations.
>
yes it has nothing to do with documents, but it has a lot to do with the
UI, which seems to be equally touchy
>
> Can you please provide some concrete examples. Have you located the
> strings in the user interface and have you tested exactly what the
> difference is when you change it as proposed?
>
Examples below...bear in mind this is not a complete list, and just for
.src, I have also seen same tendency in .ulf files.
I have tested with the resource compiler:
1) duplicate strings, no problem
2) [ de ] strings, when I simulate a merge from de lang, the translated
strings is not used
3) missing [ en-US ] shows english text in my spanish UI.
accessibility / acccessiblestrings.src
String RID_STR_ACC_ACTION_DECBLOCK
{
Text = "decrementBlock";
};
cui / cfg.src
PageItem
{
Identifier = RID_SVXPAGE_MENUS ;
Text [ de ] = "Menüs" ;
Text [ en-US ] = "Menus" ;
PageResID = 300 ;
};
cui / autocdlg.src
CheckBox CB_AUTOABBREV
{
HelpID = "cui:CheckBox:RID_OFAPAGE_AUTOCORR_EXCEPT:CB_AUTOABBREV";
Pos = MAP_APPFONT ( 137 , 78 ) ;
Size = MAP_APPFONT ( 111 , 10 ) ;
Text [ en-US ] = "~AutoInclude";
Text [ en-US ] = "~AutoInclude" ;
TabStop = TRUE ;
};
>From what I read so far it sounds like a bug and should be fixed as
> proposed but I would like to get more info. Important from my pov is to
> understand it before we change it.
>
which is why I ask. The introduction of genLang calls for some major edits
of the language files because a number of keys change...I will do these
edits so we have all languages at the same level as before the change, but
I want to be 100% that I do the right thing.
Rgds
jan I.
>
> Juergen
Re: [discussion/vote] non-translated text in resource files.
Posted by Juergen Schmidt <jo...@gmail.com>.
Am Samstag, 16. Februar 2013 um 10:26 schrieb janI:
> Hi.
>
> While I am testing genLang, I stumple across a number of texts in the
> resource files, which seems strange. It is not a huge number (at the moment
> about 10 entries), but I think it should be corrected.
>
> The patterns I see are as follows (example from .src files):
>
> 1) Text "xyz" <- [ en-US ] missing, not extracted to current sdf file
> 2) Text [ de ] "xyz" <- followed by a [ en-US ] entry, making it
> impossible to translate (the translated entry is duplicate and removed)
> 3) Text [ en-US ] "xyz" duplicated within a control
>
> I propose that I change/commit these entries when I find them (commits will
> be commented)
>
> However doing so, means that translations need to be changed (new entries,
> or in case with "de", missing entries).
> It also means that the User Interface for these texts changes in the
> international versions (local language, instead of en-US), which breaks
> compatibility.
>
> Due to the current debate on compatibility and changing other peoples code,
> I want to be sure that the community is behind this suggested change before
> I go ahead and do it.
>
> If there is a reason for especially the non-translated entries, please help
> me understand the reason.
>
First of all please don't stress the compatibility issue more than necessary. In this longer thread and the story behind came more things together which should be addressed in some way.
Your changes would be of completely different nature than incompatible changes in documents and related calculations.
Can you please provide some concrete examples. Have you located the strings in the user interface and have you tested exactly what the difference is when you change it as proposed?
>From what I read so far it sounds like a bug and should be fixed as proposed but I would like to get more info. Important from my pov is to understand it before we change it.
Juergen