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

[Leonard Lausen]

>>> 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.

Well, it's a fallback for the things that the respectively undefined
LC_* variable would define. So the argument here is that LC_CTYPE
according to POSIX does not define the interface language.

The current behavior of emacs can only be justified by the "Additional
semantics of this variable, if any, are implementation-dependent."
clause for the LC_CTYPE variable. Note though that I have besides
Dropbox not found a single program which uses LC_CTYPE to set the
interface language. Instead those other programs rely on LANG. You may
try "LANG=zh_CN.utf8 vim" compared to  "LC_CTYPE=zh_CN.utf8 vim" as
example. Also the name of LANG compared to LC_CTYPE does somewhat
suggest to me that it should define the interface language whereas CTYPE
should define the "character types" (?) ;)

So I agree with the previous comment that LANG should take precedence
over LC_CTYPE with regards to the interface language. Not sure if the
current emacs implementation allows that change without affecting the
settings where LC_CTYPE does change precedence over LANG.

But nevermind if you prefer to keep the current behavior. You taught me
how to overwrite the language variable manually, so while I still am
unhappy about emacs behaving differently to most applications, my
immediate concern is resolved ;)