On Thu, Feb 20, 2003 at 10:57:23AM +0100, Gerd Knorr wrote: > Thomas Zander <[EMAIL PROTECTED]> writes: > > > > You can specify "en_US.UTF-8" as your locale. Which implies to me that > > > xterm can recognize, from its environment, the encoding, and act > > > accordingly. > > > > Hope you aren't using the locale standard 'Variation' variable for > > that; in most europe countries that will give problems since they > > allready use it for the EURO variation. Do you know who came up > > with this idea? Is there a mailing list I can look at? > > > > Knowing my locales; encondings should not be in a locale! (Since the > > user can override them) > > The encoding _is_ in the locale.
Not true; the locale is nothing more then a pointer to the i18n and l10n specific for that person using the computer. Naturally the l10n implies certain things like currency, date format etc. The nl_NL@EURO has a variant to change one aspect of the implied information. > Allowing the user to override it is > a design bug (de_DE@euro with iso-8859-1 isn't going to work ...). That is exactly why your assertion that locale == encoding fails. If a user decides to read his error messages in german he changes his locale, same with date format etc. But changing the locale should not imply a change in the encodings since changing the locale does not change all your text files and filenames. It could be implied information; but you can't say that if you want to change the encoding you have to change the locale. Your reasoning would work if it is impossible to change the locale, but (luckely) it is not, otherwise you would have to reinstall your machine to be able to see KDE/GNOME (or bash errors) in another language! As a SuSE install recently showed me, the machine locale is a default, nothing more then a hint. This is why (as I stated before) a machine wide variable should be created that has nothing to do with locale can imply the usage of utf8 for XFree. > Use the correct locale instead, there are different ones for different > encodings: > > E199 kraxel ~# LANG=POSIX locale charmap > ANSI_X3.4-1968 > E199 kraxel ~# LANG=de_DE locale charmap > ISO-8859-1 > E199 kraxel ~# LANG=de_DE@euro locale charmap > ISO-8859-15 > E199 kraxel ~# LANG=de_DE.UTF-8 locale charmap > UTF-8 I get no difference in charmap between these last two on my debian SID machine. > > And, yes, of course xterm should start up in utf-8 mode if the locale > encoding is UTF-8. > > Gerd This will only work (as RedHat discovered allready) if your machine is alone on this world. The correct solution is that the commands man, ls etc would correctly use uft8 at which moment the strings they display (send through the ssh port or to an xterm) have to be encoded in an encoding the current bash/csh decided on. That last part has always happenes correctly, the first (adjusting man and ls) is something that has yet to occur. Creating a shortcut by trying to do the encoding conversions later on will not work. But again; you allready saw that. Each and every application that assumes latin1 or other non-utf8 encodings has to be adjusted before a system as a whole can be converted. Conclusion; An xterm should be able to display chinese if man or ls outputs that, no matter what encoding the files man reads them in, but man reads utf-8, not xterm. Please follow KDEs example and make XFree configurable by the distro if he wants his texts and filenames in utf8 or not; use a global environment var or a file or similar. But (again) not for the encoding of xterm, but for the resources where it is relevant. -- Thomas Zander _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
