Daniel Leidert wrote: >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 >> >> > > > The only advantage I see is that when a user requests French, it would be nice to return for them the country localization that was used in the translation. Or if they request "fr_CA" it would be nice to indicate back that the closest to that -- fr_FR -- was used instead. That's all.
> >>and possibly some only with >> >>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. 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". > > >>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 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" 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. >>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. > > > First, the browser preferences are not used here, as far as I can tell. That is an entirely independent system. It only sends a message to the server as I indicated in a previous email: Accept-Language: es-mx,en-us;q=0.7,en;q=0.3 That's from a log on my own server when I asked for a page using my own browser. It is precisely my preference list in Mozilla, so I think that the browser preference list only serves this purpose. It does not get tapped for java locale(), as used in Jmol. Jmol does not get a list of preferences. We get one setting, and that is it. I think it is coming from the operating system, not the browser. So we only get "pt_BR". If we have pt_BR, we send it. If not, and we have pt, we send that. If not, and we have a default country pt_PT, we do the best we can, send that, and indicate that the request has only been partially fulfilled, hopefully to the user's liking: user> language = "pt_BR" Jmol> language = "pt_PT" I think this is slightly, perhaps not meaningfully, but slightly more informative than: user> language = "pt_BR" Jmol> language = "pt" For example, Sergio would know immediately that it was not Brazilian Portuguese that was in the translation, whereas just getting "pt" might still mean that it is Brazillian Portuguese -- just not indicated as such. He would not know. This way, he knows. >>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. > > > 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? > > >>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? 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
