Re: master e4e1e268c8e 2/2: Set a default locale on Android

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 08 Dec 2023 08:11:05 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Is this the best we can do on Android?  AFAIU, the issue here is that
> > the locales available on Android are different from those recognized
> > by the C library.  But cannot we solve this by implementing a mapping
> > from Android locales to libc locales?  If not, why not?
> >
> > I think arbitrarily using en_US.utf8 could surprise users and worse,
> > could produce effects that break UX.  For example, LANG defines the
> > default spell-checking dictionary, so the above basically forces users
> > of non-English locales to manually change the dictionary each time,
> > or customize their Emacs to do that, something they don't have to do
> > on other platforms.
> 
> This is the behavior of other Android programs placed in similar
> situations, and is only designed to enable programs to output UTF-8
> error messages and the like, not for these programs to print messages in
> the language the user has configured, most of which the Android C
> library doesn't support anyway.

I wasn't talking about error messages, I was talking about other uses
of LANG and locale information in Emacs.  E.g., we define the default
coding-systems based on the locale, and detect-coding-* guesswork uses
it.  How does the solution you installed affect all that when, for
example, Emacs needs to visit a file or show an email or use
sub-process output encoded in Latin-1 with no charset information
available from other sources?

As for other programs' behavior: since when we consider that a
dictate?  We take the platform-specific behavior into consideration,
but make our decisions based on additional aspects as well.  And I
still don't see why in this case we should use such a simplistic
solution.  Is there any problem in having a mapping of the kind I
suggested?  If that is possible, it sounds to me like a simple-enough
solution that will make the Android build behave like Emacs users
expect, with minimal costs and with predictable success.

In any case, if there are Android-specific aspects of this, they
should be prominently mentioned in the "Language Environments" section
of the user manual.  I don't think they are, as of now, unless I
missed something.

Thanks.