Re: Summary of Debconf i18n/l10n activities
On 6/7/06, Javier Fernández-Sanguino Peña <jfs@computer.org> wrote:
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:
Hi jfs,
Thanks for the summary i'm ccing debian-i18n@ too.
- 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.
Sure, i think that's what debian-18n is discussing to implement using Pootle.
- 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)
I thought it would be a good reason (there are others) to move
'volatile' to our infrastructure, if the reponsible people agree, of
course.
- 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]
Yeah, no way for overwrite stuff in '/usr/share/locale'.
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.
(...)
Me too, but while the whole translation infrastructure subject is hot,
it's valid discuss how we will benefit from this with our releases in
mind, keeping the translations updated and in a high quality. :-)
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.
thanks,
-- stratus
Reply to: