From: Bob H. <ha...@st...> - 2007-05-08 19:09:23
|
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")},}; |