Marc Waeckerlin
YaST has now a nice feature to specify a primary and a list of secondary languages.
If you install a primary language that is not Chinese or Japanese, but one of the two Chinese or Japanese as secondary language, then CTYPE could be set to that secondary language.
Not a bad idea. But there are some problems. You will get Chinese fonts by default then. For example, xfd -fa sans will default to a Chinese font. In applications which can use only one single font, this will usually have the effect that you don't get German Umlauts anymore, unless your Chinese default font has Umlauts. Applications which are able to use several fonts at once (GTK, Qt, ...) may be able to display the Umlauts correctly. But the Umlauts used may be from a different font than the glyphs used for ASCII (which are from the Chinese default font). This is of course readable but ugly. I.e. if this is a multi user system where you install CJK stuff because some users want to use CJK, you probably do not want to set LC_CTYPE=zh_CN.UTF-8 for all users. In that case, users interested in CJK should set it in their personal ~/.profile.
If in primary and secondary language, there are more than only one of both Chinese and Japanese, YaST could detect an unresolvable conflict, and display an information on this (if there is no solution to this problem).
If the list of languages were an ordered list, like in the KDE control centre where you can add languages to the list or remove them and move languages up and down in the list, there would be no unresolvable conflict, one could give the CJ language higher up in the list priority for LC_CTYPE. But, as I wrote above, setting LC_CTYPE to a CJK locale different from your main language may cause some problems. Therefore, although this may be a fine default for you, it may not be the best default for everybody.
Maybe one could extend the "Expert Language settings" dialog in YaST2 to edit LANG and all the LC_ variables. Currently you can only choose whether to use UTF-8 or not and the value of ROOT_USES_LANG in that dialog.
Yes, that's a nice idea: Offer CTYPE in the experts dialog, and select the default as mentioned above.
Select the main language (here I would like to correct de_DE to de_CH) and the CTYPE would be enough for me (in addition to the already existing "UTF-8" (why should one not use UTF-8?!?)
Nowadays I don't see any reason not to use UTF-8 either.
What do you mean by "official"? Of course you can set your locale to de_CH.UTF-8 (by editing /etc/sysconfig/language), this locale is supported by glibc and contained in the glibc-locale package.
Ah, ok. But it is not in the list of supported language settings in the comment of the /etc/sysconfig/language file. That's why I though it was unsupported.
That list is a bit strange. Somebody edited that list manually a while ago and just listed some locales he thought to be useful. This is not a complete list at all. It would be better if that list could be generated automatically from the list of locales supported on the installed system, currently it is just a hardcoded list with no particular meaning.
Also different in Switzerland, AFAIK, is the currency, some numbering and time rendering (we have 1'234,56 and hh.mm -> how is it in Germany?).
Numbers are written like 1.234,56.
Glibc doesn't appear to make a difference in the time format
between de_DE and de_CH, both in /usr/share/i18n/locales/de_DE
and /usr/share/i18n/locales/de_CH there is
t_fmt "<U0025><U0054>"
which is %T (time, 24-hour (hh:mm:ss), see the man-page of "date").
mfabian@magellan:~$ LANG=de_CH.UTF-8 date
Die Mai 17 17:41:15 CEST 2005
mfabian@magellan:~$ LANG=de_DE.UTF-8 date
Di Mai 17 17:41:25 CEST 2005
mfabian@magellan:~$
This may be an error in glibc of course, if you think it is you may
file a bug in the glibc bugzilla.
--
Mike FABIAN