[Debian-l10n-devel] tdebs infrastructure

[Steve McIntyre]

On Sun, Jun 01, 2008 at 01:11:38PM +0100, Neil Williams wrote:

<snip>

>(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?

>> > A few ideas (please comment, point out if you think they're
>> > obvious/dumb/won't work!):
>> > 
>> >  * I'm thinking it would be really useful to pick out translations
>> >    from uploaded files and put them in a central database/VCS. That
>> >    could allow all kinds of useful things...
>> 
>> Sure, organising some meta-stuff around this would be good. Indeed, I
>> don't really see "translators" building the tdebs. We/they would
>> interact with some friendly tool offering them strings to translate,
>> or PO files, and the tdebs would be built from that material by a
>> dedicated infrastructure.
>
>(Anyone willing to write such a tool is welcome to start asap - don't
>wait for me to do it. :-) I'm happy to include whatever rules are
>necessary for the pseudo-source packages to autobuild.)
>
>I envisaged the debian i18n translator teams appointing a person to
>upload TDebs after the usual review process was complete rather than
>giving upload privileges to all translators. Submissions via a web
>interface may still need review by the existing debian i18n teams.

Yup, we'll definitely need review/moderation. Let's try and avoid
people adding insults in "translations". It's a shame, but I just know
that could happen if we're not careful.

>> >  * If we have a database, that will allow us to more easily track
>> >    translations that have been made and new translations that are
>> >    needed.
>> 
>> Yep. That's the overall idea of Pootle (i18n.debian.net:8080)
>> 
>> >  * Using the database, we could build a web app that will allow people
>> >    to do translation for us without needing to get learn the big,
>> >    scary technical workflow that can be involved in package
>> >    maintenance. We could pull out a few strings at a time and ask the
>> >    user to translate. Add those new translations to the list for
>> >    people to moderate/review for the next upload. Maybe even automatic
>> >    builds/uploads directly from the database?
>> 
>> Pootle..:-)...we don't need to build anything, it's there. We need to
>> feed it, actually (and have it survive the huge amount of data it
>> could have to deal with.....that was tried with Packages Descriptions translations).

OK. I'm glad that I'm not the only person to have thought of some of
this. :-) Apologies, I should have looked into this more first.

>> >  * We should add specific support into our archive and package tools
>> >    to work out appropriate versions of translations to use. The
>> >    versions will have to be slightly more fuzzy than our normal
>> >    packaging relationships; this will allow for some disconnection
>> >    between the versions of packages and their translated strings, so
>> >    that we're not forced to bump versions if they're not needed.
>> > 
>> > Thoughts? :-)
>
>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.

>> You very well understood the problem, imho. My current feeling is that
>> we're now ready to go into the deep of these ideas. A first move could
>> be done at Debconf, in the i18n "sessions" I proposed. What would be
>> good could be to dedicate a few of these to the tdebs idea and bring
>> there folks who have the knowledge of the archive management tools
>> (FTP team, release team maybe).
>
>I'll be at DebCamp as well as DebConf this year so there will be time to
>work on these things.

I'd love to join in, but I'm not there for DebCamp myself. I'm sure
we'll get more time to talk about it, anyway. :-)

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
Who needs computer imagery when you've got Brian Blessed?