Does not clean up esperanto locale

Thanks for your bug report. It's not listed in gui/gdmlanguages.c - I reported
the issue upstream: http://bugs.gnome.org/show_bug.cgi?id=318559

It's not listed in /etc/locale.alias - reassigning. GNOME is just responsible
for the nice Translation in GDM.

I have upgraded from Ubuntu-5.04 (Hoary Hedgehog)
to Ubuntu-5.10 (Breezy Badger) (apt-get update, apt-get dist-upgrade)

I was hoping it would possibly fix this bug among other things
but the bug is still there.

Also, I noticed something new in Breezy Badger, it is possible to
select languages from GNOME top bar:

  system -> administration -> language selector

Although "Esperanto" language appears ticked (installed)
in the GNOME language selector, it does not show up in
the list in the "Default language" selection combobox.

So in short, bug is still there after upgrading to Breezy Badger.

I attached a screenshot of the language selector. The screenshot shows that English, French and Esperanto languages are installed. However, when trying to select the language, only English and French are available.

I also precise that I installed Ubuntu-5.10 on another machine and observed the same bug.

I also noticed that if I install Kubuntu, then I can switch to Esperanto. So this problem seems to be specific to gnome.

The locales packages got updated during the recent distro sprint. Can you try again with a fully up to date system and see if this is fixed now? A number of problems that people had have gone away.

Jeff Bailey wrote:

> The locales packages got updated during the
> recent distro sprint. Can you try again with a
> fully up to date system and see if this is fixed
> now? A number of problems that people had
> have gone away.

I have the latest updates to "Breezy Badger" packages as of today (Feb 13, 2006) + latest security updates + universe + backports. However, the bug is still there.

I remember indeed seeing locale packages being
updated a few weeks (or months?) ago but it did
not change anything to this problem.

Right, sorry. I had actually meant the latest 'dapper' packages. We tend to fix bugs in the development version first before evaluating if the fixes should go into a stable release or not.

Do you have access to a Dapper system?

Jeff Bailey wrote:

> Right, sorry. I had actually meant the latest 'dapper'
> packages. We tend to fix bugs in the development
> version first before evaluating if the fixes should go
> into a stable release or not.
>
> Do you have access to a Dapper system?

Oh right. No, I have not tried Dapper. I prefer
not to experiment too much with my stable
machine right now and I only have a slow internet
access anyway. So I probably won't upgrade to
Dapper until it's stable (Apr 2006). Sorry about
that.

Anyway, if anybody wishes to try to reproduce
the bug to verify whether it's fixed or not in Dapper,
it should easy:

- install the Esperanto language Packages (probably
  not all of these are necessary):
     language-pack-eo
     language-pack-eo-base
     language-support-eo
     iesperanto

- try to change language either in the GNOME
  language selector (From top menu bar:
  Sytem -> Administration -> Language Selection)
  or when loggin-in from gdm.

- observe that Esperanto language is not available
  even though packages were installed (see screenshot
  attached a in previous comment). I'd expect
  to be able to switch to Esperant language.

I've tried in Dapper, and it's still not working.

I've installed Esperanto via the System > Admin > Language Selection. The files were downloaded and installed but you can't select esperanto (in gdm and in the language selection)

One bug is that the locale cannot be generated - the locale is eo_XX.UTF-8, but the locale definition file is just 'eo', not 'eo_XX'. Will fix that in the next locales version.

The other part of this bug is that /etc/gdm/locales.conf does not know about Esperanto. Adding

  Esperanto eo_XX.UTF-8

fixes gdm.

 langpack-locales (2.3.12) dapper; urgency=low
 .
   * locales/en_NZ: Add AM/PM definition (Malone #34262)
   * locales/tr_TR: Fix stray space in int_curr_symbol (Malone #34738)
   * locales/eo: Rename to eo_XX, since that's the format that other programs
     expect (Malone #23435)
   * locales/es_CO: Change standard paper size from A4 to US Letter. (Malone
     #27622)

 gdm (2.14.0-0ubuntu2) dapper; urgency=low
 .
   * debian/locale.conf: Add all 41 missing locales. (Malone #23435)

With both fixes, selecting Esperanto works now.

I'm using Gutsy Gibbon Ubuntu, recently updated and I have the same problem here. Shouldn't it be working?

I'm using Hardy, the same problem.

Same problem on Hardy (8.04.1).

The source of this problem - eo locales does not created when esperanto support gets enabled.

To fix it I added names of all available esperanto locales (from /usr/share/i18n/SUPPORTED) to the /var/lib/locales/supported.d/eo file.
It is just 3 lines:
eo.UTF-8 UTF-8
eo ISO-8859-3
eo_US.UTF-8 UTF-8

Then I ran locale-gen command to generate required locales and it worked fine.
After that I got possibility to choose esperanto language in GDM and/or start any program with esperanto locale using commands like "LC_ALL=eo cal" etc.

Hope this helps.

I tried what Alexey suggested, but it didn't work for me on Hardy.

Also not working for me.
Im using newest Hardy. It seems to me it worked some months ago?

I tried editing the /etc/gdm/locale.conf, the /etc/locale.alias and the /var/lib/locales/supported.d/eo but no luck.

Sed... neniu Esperanto.. kion fari :-(

Please reopen this bug.

Googling around I and trying different things I found from http://groups.google.com/group/eliberaprogramaro/msg/7304b9fd744a55fd that typing

sudo localedef -f UTF-8 -i eo eo.UTF-8

solved my problem. I have no idea what the command does, but it fixes the problem for me.

I think this bug should not be closed until it is possible to select Esperanto and work without having to execute any command or edit any files.

So I don't see either of the fixes that Martin did on my Intrepid machine. GDM's locale.conf doesn't use eo_XX and langpack-locales still calls the locale 'eo'. So I'm not sure what's up with that.

However, I believe the real problem lies in belocs-locales-bin:

When installing a language-pack-XX-base package, the program 'install-language-pack' is called with the language code during postinst. The expectation is that this will generate all UTF-8 locales for that language on the system. This occurs by in turn calling locale-gen and expecting it to fallback to its 'guess that the user wants all locales' algorithm if it can't find the exact specified locale in /usr/share/i18n/SUPPORTED.

However, the language eo has a locale in /usr/share/i18n/SUPPORTED called just 'eo'. So locale-gen thinks that the caller wants that specific locale and never uses its 'install all locales for the language' fallback logic.

Even if it did use that logic, the code assumes that there is a country code for all UTF-8 locales. This might not be the case, as eo shows (there is a 'eo.UTF-8' locale).

Attached is a debdiff for jaunty that modifies locale-gen to add a new argument --lang that tells it that the passed argument is really a language code, not a specific locale that we want generated. This part is needed to bypass the exact match of 'eo'.

Then, I also modified locale-gen to use a slightly more clever 'find all UTF-8 locales' algorithm that anticipates locales without country codes (like eo.UTF-8 and any other such).

I added the --lang option to the install-language-pack script and modified remove-language-pack to support deleting locales that don't have country codes.

reassigning to glibc, because I was just about to file for removal of belocs-locales-bin from jaunty since it's now uninstallable following the last glibc change.

Sorry that this slipped. I'll look at this today.

locale-gen is shipped in langpack-locales now.

In Jaunty, the situation is different. "eo" as locale doesn't exist any more in /usr/share/i18n/SUPPORTED, since it is malformed (no country). Since a locale defines date formats, currencies, address formats, etc., they are always country specific. So ideally there would be more eo_* locales available for more countries.

As it stands, current locales have eo_US which resolves the install-language-locales confusion described above, and "eo" (for backwards compatibility, I think). However, the eo_US locale does not actually work:

$ sudo apt-get install language-pack-eo
[...]
Richte language-pack-eo-base ein (1:9.04+20090213) ...
Generating locales...
  eo_US.UTF-8... LC_ADDRESS: terminology language code `eo' not defined
failed
  eo.UTF-8... done
Generation complete.

I just tested this in current Jaunty, and it works correctly now (presumably because there is no locale "eo" any more, just "eo.UTF8"). I can install language-pack{,-gnome}-eo, get "Esperanto" as a langauge choice in gdm, and an Esperanto desktop.

However, the remove-language-locales bug still stands, and Michael's robustifications to locale-gen look like a good idea, too.

This bug was fixed in the package langpack-locales - 2.9+cvs20090214-6

---------------
langpack-locales (2.9+cvs20090214-6) jaunty; urgency=low

  * debian/local/locale-gen:
    - Add --lang option which means the argument is a language code and
      not a specific locale. All of its locales will be generated,
      including any without a country code.(LP: #23435)
  * debian/local/install-language-pack:
    - Call locale-gen with above --lang argument
  * debian/local/remove-language-pack:
    - Remove locales even if they don't have a country associated with
      them.

 -- Michael Terry <email address hidden> Fri, 30 Jan 2009 10:55:02 -0500