LocalesThatDontSuck

Differences between revisions 8 and 13 (spanning 5 versions)
⇤ ← Revision 8 as of 2005-11-02 22:07:32 →
Size: 4024
Editor: 209
Comment: Review
← Revision 13 as of 2005-11-04 01:43:32 → ⇥
Size: 5222
Editor: 249_220_103_66-WIFI_HOTSPOTS
Comment: some comments from approver
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
 * Status: DraftSpecification
Line 33: Line 32:
 * Langpacks

{{{XXX:Does it affect all of every langpack? Surely not ;-) -- smurf}}}		  * Langpacks: postinst/postrm scripts, additional content (ship locale data)
Line 39: Line 36:
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.  * 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 41: Line 38:
 * Factor out code from the language pack maintainer scripts to a common package `locales`.
Line 44: Line 42:
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.  0. Remove locales package from glibc build. The locales binary should instead be built from a small separate source package, in order to make fixes and changes easy. The locale-gen, and {install,remove}-language-locales scripts from the old locales package would need to be moved to that separate package. The locale-gen script needs to be modified as noted below.
  * ColinWatson: belocs-locales-bin contains /usr/sbin/locale-gen. What are we doing with this?
 
 0. Completely remove the currently existing debconf question, since it is unnecessary. Locales get installed and removed automatically.
  * ColinWatson: This implies that either (a) everyone must install language-pack-* to get locales, and the locale data shipped in belocs-locales-data is irrelevant except for import into Rosetta, or (b) belocs-locales-data ships with all locales enabled, which would be rather space-intensive. The comment below suggests that the state is (a) - but is there any way we can arrange for people to be able to get locales (e.g. for locale categories other than LC_MESSAGES) without having to download and install the rather larger language packs?
Line 46: Line 48:
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 therein (which may be more than one, for e.g. english, there is en_US, en_CA, etc).  0. Move the belocs-locales data into language packs build.
Line 48: Line 50:
{{{XXX: Would the existing locale selection dialog, with its large list of glibc locales, be kept-as-is / truncated-to-installed-locales / removed? -- smurf}}}  0. language packs ship a file /etc/locales/supported.d/<lang-code> (which is a subset of the former /usr/share/i18n/SUPPORTED file).
 
 0. language-pack postinst/postrm script just call a common hook provided by the locales package in order to factor out code from the current maintainer scripts. This allows us to hook other actions into the installation process in the future (e. g. desktop file translations).

 0. The common postinst script calls `install-language-locales` ''lang-code''. The common postrm script calls `remove-language-locales` ''lang-code''.
Line 51: Line 57:

  
Line 55: Line 60:
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>.

{{{XXX: Exactly what needs to happen? -- smurf}}}
  * langpack-o-matic already provides the mechanics for shipping additional data in the language packs. This will be used to ship the locale data.
 
Line 61: Line 64:
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 the missing part needs to be investigated for inclusion as well. It may be that ones missing from belocs just don't work, or are no longer needed. 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 the missing part needs to be investigated for inclusion as well. Those missing from belocs are very probably not longer needed for various, justified reasons (countries changing name, ISO 639 code updates...).
Line 63: Line 66:
Specifically, several locales in Breezy were marked to be removed after the "Sarge" release. These should not be carried forward.

 0. Release Notes: Point out that the user has to manually fix his locales when he manually added locales without the corresponding language packs installed.
Line 72: Line 78:
== Outstanding ==

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: postinst/postrm scripts, additional content (ship locale data)

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.

  • Factor out code from the language pack maintainer scripts to a common package locales.

Implementation

  1. Remove locales package from glibc build. The locales binary should instead be built from a small separate source package, in order to make fixes and changes easy. The locale-gen, and {install,remove}-language-locales scripts from the old locales package would need to be moved to that separate package. The locale-gen script needs to be modified as noted below.

    • ColinWatson: belocs-locales-bin contains /usr/sbin/locale-gen. What are we doing with this?

  2. Completely remove the currently existing debconf question, since it is unnecessary. Locales get installed and removed automatically.

    • ColinWatson: This implies that either (a) everyone must install language-pack-* to get locales, and the locale data shipped in belocs-locales-data is irrelevant except for import into Rosetta, or (b) belocs-locales-data ships with all locales enabled, which would be rather space-intensive. The comment below suggests that the state is (a) - but is there any way we can arrange for people to be able to get locales (e.g. for locale categories other than LC_MESSAGES) without having to download and install the rather larger language packs?

  3. Move the belocs-locales data into language packs build.

  4. language packs ship a file /etc/locales/supported.d/<lang-code> (which is a subset of the former /usr/share/i18n/SUPPORTED file).

  5. language-pack postinst/postrm script just call a common hook provided by the locales package in order to factor out code from the current maintainer scripts. This allows us to hook other actions into the installation process in the future (e. g. desktop file translations).

  6. The common postinst script calls install-language-locales lang-code. The common postrm script calls remove-language-locales lang-code.

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

Code

  • langpack-o-matic already provides the mechanics for shipping additional data in the language packs. This will be used to ship the locale data.

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 the missing part needs to be investigated for inclusion as well. Those missing from belocs are very probably not longer needed for various, justified reasons (countries changing name, ISO 639 code updates...).

Specifically, several locales in Breezy were marked to be removed after the "Sarge" release. These should not be carried forward.

  1. Release Notes: Point out that the user has to manually fix his locales when he manually added locales without the corresponding language packs installed.

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.

Outstanding

CategorySpec

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