GNU bug report logs - #57531
28.1; Character encoding missing for "eo"

Previous Next

Full log

Message #181 received at 57531 <at> debbugs.gnu.org (full text, mbox):

From: Gregory Heytings <gregory <at> heytings.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: jonathan <at> jonreeve.com, Eli Zaretskii <eliz <at> gnu.org>, schwab <at> linux-m68k.org,
 57531 <at> debbugs.gnu.org
Subject: Re: bug#57531: 28.1; Character encoding missing for "eo"
Date: Thu, 06 Oct 2022 11:28:59 +0000

>>> This does work (with or without the patch):
>>>
>>> LANG=eo.UTF-8 ./src/emacs -Q
>>> current-locale-environment
>>> "eo.UTF-8"
>>
>> But it requires the eo.UTF-8 locale to be available, AFAIU, and for 
>> that reason somehow didn't work for the OP.  I don't think I understood 
>> why it didn't work for him.  I still hope the OP will come back and 
>> help us understand that.

Actually that problem has been debugged: it's a NixOS bug.  NixOS rejects 
the locale to "eo.UTF-8" in its configuration files, even though 
"eo.UTF-8" is a perfectly valid locale.  It rejects it because the 
"eo.UTF-8" string is not present in some text file (apparently the 
"localedata/SUPPORTED" file from glibc).

>
> Yes, that would be helpful.  On this Ubuntu system, I just uncommented 
> the "eo" line in locale.gen and ran locale-gen, and that made both the 
> "eo" and "eo.UTF-8" locales available.
>

Another similar example is the en_IL (English Israel) locale.  X11's 
locale.alias indicates that "en_IL" alone means "en_IL.ISO8859-1", yet 
glibc provides only one encoding for "en_IL", namely "UTF-8".

To avoid such bugs, the most reasonable thing to do for users is to always 
specify the encoding.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.