Version: (using KDE KDE 3.1.4) OS: Linux Hi, KDE pretty well allows to choose the language of the user interface, but does propagate the setting to KDE applications only. There are other important applications such as Openoffice, which cannot configured interactively but do require the environment variable LANG to be set properly. Would be good if KDE would propagate the language setting through LANG or would allow to separately choose this variable for the desktop. regards Hadmut
I didnt test it. But KDE also should ensure that the locale chosen is a utf-8 locale. If it is not, some deadkeys in some languages don't work if you choose a different for a different language. For example, I use English for all applications but then I write in Czech. cs_CZ.iso-8859-2 locale works but that's not what I want (I want English messages) en_US.iso-8859-1 disables some of the dead keys which is very annoying. en_US.utf-8 works just fine (the above is related to X and i tested it launching applications from Konsole) Current X applications usually ignore the charset part of the locale (only X does not).
> But KDE also should ensure that the locale chosen is a utf-8 locale. Unfortunately, we cannot do that. For one thing, if we did it, the user's file names could be incorrectly decoded. But the biggest problem is that we need the language to exist in glibc for it to work. If it doesn't, setting LANG to it would be the same as setting LANG=C.
Hmm First I don't understand the way how the filenames are encoded. I thought it was utf-8 already. Some link or hint would be great. And then is it all about glibc locales? So why not let the user choose one (suggesting the best one - that for his language with utf8 - if it exists)? Would be nice to be able to switch the language for all apps. On the other hand, experienced user or admin can do it himself just as easily. Maybe it's not so important.
Filenames are encoded in the user's locale. They are UTF-8 in UTF-8 locales, but they are Latin 1 in Latin 1 locales, Latin 2 in Latin 2 locales, etc. The problem with non-existent locales is this: $ LANG=C ls asdf ls: asdf: No such file or directory $ LANG=pt_BR.UTF-8 ls asdf ls: asdf: Arquivo ou diretório não encontrado $ LANG=pt_PT.UTF-8 ls asdf ls: asdf: No such file or directory You see that pt_PT.UTF-8 doesn't exist. So the setlocale(3) calls in glibc will fail for that, which in turn means we don't know whether the locale is UTF-8 or not (there are UTF-8 locales that don't end in ".UTF-8"). In other words: locales exist for programs only if they exist in glibc too.
Hmm, I understand.
Hello, Any news regarding this wish? Is it valid? Thanks.
This should be fixed now.