The GOK "static" keyboard such as the Main keyboard don't use gettext(), because
locale-specific versions of the keyboard XML files already exist.  For instance,
if locale is fr, then GOK reads /usr/share/gok/fr/main.kbd, etc.

GOK uses LANG for this, not LC_MESSAGES.  This is intentional, though I suppose
a case could be made for using LC_MESSAGES instead of LANG.
 

Looking only at LANG is never the right behaviour. The right behaviour is:

 if LC_ALL set, follow it
 else if LC_XXX set, follow it
 else if LANG set, follow it
 else default/POSIX/C/...

where "XXX" is the right choice for the thing being decided (what to consider a
character (CTYPE), sorting orde (COLLATE), communication with the user
(MESSAGES), dates formating and parsing (TIME), numbers formatting and parsing
(NUMERIC), ...) See 'man 7 locale' for details.

LANG is only a default value for LC_XXX's, never a deciding factor by itself,
and LC_ALL only an overriding value for LC_XXX's, never a deciding factor by itself.

These are the most common locale handling errors I encounter.

For the specific case here, the documentation says:

      LC_MESSAGES
              changes  the language messages are displayed in and
              how an affirmative or negative answer  looks  like.

It seems pretty clear to me that the labels on the buttons of the main window
are "messages" displayed to the user, and thus fall in this category.

Hi Lionel:

I understand your comment, but I am afraid that I do not agree with your
conclusion.  Since GOK is so intimately linked to the use of the keyboard and
language environment (rather than just the 'message' environment), I think LANG
is the better choice.  Ideally we would treat the various LC_XXX categories
differently, but this is not practical for GOK because we are crafting
language-specific keyboards for each case.  Since we must (at least for the
static keyboards) use only one of the locale parameters, LANG was chosen as the
most general and closest in correspondance to the primary "keyboard" paradigm.

It seems very strange to me to have a program that displays one window in one
language (e.g. "I have enabled sticky keys, since I need it", "you are running
in core pointer mode") and another one (the 3*3 buttons matrix with "activate",
"settings", etc) in another one. That's inconsistent.

And the bug report was not about the keyboard itself, but about the strings on
the buttons on the main window (and on the keyboard, too). I am _not_ arguing
over the keyboard layout.

You want to make the on-screen keyboard disposition follow LANG and not any
LC_*, fine, I don't have any strong opinion on that, and indeed it doesn't
cleanly fall into any of the LC_XXX categories (although LC_ALL looks relevant
and I'd probably say "use LC_ALL if set, else LANG".

But the strings displayed on the buttons of the main window (the 3*3 matrix) and
on the keyboard ("space", "previous", ...) are definitely communication with the
user that should happen in the LC_MESSAGES language (with LC_ALL overwrite and
LANG fallback); there is no fundamental difference between those and the pop-ups
explaining core pointer problems, for example.

Do I understand what you mean by "we are crafting language-specific keyboards"
well? What I understand is that you are speaking about the layout of the
keyboard, not the strings on the buttons.

Or from a different angle: is the french layout forced to have french button labels?

(BTW, concerning Lionel's remarks, I think the cascading of precedence between
LC_ALL, LC_MESSAGES, and LANG is done automatically if one calls setlocale() to
request a type of locale.)

Hi Lionel:

>Do I understand what you mean by "we are crafting language-specific keyboards"
>well? What I understand is that you are speaking about the layout of the
>keyboard, not the strings on the buttons.

Our "language-specific" keyboards do both, i.e. the layout _and_ the labels are
LANG-dependent.  We also have some keyboards, like the 'main.kbd. one, which
corresponds more closely to LC_MESSAGES.  The problem is that technically, we
currently must choose only ONE locale-specific directory from which to read all
our pre-compiled keyboards.  Since we must decide between LC_MESSAGES, LC_ALL,
LANG, etc. for ALL our static keyboards (in the current implementation), we
chose LANG because we felt it was most important that the 'compose' keyboard
follow the user's LANG.  The labels on the 'dynamically generated' GOK keyboards
already track LC_MESSAGES, in some cases the 'GOK' LC_MESSAGES value and in
other cases the LC_MESSAGES value from other applications (because GOK
re-displays strings from other applications as well as presenting its own
message strings and various keyboard layouts).  GOK can also read the keyboard
layout directly from the X server, so if you change your keyboard layout without
changing LANG, you also get the altered keyboard layout (if GOK is configured to
read the keyboard layout from the server, instead of using a precomposed keyboard).

The short answer is that we had to choose one LC/LANG parameter for reading
GOK's static keyboards, and we chose LANG, because of the special nature of the
GOK application.


The button labels on the French keyboard layout depend on how GOK is configured.
 If GOK is reading the keyboard layout from the Xserver, the resulting labels
are mostly french (i.e. the ones which are single glyphs), but certain strings
will be localized into the LC_MESSAGES locale in which GOK is running.