Re: [Jmol-developers] [Jmol-users] pt-br translation

[Daniel L. <dan...@gm...>]

CCed you, because sf.net still has problems with my mail

Am Dienstag, den 08.05.2007, 08:53 -0500 schrieb Bob Hanson: 
> Nico, I just checked in some changes for GT. There was a bug there will 
> cause an exception if the default language includes a variant or if the 
> user specifies a variant.
> 
> In addition, The coding changes I introduced makes it possible to have 
> all po files in the form
> 
> la_co.po

Why? Where is the advantage IYO? There are further currently 8
translations with a generic language code and only one case with a
variant.

> and possibly some only with
> 
> la_co_va.po

There is even not a case.

> The code I just introduced makes it unnecessary for us to have any po 
> files of the form:
> 
> la.po

How do you want to handle browsers sending, e.g.

de_AT, en_US

as language code, when you only have de_DE?

> What I was thinking is that the base language translation could identify 
> the country of origin.

Hm. I think this violates users setting. Say, someone has set the
following locale in his browser: pt_BR, en_US and we only have pt_PT.
Where do you know, that the user wants to see pt_PT in this case and not
en_US, as defined in his browser preferences. If he want's to see it, he
would have added pt or pt_PT at least to his language code preferences.

> If the programs that compile .po files cannot 
> support the idea that pt_BR.po derives from pt_PT.po,

gettext supports this (not sure about the gettext Java classes - but I
guess, they do too). Only the GT class probably doesn't. The idea behind
having e.g. de.po and de_AT.po is, that the variant file de_AT.po only
contains the translations that are different from the one in the generic
de.po. So the translating class/function should get the string from the
right resource. Say e.g. the official program contains the string
"January" and "February". Then de.po would contain "Januar" and
"Februar" and the de_AT.po would contain "Jaenner" but no translation
for February. So a user with a de_AT would see "Jaenner" and "Februar",
whereas the user with a de_DE locale would see "Januar" and "Februar".
So normally the pt_BR.po variant file should contain only these strings,
that are different from the pt.po file.

(AFAIK how it should work using gettext library)

> then I think I can 
> add a bit of code to get around that. What do you think?

I don't feel confident with your suggestion atm. I violates the common
usage of po files.

Regards, Daniel