[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Summary of Debconf i18n/l10n activities

On Tue, Jun 06, 2006 at 03:21:45PM -0300, Gustavo Franco wrote:
> Nice, thanks. While we're at this subject, what's your view on the
> Ubuntu language packs? Are we going to extract the translations from
> the packages creating language packs? It has pros and cons, and
> the best thing i see is the possibility to keep translating stuff after
> release. Thoughts?

I don't know if people have a wrong impression of what language packs in
Ubuntu are, I sure did until I looked at the Spanish language pack. It
(language-pack-XX) actually is a package that pulls in:

- a package (language-pack-XX-base) that provides update locales for *some*
  applications under /usr/share/locale-langpack/ and uses
  '/usr/sbin/install-language-locales' in postinst. 
[ This package Recommends: ]
- a meta-package (language-support-XX) that pulls in translations for
  OpenOffice, Mozilla (Firefox) and the proper dictionary information
  (aspell-es, wspanish)

Glibc is patched in Ubuntu (./debian/patches/ubuntu-altlocaledir.dpatch) to
use /usr/share/locale-langpack/ as an alternate PO location.

Now, if we wanted to do that in Debian we would need to:

- have translation teams be able to check, review and update locales for
  *sarge* packages (Ubuntu uses Rosetta). This infraestructure we don't have

- Create the said packages (and maintain them). This maybe needs to be
  through an automated procedure, since the new translations are probably in
  the main package too.

- Relax our policy regarding proposed-updates (since that's where translation
  packs would go to). I don't know if the Stable release managers are open
  to this (but we could try)

- Patch glibc like Ubuntu did (I don't know if that patch would get approved
  by our glibc maintainers) to use that location.

We already cover the meta-package idea (depending on OpenOffice, Mozilla and
dictionaries) through tasksel at installation. And we abandoned the idea of
using meta-packages Depending: on translations because of all the
interdependencies issues (see [1])

If we don't do all of this we are stuck with only being to provide
translation-packs (during or post release) with ugly hacks like overwritting
files under /usr/share/locale/ (or wherever the program's localised
information is) *after* a package installation (and not because of it) [2]

Quite sincerely, I don't see that feasible for etch right now. If someone
wants to start the ball rolling, however, it's worth a try.



PS: We could even do better than Ubuntu and provide proper (c) statements in 
language-pack-XX-base, since that package's copyright states is (c) Canonical
but the translations in those packages are, quite sincerely, not (c) them.
They are (c) their translators in most cases (I know, I've done some of
them myself!)

[1] http://people.debian.org/~jfs/debconf6/html/x321.html#packages
Although I need to update that section quite a bit

[2] That is, unless you have packages that have a setup similar to KDE's (a
main package with the code and separate kde-i18n-XX packages with their
translation), Mozilla or OpenOffice (localised information in separate -XX
packages). That's probably why Ubuntu's localised-packs packages just Depend:
on them to get the updated translations.

Attachment: signature.asc
Description: Digital signature

Reply to: