Eirik Byrkjeflot Anonsen eirik at opera.com
Fri Dec 19 01:35:07 PST 2008

"Nicolas Mailhot" <nicolas.mailhot at laposte.net> writes:

> Le Jeu 18 décembre 2008 17:08, Eirik Byrkjeflot Anonsen a écrit :
>> "Nicolas Mailhot" <nicolas.mailhot at laposte.net> writes:
>>> Hi,
>>> I hope that when XI and XKB are reworked a "language" property will
>>> be
>>> added to the protocol.
>>> Right now many apps try to infer the language being written from the
>>> xkb layout in use (for on the fly spellchecking, activation of the
>>> correct locl font features, etc) and since the same layout can be
>>> used
>>> to write different languages the heuristic breaks badly.
>> In which cases should this differ from the system locale?
>> (I.e. whatever setlocale() returns).
> When someone writes an English message to an international list, for
> example.

Thomas Ilnseher <illth at gmx.de> writes:

> The Problem is IIRC that this locale stuff uses environment variables
> (ie. LANG, LC_ALL, etc ...). This stuff is placed on the stack of a new
> process when execve is called, and can't be changed at runtime.

Ah, I see.  The problem is when there is something outside the
application that wants to change the current locale of the

If the application itself wants to change the language, it obviously
knows which language it works in (emacs does that, which is how I do
japanese, norwegian etc.)  The problem with that is that the support
must be built into each application, which also means that each
application behaves differently.

It seems to me that this is only about text input.  In general I would
assume that only the user's current text input language is what is
particularly useful to change frequently.  So this would be part of
"internationalized text input", otherwise knows as "input methods".
To the extent that X has support for input methods, I think it makes
some sense to be able to ask the input method subsystem of X "what
language is the user currently typing in".  But then again, maybe
input method handling should be decoupled from X completely.


More information about the xorg mailing list