From kde-i18n-doc Mon Dec 03 12:39:15 2001 From: Eric Bischoff Date: Mon, 03 Dec 2001 12:39:15 +0000 To: kde-i18n-doc Subject: Re: KDE 3 language codes X-MARC-Message: https://marc.info/?l=kde-i18n-doc&m=100738355206461 Le Vendredi 30 Novembre 2001 17:56, Frederik Fouvry a écrit : > Hi, > > Browsing through the list archive I noticed the thread on the > language codes. Here's my view: (a few can probably guess what's > coming now ;-) > > I am all for sticking to the RFC (which is also a BCP - Best > Current Practice, forgot the number). Whatever solution we choose - we must take a decision quite soon. Currently, we do not conform neither to the RFC nor to ISO-639-2, and I would call the current situation "a mess" ;-). In kde-i18n and koffice-i18n packages, we already moved some old languages to ISO 639-2 or added new languages as ISO-639-2. Examples are "ind" (Indonesian, ISO-639-2) instead of "id" (ISO-639-1) or "ara" (Arabic). If we want to stick to the RFC, we must revert these changes. If we want to stick to ISO-639-2, we must do the same changes for the remaining languages. In both case, we must remove the encoding ("Big5" or "GB2312") from the name of the Chinese variants since it's now pure UTF-8. Now about the choice in itself: I am personally in favour of sticking completly to ISO-639-2 at internal KDE level, for sake of simplicity, given that we already use codes independant from the rest of Linux applications and that the mechanisms to do that already exist. We even already used them at DocBook style sheets level if you remember, Frederik. I find the idea of "ISO-639-2 gives the codes but doesn't say you must use them, the RFC says that the codes exist but that no one should use them" rather schyzophrenic. I'm happy no one attempted to make such reasonings when we decided to move to unicode, otherwise we would still mix ISO-639-15 for French and Big5 for traditional Chinese and say that "unicode exists but no one should use it, we should stick to the old code pages". Frederik also says that the RFC provides no hardwired mechanism for distinguishing "pt_BR" from "pt" or "zh_CN" from "zh_TW", and that this distinction should be based on a fallback mechanism. I think this is another excellent reason for not sticking to this braindead RFC ;-). "zh_CN" is _not_ a fallback of "zh_TW", nor the contrary, and I don't want to start a war in the Formose detroit for having assumed that ;-).