Nicolas Vervelle wrote:
> Bob Hanson wrote:
>
>>right, so is there also a setting that can tell gettext that de_AT.po is
>>not an extension of de.po in this case,
>>but instead an extension of de_DE.po? I could imagine it being set up
>>either way. Either:
>>
>>de_DE.po
>>de_AT.po
>>
>>are always independent and derived mutually from de.po, or there is a
>>setting that one can use
>>to indicate that de_AT.po is derived from de_DE.po.
>>
>>Anyone know?
>>
>>
> gettext is working the same way as Java resources do : de_AT.po is an
> extension of de.po, not of de_DE.po.
> That's the established standard way of working with Locale, that's why
> your proposition is disturbing Daniel (and me also a little).
>
Not a problem. if gettext doesn't allow for it, then that's all there is
to it.
> I don't see what happens in your description if de_AT.po is not
> complete: do we have the translation from de_DE.po for the missing
> translations ?
> What happens if we have 3 countries for the same language ?
It's a moot point if gettext doesn't allow for it. What happens right
now in Jmol is that if you had just:
pt_CS.po
pt_BR.po
pt_PT.po
but no pt.po, then Jmol would be OK with that and use pt_PT as the
"base" class for both pt_BR and pt_CS. If a user requests "pt",
Jmol would return "pt_PT"; if the user requested "pt_BR", then Jmol
would return "pt_BR" and access pt_BR.po first ,and pt_PT.po second.
Listen, it doesn't matter. We can keep on calling the base class just
xx.po. That's fine.
The only reason I thought of it was that there was the question about
who wrote the pt.po translation, whether it was associated with Portugal
or Brazil, and I thought it might be nice to make it explicit. Thus the
idea that there be "pt_PT.po" and "pt_BR.po" but no "pt.po".
Personally, I think it's awkward for a translator to "claim" a base
language without qualifications. Which should be "en" -- "en_UK" or
"en_US"? Right now "en" means "en_US". Why not say so? That's my point.
Then, rather than complaining that "en" isn't proper English, someone
might think, "Well, they have en_US -- I'd like to write an en_UK
version of that." And we would have a new translation.
Provided that is the case -- that you MUST have xx.po as a base for
xx_co.po -- I'd like still to make it clear to Jmol users what the
implicit base country is. France for French, US for English, etc. We can
still do that without any regard to files -- I would just set it up so
that one particular code is flagged as the base class, and although it
would appear on the menu as, say, "Spanish -- Spain (es_ES)", the file
accessed would still be "es.po".
Here's what I'd like to know: What are the assumed country codes for the
following, if there is such?
{"ca", GT._("Catalan")},
{"cs", GT._("Czech")},
{"nl", GT._("Dutch")},
{"et", GT._("Estonian")},
{"fr", GT._("French")},
{"de", GT._("German")},
{"pt", GT._("Portuguese")},
{"es", GT._("Spanish")},
{"tr", GT._("Turkish")},};
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
