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

Re: Localization framework



Quoting Nikolai Prokoschenko (nikolai@prokoschenko.de):

> PROBLEMS: There is no way for a translator (who is usually not a geek or
> maybe even not a user) to get into the translation process easily. One
> possibility is to read tons of README's, man pages and help files to at
> least understand how he can get to the translation templates. IF, after
> learning CVS, SVN, 'apt-get source' and so on, he manages to translate
> _anything_, he has got a problem of committing this. This often requires
> write access to CVN/SVN or a bug report or some other weird way of getting
> work included. Even if this is done, there is no easy way to track the
> includsion of his work.

There is, for po-debconf. Mostly because using the BTS for "asking"
maintainers to include a translation is something we have to keep in
some manner. The BTS already has the ability to track things down, so
we probably don't need to re-invent the wheel.


But, I share some of your analysis on some points. We need to make our
possible to easy the process of grabbing things to translate and
putting them back in some system which could maybe do bug reports
automatically (be careful...DANGEROUS topic around.....all things
which lead to automatically mail Debian maintainers will for sure draw
up hot flaming).

Again, Denis Barbier system for po-debconf already exists. Just start
from this. The backend could then be the general SVN repository for
the given language of course instead of some daily picking in the
unstable archive.

> 
> SOLUTION: Debian needs a l10n infrastructure. It should be as easy to use
> for the translator as possible - most preferably something as
> uncomplicated as  SVN checkout -> KBabel -> translate -> SVN commit. This
> should be valid for everything to be translated, so that the translators
> do not get confused.

Maybe hiding the "dirty" work of checkout/chek in could also be a good
idea, thus having the l10n system doing the commits with some kind of
web or mail interface.

I have here to mention Michael Bramer's (grisu) project, named
DDTP. This is the project you mention somewhere.

DDTP was hit by the compromise and is still not up again.

IMHO, it was very well designed for the package description
translations, but less well for the debconf templates because there
mostly it dealt with templates from *binary* packages instead of
source packages.

But several tools in it where *very* interesting. The most interesting
part for me was that it allowed to completely interact with it by
*mail* with a set of simple commands (and the "ddtc" package from
Nicolas Bertolissio who helped Grisu a lot with the DDTP).

The DDTP suffers from a somewhat bad "image" among DD's because of
some communication problems when it was started. However, this does
not prevent the thing to be full of good ideas and good tools.




Reply to: