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 yet. - 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 ) 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)  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. Regards Javier 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!)  http://people.debian.org/~jfs/debconf6/html/x321.html#packages Although I need to update that section quite a bit  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.
Description: Digital signature