LocalesThatDontSuck

Differences between revisions 3 and 6 (spanning 3 versions)
⇤ ← Revision 3 as of 2005-10-01 17:10:05 →
Size: 1885
Editor: modemcable139
Comment: Provide more details
← Revision 6 as of 2005-11-01 21:50:19 → ⇥
Size: 2883
Editor: 209
Comment:
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
 * Priority: NeedsPriority
 * People: JeffBailey, JordiMallach		  * People: JeffBailey, JordiMallach, MartinPitt
Line 7: Line 6:
 * Interested: MartinPitt
 * Status: UbzSpecification, BrainDump (then DraftSpecification then EditedSpecification then ApprovedSpecification), DistroSpecification
 * Branch:
 * Malone bug:
 * Packages affected: locales, langpacks
 * Depends:
 * Dependents:
 [[FullSearch()]]
 * BoF sessions: none yet 		 * Status: DraftSpecification
 * Launchpad: https://launchpad.net/distros/ubuntu/+spec/belocs-locales
 * Packages affected: locales, langpacks, belocs-locales-data
Line 19: Line 13:
In order to server our user communities better, we need to be more responsive and proactive with localisation updates.  There are two solutions proposed here: In order to serve our user communities better, we need to be more responsive and proactive with localisation updates.
Line 21: Line 15:
1) Switch to using the belochs locales packages.

2) Use the belochs locales packages to seed Rosetta, and generate all localisation information from Rosetta.
Line 29: 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 33: 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.  * 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.

 * Locales maintainer wants to upload new locales, but does not want to force a rebuild of the entire glibc source.
Line 37: Line 31:
* Locales / Belocs-locales packaging  * Locales / Belocs-locales-data(universe) packaging
Line 39: Line 33:
* Langpacks  * Langpacks
Line 41: Line 35:
* Rosetta
Line 45: Line 38:
See also BreezyFirefoxStartPageTranslation. == Implementation ==
Line 47: Line 40:
== Implementation == First stage is to remove locales package from glibc build.

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.

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).
Line 51: Line 51:
Requires somewhat extensive packaging changes for the lang-packs.
Line 52: Line 55:

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.
Line 55: Line 61:
None
Line 56: Line 65:
----
CategorySpec

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

  • 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.
  • Locales maintainer wants to upload new locales, but does not want to force a rebuild of the entire glibc source.

Scope

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

Design

Implementation

First stage is to remove locales package from glibc build.

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.

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).

Code

Requires somewhat extensive packaging changes for the lang-packs.

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.

Outstanding issues

None

BoF agenda and discussion

CategorySpec

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