Am Dienstag, den 08.05.2007, 13:21 -0500 schrieb Bob Hanson: > Daniel Leidert wrote: > >Am Dienstag, den 08.05.2007, 08:53 -0500 schrieb Bob Hanson:
[snip] > >>la_co_va.po > > > >There is even not a case. > > > Right, not at this point. And I don't even know what "va" means exactly. I guess, Saxon, Bavarian, ... for German. But I never saw it. IMHO there is no need to support it atm. > But if a translation is > of some variant, then it makes sense to recognize that and not just > claim that what was translated was "la". Yes, that's the reason, why the way is la_CO_VA > la_CO > la But the more specific files only contain these translations, that are different from the less specific. [..] > What happens is that if the request is for "de_DE", and de_DE is not > supported, then the algorithm looks for > "de". But if "de" is not found, then it takes the default la_co > translation for that language. So, in this case, let's say > we recognize the German as "de_DE" because that's really what it is. > Then when the request comes for "de_AT", > since we have no "de", we get: > > user> language = "de_AT" > Jmol> language = "de_DE" > > clearly indicating that the language is in German, but not quite what > was requested, as there is no "de_AT". > It's not a big deal to me. If we would prefer: > > user> language = "de_AT" > Jmol> language = "de" Where is the problem to return la_LA if the generic la-Locale was used (see [2]!)? It's far simpler than renaming all files or violating the common standards. I mean, everything you want to solve is, to return an IYO more specific locale info to the user. For this you create problems [1], although you would only need to process the "la" string and manipulate it a bit for the return value. I mean, why? Where is the technical necessity? > I won't complain. I just wanted to make it clear that the Jmol algorithm > doesn't NEED to have a de.po translation > to do its job properly, and leave it to others to decide what they want > to do with this. Well, the idea behind introducing some more standardized way to internationalize Jmol was, to make the life of developers and translators easier. And this happened. It currently has more translations than it had (IIRC) and they are easier to maintain. But ... [snip] > right, so is there also a setting that can tell gettext You don't use the gettext Java classes. You use a self-written GT class, that was derived from some other project and adjusted to work with Jmol. You only use some tools from the gettext suite to handle portable object files and create Java resource bundles. > 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? [1] ... you would create a must to maintain the same translation in two files or more (as more country variants, as more translators to translate the same string). This is a heavy disadvantage and a lot more work for translators. There is currently only one suffering from this issue (the pt_BR translator), but if Jmol ever gets more translations (which I hope; btw: Are it's po files listed in the translation project?), this will become a hell for translators. So no, I highly disagree with your suggestion. > >>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. > > > > > > > That is to say, you think or know that de_AT.po cannot be an extension > of de_DE.po? [2] Yes. de_DE(.po) can be an extension of de(.po). There is e.g. an es.po and an es_ES.po for bazaar. I can see more examples. So I guess (but don't know it for sure) you cannot assume, la = la_LA (this might be the case for German, but it's not a must). Regards, Daniel ------------------------------------------------------------------------- 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
