[Debian-l10n-devel] tdebs infrastructure
steve at einval.com
Sun Jun 1 15:01:52 UTC 2008
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?
>> > 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
>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
>> 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?
More information about the Debian-l10n-devel