Re: Better language detection for tutorial

[Eli Zaretskii <eliz@gnu.org>]

> Cc: thomas@intevation.de, schwab@suse.de, emacs-devel@gnu.org
> From: Sascha Wilde <wilde@sha-bang.de>
> Date: Mon, 23 Jul 2007 22:29:16 +0200
> 
> >> > I think this is in wrong order: the `tutorial' property of the
> >> > language environment should have higher priority than what the new
> >> > function `tutorial-get-language' returns.
> >> 
> >> I highly doubt that, for all my tests (more complex locale setups,
> >> that is) the tutorial property of the language environment yields
> >> an unexpected (IMO wrong) language.
> >
> > Please tell the details, then.  It's hard to argue with unspecified
> > results of unnamed tests.
> 
> Please read my initial mail <m2k5sy2f3o.fsf@kenny.sha-bang.de> for a
> complete, real world example.

That's the message that started this discussion, right?  If so, it
just shows, AFAICT, that the way language environment is determined
might need fine-tuning.

Anyway, what you said (see above) seemed to indicate (``for all my
tests'', with ``tests'' in plural) that you have more than just a
single example, thus my request.  Apologies if I misunderstood you.

> > In general, the tutorial property of the language environment should
> > be more accurate, since it is specific to Emacs, and specific to the
> > situation (i.e., reading the tutorial).  By contrast, the locale
> > environment variables are general and not limited to Emacs, so they
> > might be wrong for Emacs where general needs conflict with Emacs
> > tutorial needs.
> 
> The opposite is true: the LC_* environment variables provide a
> universal way to define what i18n variant (language, data formatting
> etc.) the user wants for specific aspects of applications.

I'm obviously failing to explain myself: my point was _exactly_ that
universal settings might be applicable to Emacs needs not as well as
Emacs-specific defaults.  For example:

> A well behaved application should respect these settings.  But
> currently Emacs potentially displays the tutorial in an language
> unrelated to LC_MESSAGES, which is not what a user familiar with
> locale settings would expect.

It is not clear (at least to me, but it sounds like I'm not the only
one) that LC_MESSAGES is relevant to selecting the tutorial.  On a
GNU/Linux system, the locale(1) man page says:

	LC_MESSAGES
              Formats  of  informative and diagnostic messages and
              interactive responses.

and locale(7) says:

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

In other words, LC_MESSAGES talks about messages of the type Emacs
shows in the echo area.  It is not at all clear that the same setting
is good for the tutorial.

> So the tutorial language is set based on the
> current-language-environment, which is in turn determined (if not set
> explicitly) in a way, disregarding the users choice for ui messages
> language.  This is no good.

Then perhaps we should modify the way the language environment is
determined, and leave the tutorial alone.

In any case, please keep in mind that the language environment can be
set from ~/.emacs or interactively, not only from environment
variables.  I hope you are not saying that LC_MESSAGES should override
that as well.

> Making the tutorial property higher priority than my
> `tutorial-get-language' would make my patch nearly useless...

It sounds like fixing the way the language environment is determined
is a better way to solve this problem.  My interpretation of your
original report is that in that particular case, Emacs wrongly decided
that the user's language environment is German.  I hope you agree
that, if the language environment is indeed German, the user should be
shown a German tutorial.