Kaixo! On Wed, Sep 08, 2004 at 04:43:19PM +0200, Danilo Šegan wrote: > OTOH, Metin doesn't seem too fond of the idea of renaming all the > files for the locale, and I don't see a good reason to do this now, > unless we go for it for all the locales. The reason is that "az" and "az_IR" are not compatible (they use different writting systems; and probably the average speaker is not able to easily read the other writting). If a string is translated in an "az.po" file, and not in the "az_IN.po" one, then Azeri language users in arabic script will still see the translation in Azeri in latin script. In the case of "pt/pt_BR" (or en/en_GB/en_AU, etc) they are compatible. In the case of sr/sr Latn, etc. all users of the language are expected to be able to easily be able to read on the different writting systems, if needed. having az_AZ and az_IR ensures that there won't be fallback to another writting systems (unless the user so chooses, with LANGUAGE=az_IR:az_AZ for example). On the other hand, it is a lot of files to rename. >> We should be general when a team is started (Iranian Persian is readable >> to Afghan speakers, so we only have one "fa" team for now) but fix >> mistakes later (current Persian files should be renamed to "fa_IR" and a >> new "fa_AF" created when volunteers are found and the vocabulary is >> proved to be non-unifiable). > > Yeah, "we should", but it doesn't seem we are. After all, we have > Spanish as "es", Portuguese as "pt", French as "fr", etc. Yes, these > are slightly different from "az" case, since they at least use the > same script, and are probably *at least a bit* comprehensible to > everyone expecting those languages. That's not "slightly different" but a HUGE difference. And the problem is that the fallback is hardwired in libc mechanism (LANGUAGE="az_IN:C" will still found az.po translations if az_IN are missing...) > Still, we cannot expect all of us to be language experts for all > languages in the world, so perhaps first-come-first-served basis is > good enough here (at least it's non-discriminative: "we don't know if > it's best choice, but since no one has asked for it before, you may > have it"). > > Of course, if we had sufficient input on this when "az" team was > *started*, perhaps we should have acted differently. Alas, we didn't, > so I see no reason in forcing a switch now (anymore than we're going > to force "pt" to become "pt_PT", or "fr" to become "fr_FR"). I think the case is different here. Nobody will as to rename "pt" and "fr" etc; as people expect to have those fallbacks (so that they can define "LANGUAGE=fr_BE" and it still works, for example). But here, keeping "az" will actually be discriminating for people using arabic script, as that will force them, in some cases, to read in latin script. Now, the question is, would "az_IN" users be ok with such fallback? (that is, if no translation in arabic scritp exists, but an Azeri translation in latin script do exist, is it better than plain English?) If it is ok, then there is no need to change anything; however if that is not ok, there may be a problem. Note: there are various other languages that may go into similar problems; Kurdish is one, for which there start to be translations. For OpenOffice.org, they settled to use ku_TR for latin script and ku_IQ for arabic script. -- Ki ça vos våye bén, Pablo Saratxaga http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Catalan or Esperanto] [min povas skribi en valona, esperanta, angla aux latinidaj lingvoj]
Attachment:
pgpczH8Omt8YF.pgp
Description: PGP signature