[kde-linux] Wrong language detection in KDE since 3.1
kloecker at kde.org
Sat Mar 29 14:41:45 GMT 2003
On Friday 28 March 2003 21:58, Lukáš Tinkl wrote:
> Dne pá 28. března 2003 17:01 Ingo Klöcker napsal(a):
> > Does anyone object against the following change:
> > =====
> > - langs << QFile::decodeName( ::getenv("LC_CTYPE") );
> > - langs << QFile::decodeName( ::getenv("LC_MESSAGES") );
> > langs << QFile::decodeName( ::getenv("LC_ALL") );
> > + langs << QFile::decodeName( ::getenv("LC_MESSAGES") );
> > langs << QFile::decodeName( ::getenv("LANG") );
> > + langs << QFile::decodeName( ::getenv("LC_CTYPE") );
> > =====
> Do you know what happens if the root user has LANG=C (or en_US) or
> LC_MESSAGES=C (or en_US) but you still want to enter non-english
> characters under root? Did you actually test that?
I don't understand your problem. Let's have a look at another excerpt of
This changes the behaviour of the character handling and classification
functions, such as isupper() and toupper(), and the multi-byte
character functions such as mblen() or wctomb().
changes the language messages are displayed in and how an affirmative or
negative answer looks like. The GNU C-library contains the gettext(),
ngettext(), and rpmatch() functions to ease the use of these
information. The GNU gettext family of functions also obey the
environment variable LANGUAGE.
I see no indication that the value of LANG or LC_MESSAGES should have
any effect on the characters someone can enter. Their value should only
affect the language of messages. If KDE applications don't behave this
way then they have to be fixed as Stephan already said.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
More information about the kde-core-devel