Daniel Leidert wrote:
>
>[..]
>
>
>>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]!)?
>
I'm not sure I understand the question here. Do you mean, where is the
problem returning de_DE if de_AT is requested? Apparently, under
standard rules, returning de_DE is not possible if de_AT was requested.
Do you mean, where is the problem returning de if de_AT is requested? If
that is what you mean, then, it isn't a "problem", it's just ambiguous.
user> language = "de_AT"
Jmol> language = "de"
Only tells the user that "some" version of German is implemented. Most users
would assume that means de_DE, which would be a correct assumption.
Jmol's default language is en_US. There is no en_US.po file, of course. Right
now if you request
user> language = "en_UK"
you get:
Jmol> language = "en_US"
I think that's "truth in advertising." But if people think that's too strange,
because it breaks some standard expectations, we can have this read:
Jmol> language = "en"
and leave it to the user to figure out what country the translation relates to.
It really does not matter to me.
>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?
>
>
As I said, it is not necessary to make any changes. I was simply asking
if the standards allowed for de_AT returning de_DE, and the answer I
have gotten is, "No, that's not the way it works. If de_AT is not
available, then de is returned, not de_DE, because de_AT can be derived
from de only, not de_DE. This is no problem.
>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.
>
>
>
what I was referring to was the mechanism by which the .po files are
created and maintained, not how Jmol accesses them. We can do anything
we want in terms of Jmol accessing these files in any order we wish. GT
is now set to properly recurse the .po files in the proper order --
la_co_va, then la_co, then la.
>>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.
>
>
It wasn't a suggestion. It was a question as to whether there was a
setting in the programs that create the .po files that allows for one
specific country to be considered the "primary" language file from which
others are derived. From what people are saying, the answer to that
question is, "No, all la_XX.po files are derivatives of la.po files."
That's fine. I was just wondering. Jmol supports this just fine.
>>>
>>>
>>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).
>
>
>
Exactly my point -- you can't assume it. So I was hoping we could be
explicit about that, but I guess not.
As I said, it doesn't matter to me.... The GT class is all set for any
translations we want to have.
So, to be clear -- correct me if I am wrong:
1) All language translations must involve at least one la.po, la_CO.po,
or la_CO_va file.
2) Files present will be checked in the order (1) la_CO_va.po, (2)
la_CO.po, (3) la.po.
3) When a la_CO.po file is present but la.po is absent, this will not
cause any exception.
4) If, for some reason, la_CO.po is present and la.po is absent (perhaps
you say that is impossible), if a user requests a country for a language
that is not supported -- en_AU, perhaps -- then Jmol will provide a
"default" country translation, in this case en_US. (I know, there isn't
an en_US.po file, but that's only because en_US is the default language
for Jmol.)
5) All files available will be identified in the GT class. This is to
properly populate the language submenu.
(5) is new. We now have in GT:
languageList = new String[][] {
{"ca", GT._("Catalan")},
{"cs", GT._("Czech")},
{"nl", GT._("Dutch")},
{"en_US", GT._("English")},
{"et", GT._("Estonian")},
{"fr", GT._("French")},
{"de", GT._("German")},
{"pt_BR", GT._("Portuguese - Brazil")},
{"pt", GT._("Portuguese")},
{"es", GT._("Spanish")},
{"tr", GT._("Turkish")},};
Previously the only place the languages were listed was in build-i18n.xml:
<property name="all.Jmol.languages"
value="ca,cs,de,es,et,fr,nl,pt,pt_BR,tr" />
<property name="all.JmolApplet.languages"
value="ca,cs,de,es,et,fr,nl,pt,pt_BR,tr" />
This is a bit of a nuisance, having these listed twice, but it is
important that it be done this way. If you look there you see that
GT._() is being used to flag those language names themselves for
translation. So unless there is something I'm missing, that has to
remain in the class code, not a property file in order for xgettext to
find them and supply them to the .pot files. So maybe this is just the
way it needs to be. Probably the smart thing to do is make clear
comments in both files that indicates that if you change one you must
change the other as well.
One possibility is that we do something like this:
languageList = new String[][] {
{"ca", GT._("Catalan")},
{"cs", GT._("Czech")},
{"nl", GT._("Dutch")},
{"en", GT._("English - USA")},
{"et", GT._("Estonian")},
{"fr", GT._("French")},
{"de", GT._("German")},
{"pt_BR", GT._("Portuguese - Brazil")},
{"pt", GT._("Portuguese - Portugal")},
{"es", GT._("Spanish")},
{"tr", GT._("Turkish")},};
I think it pays to discuss this now before we go too far. I don't like
the idea of changing what is inside GT._() unless absolutely necessary.
So agreeing on this now would be a good thing. What makes sense to me is
to identify the country now so that later, if different countries are
added, we don't have to go back and change, for example,
GT._("Portuguese") to GT._("Portuguese - Portugal"). Looks like we
can't do that in the .po file, and that's perfectly fine by me. But we
might consider doing it on the menus.
Bob
-------------------------------------------------------------------------
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
