[Debian-l10n-devel] tdebs infrastructure

Neil Williams codehelp at debian.org
Sun Jun 1 15:37:27 UTC 2008

On Sun, 2008-06-01 at 16:01 +0100, Steve McIntyre wrote:
> On Sun, Jun 01, 2008 at 01:11:38PM +0100, Neil Williams wrote:

> >(Also note that after discussions with Frans Pop at FOSDEM, Emdebian
> >TDebs are *architecture-dependent*. It is undecided whether Debian TDebs
> >should be also, but the consensus so far appears to be that the overhead
> >of converting the binary .mo file at runtime is less of a problem than
> >instantly multiplying the number of TDebs by 12. Emdebian uses
> >architecture-dependent TDebs because we have only 250 source packages,
> >not 20,000. Even so, Emdebian currently has 1,625 TDebs from just 250
> >source packages and that is only for one architecture, ARM. That could
> >easily translate to over 100,000 TDebs for Debian or 1.2 million if
> >Debian TDebs were architecture-dependent.)
> Eek! :-) What's arch-dependent about the .mo format?

It's a binary format, so there are endian-ness problems which are
normally handled at runtime. For embedded devices, it's worth avoiding
that overheaad.

> >This reflects the reality that a lot of packages have multiple uploads
> >into Debian and often a few new upstream releases, without any of the
> >translated strings being changed and without any new PO files being
> >added.
> >
> >Part of implementing TDebs in Debian will be modifying debhelper and/or
> >debian/rules to not install anything in /usr/share/locale/ but to leave
> >that job to the TDebs. The Debian maintainer would then only need to
> >upload any TDebs him/herself *if* the package is NEW or if the
> >translations are known to have changed. We need to prevent maintainers
> >uploading old translations that then replace updated TDebs because the
> >Debian upload has a higher version string.
> Would we *ever* expect a normal maintainer to upload tdebs alongside
> their normal package? I'd expect not - they should be added separately
> afterwards.

OK, that needs scriptage that can get any updated PO files from the new
upstream source tarball, compare with the current TDeb and decide how to

Which brings me to the Translation Project:

I've tried that as upstream myself and it is painfully slow and I'm sure
Debian can do a lot better. In the meantime, some form of coordination
with upstream is going to be needed. That will be the main part of
development needed before we start using TDebs in Debian.

Neil Williams <codehelp at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/debian-l10n-devel/attachments/20080601/1370d98a/attachment-0001.pgp 

More information about the Debian-l10n-devel mailing list