[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Google summer of code: i18n infrastructure



Hello,

> everybody agrees that l10n in Debian has to be improved a lot, thanks
> for working on this.  I will explain below my view on this topic.

As I said, I am very interested in any kind of input.  In fact, I see
it as part of my task to hear out all the different opinions and
reconcile the differences.

> This is not a criticism on your proposal, but rather an informal

Oh, don't worry about that, I can usually take criticism well ;)

> discussion. If your proposal is accepted as is, Debian will benefit
> from your work, but I believe that it can be even more useful ;)

Actually, I view the proposal as a some kind of a "vision", a coarse
plan on how the system will look, and I see no obligation to stick to
the letter if we all agree on the change.  I am certain that a lot of
things currently documented in there will change (they always do).

> Yes, this has been discussed several times, teams should work together
> to improve efficiency.
> Our ultimate goal is not to translate because it is fun, but to
> provide translations to our users, so how translated material is
> published is an important piece of the whole picture.

Agreed.  I would say that the goal of translating is to provide the
translations to users of Debian, but I would like to point out that fun
has a lot to do with why people do translations.  I did not intend to
stress the latter in the proposal though.  My very high-level plan:

(a) make something usable
(b) adapt it to the Debian processes
(c) make it fun (after (b) is acceptable!)

Basically "fun" contributes to the quantity and "processes" contribute
to the quality of translations.  I know the focus of Debian on quality
and I agree wholeheartedly on this point.

> You should read the (huge) thread initiated by
>   http://lists.debian.org/debian-devel/2003/02/msg01924.html
> it is very instructive.  The situation has not changed for 3 years,
> so your infrastucture will face problems similar to the DDTP if
> nothing is planned to work with developers.

For starters, I believe I mentioned the intent to automate in part the
interaction with the Debian BTS.  Does that count?

> In most other large groups, translators have direct access to a
> central CVS/SVN repository, but this will not happen in Debian.

Could you explain this strong statement?  Is it a matter of principle
or just technical reasons?

By the way, I have mentioned on the webpage that it might in fact be
possible to provide a WebDAV frontend (used by Subversion) so
translators who prefer this way could actually work with the project
using Subversion.  I do not want to make guesses how difficult this
would be.

> Several people involved in the thread above reported that l10n is
> quite similar to buildd, and an infrastructure similar to
> buildd.debian.org could help language coordinators to track ignored
> l10n bugs and perform NMUs if necessary.  There are new BTS features,
> like
>   http://lists.debian.org/debian-i18n/2006/02/msg00013.html
> which can be very helpful.

A comparison with buildd makes sense.

Actually. some of my ideas start with the translation bot
(see http://dutch.debian.net/).  I was thinking of something similar,
but more general and more integrated:

* (external) scripts that process a package, extract localisable text
  and upload it to the system.  Could be hooked up to automatically
  process newly uploaded packages.  Different packages may need
  different treatment, but I think that a few simple heuristics
  (find .po files) should be able to handle the majority of cases.
* a web interface to check the status of the translations
* interfaces for submitting translations (web: submit .po / translate
  individual strings, e-mail, possibly others)
* interfaces for reviewing translations (web, e-mail)
* module that interfaces with the BTS, which automatically files and
  tracks l10n bugs on behalf of the translator.  This could be extended
  to talk directly with GNOME/KDE/whatever bugtrackers too to reduce
  hassle for DDs.
* notification module (probably e-mail service and a web "dashboard")
  that notifies translators about new untranslated/unreviewed strings,

That's a lot of work, but hey, I'm just brainstorming.

One thing that has been bothering me a little is the versioning of
translations.  Is there a point in keeping different translations (for
the same language) on the same package?

> Of course you cannot implement everything in 3 months, this is not
> the point, but IMO we have to keep an eye on the whole picture when
> designing a new l10n workflow.

Your comments are highly appreciated.

There is a lot of related information to sift through, so please
forgive me if I have not yet read something you deem important.

By the way, I do not intend to disappear after the 3 months have
passed.  I am not a DD, and my free time may shrink in autumn because of
studies, but if I get this beast running, I am *not* dropping it!  Might
as well apply for a Debian developer then.

-- 
Gintautas Miliauskas
http://gintasm.blogspot.com

Attachment: signature.asc
Description: PGP signature


Reply to: