[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: KDE 3 language codes
From:       Eric Bischoff <e.bischoff () noos ! fr>
Date:       2001-12-03 12:39:15
[Download RAW message or body]

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 ;-).

[prev in list] [next in list] [prev in thread] [next in thread]