bug#27505: acknowledged by developer (Re: bug#27505: LC_CTYPE affects tutorial language)

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 27505@debbugs.gnu.org
> From: Leonard Lausen <leonard@lausen.nl>
> Date: Sat, 5 Aug 2017 18:52:38 +0900
> 
> > But I don't see why that would be a problem for you: if you don't want
> > that Emacs language environment be Chinese when you use XIM, you
> > should be able to invoke set-language-environment inside Emacs after
> > starting it, to set the language environment to something other than
> > Chinese.  Does that work for you?
> 
> That is a good workaround. I created this bug report, as I would expect
> this as default behavior though.

The default behavior is very unlikely to change, sorry.  It took us
many years to arrive at the current behavior, so changing that for a
single use case, even if it's deemed important, makes little sense to
me.

> > See the "interpretation of sequences of bytes of text data as
> > characters" parts: that's what causes Emacs to use LC_CTYPE to setup
> > the language environment.  So we do follow Posix, AFAIU
> 
> Hm, as long as LANG and LC_CTYPE both are UTF-8 locales, the
> interpretation of bytes would be the same.

Yes, but LANG is the fallback in case LC_* are not defined, so I don't
think how LANG set to a different language than LC_CTYPE could be
according to Posix.

> In principle the interface
> language is independent from the interpretation of bytes right? One
> could just parse the first part of LANG (i.e. "en_EN") do decide the
> display language but follow LC_CTYPE for the interpretation of bytes.
> This seems also to be what the majority of applications are doing, given
> that I set LC_CTYPE to Chinese system wide, but only emacs (and Dropbox)
> are changing their interface language (more specifically the tutorial
> language).

In Emacs, "display language" is just one aspect of the multi-lingual
environment.  So I'm afraid if the default is not to your liking, you
will have to customize the individual aspects of the language
environment separately, as you see fit.  That's why those variables
exist in the first place -- to tailor the Emacs operation to even rare
and non-typical use cases.