LocalesThatDontSuck

Differences between revisions 5 and 7 (spanning 2 versions)
Revision 5 as of 2005-11-01 21:34:27
Size: 2712
Editor: 209
Comment: Update to reflect latest BoF
Revision 7 as of 2005-11-02 20:55:33
Size: 3742
Editor: 172_220_103_66-WIFI_HOTSPOTS
Comment: Finalize
Deletions are marked like this. Additions are marked like this.
Line 20: Line 20:
In addition, updating locales requires a complete rebuild of the glibc package. This is a very time and resource intensive build just for the sake of arch-indep files.
Line 23: Line 25:
 * Agloolik lives in Iqaluit, Nunavut, Canada and has been using Rosetta to do translations, but wants his gnome calendar to correctly use Sunday as the first day of the week.  * A user from an unsupported locale would like to submit his entry. We accept it via Rosetta, and it gets applied during the next lang-pack build.
Line 25: Line 27:
 * Locales maintainer wants to upload new locales, but does not want to force a rebuild of the entire glibc source.  * New locales need to be integrated. The locales maintainer merges with lang-pack, and avoids having to force a rebuild of glibc.
Line 36: Line 38:
Currently locales come from glibc proper. Implementation will move locale data into lang-packs for easier maintenance, and to allow us to move to belocs-locales, which will provide more up-to-date data.

Line 38: Line 43:
First stage is to remove locales package from glibc build. First stage is to remove locales package from glibc build. The locales binaries still need to be provided by libc6, since they are used to generate the binary, arch-dependent locales. The locales-gen script from the locales package would need to be moved to libc6 aswell. The locales-gen script needs to be modified as noted below. libc6 would then need to conflict with locales.
Line 40: Line 45:
Second, the belocs-locales data needs to be merged into language packs build. There would need to be a lang-pack-base that included things such as the locale-gen script from locales, was able to build the locales upon installation and selection. The lang-pack-base locales list would be generated based on files placed in /etc/locales/supported.d/ (or other proper location). Files in this directory seeded from the lang-packs. Second, the belocs-locales data needs to be merged into language packs build. When a lang-pack is installed, it should place a file called /etc/locales/supported.d/<lang-name>. The postinst script would then call locales-gen with the lang-name. Locales-gen would parse this file, and (re)generate all the locales listed there-in (which may be more than one, for e.g. english, there is en_US, en_CA, etc).
Line 42: Line 47:
The language pack base would then conflict with the old (obsoleted) locales package.

Lang-packs would included all of the proper locales for that language (e.g. en_* for English).
Lang-packs would include all of the proper locales for that language (e.g. en_* for English).
Line 49: Line 52:
Requires somewhat extensive packaging changes for the lang-packs. Requires somewhat extensive packaging changes for the lang-packs. The locales-gen script needs to be modified to understand /etc/locales/supported.d/<lang-name>.
Line 57: Line 60:
== Outstanding issues == == BoF agenda and discussion ==
Line 59: Line 62:
None Attendees generally agreed that having locales in glibc was sub-optimal, and that not being able to get locales merged upstream was just an added difficulty.
Line 61: Line 64:
Consensus was that moving to lang-packs now, would also enable us move maint of the locale data to Rosetta at a later date (hopefully, dapper+1).
Line 62: Line 66:
== BoF agenda and discussion == A new spec needs to be created for Rosetta, to plan for the move of locales data.

Summary

In order to serve our user communities better, we need to be more responsive and proactive with localisation updates.

Rationale

Getting locale changes into upstream glibc is unnecessarily hard. The glibc maintainer (correctly) requires proof of the correctness of a change before it's included, but the onus of demonstrating that change falls to the glibc package maintainers. The package maintainers are frequently not qualified to provide this proof, and cannot answer upstreams questions to the needed degree of satisfaction. The glibc upstream maintainer also has a well deserved reputation for being difficult to approach with changes.

In addition, updating locales requires a complete rebuild of the glibc package. This is a very time and resource intensive build just for the sake of arch-indep files.

Use cases

  • A user from an unsupported locale would like to submit his entry. We accept it via Rosetta, and it gets applied during the next lang-pack build.
  • New locales need to be integrated. The locales maintainer merges with lang-pack, and avoids having to force a rebuild of glibc.

Scope

  • Locales / Belocs-locales-data(universe) packaging
  • Langpacks

Design

Currently locales come from glibc proper. Implementation will move locale data into lang-packs for easier maintenance, and to allow us to move to belocs-locales, which will provide more up-to-date data.

Implementation

First stage is to remove locales package from glibc build. The locales binaries still need to be provided by libc6, since they are used to generate the binary, arch-dependent locales. The locales-gen script from the locales package would need to be moved to libc6 aswell. The locales-gen script needs to be modified as noted below. libc6 would then need to conflict with locales.

Second, the belocs-locales data needs to be merged into language packs build. When a lang-pack is installed, it should place a file called /etc/locales/supported.d/<lang-name>. The postinst script would then call locales-gen with the lang-name. Locales-gen would parse this file, and (re)generate all the locales listed there-in (which may be more than one, for e.g. english, there is en_US, en_CA, etc).

Lang-packs would include all of the proper locales for that language (e.g. en_* for English).

Code

Requires somewhat extensive packaging changes for the lang-packs. The locales-gen script needs to be modified to understand /etc/locales/supported.d/<lang-name>.

Data preservation and migration

Belocs-locales seems to want to be a superset of glibc locales, but it appears to be missing several locales that are in glibc proper. If anything is missing from belocs, then either the missing part needs to be investigated for inclusion aswell. It may be that ones missing from belocs just don't work, or are no longer needed.

BoF agenda and discussion

Attendees generally agreed that having locales in glibc was sub-optimal, and that not being able to get locales merged upstream was just an added difficulty.

Consensus was that moving to lang-packs now, would also enable us move maint of the locale data to Rosetta at a later date (hopefully, dapper+1).

A new spec needs to be created for Rosetta, to plan for the move of locales data.


CategorySpec

LocalesThatDontSuck (last edited 2008-08-06 16:38:19 by localhost)