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

Re: Google summer of code: i18n infrastructure


I have been away for a short while, 

> On Friday 12 May 2006 14:03, Gintautas Miliauskas wrote:
> > * 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.
> Basically, I don't think it's smart to translate KDE and GNOME with
> Debian's infrastructure. Ubuntu has problems because a i18n team for
> eg. Catalan translates GNOME/KDE, but someone also translates some
> strings through Rosetta and Rosetta ofcourse overrides upstream
> translations. It could work for bugtracking, but it would probably
> lead to same problems for translating.

I think that Rosetta started well with the web translation interface,
but dropped the ball when it came to i18n integration processes.  The
desynchronisation was caused by the fact that it did not have any
automated 'push' functionality (or pull from upstream CVS), which I
propose here.

> > 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?
> That is also one of the problems Ubuntu had with Rosetta in early
> stages. Somebody comes and "corrects" few messages, but since
> translations weren't versioned, it was a bit harder to restore them
> back.

I had a slightly different kind of versioning in mind, not the one
about reverting changes to a previous state, but the one when you want
to have several translations in parallel, say, for a version of a
package in stable and for a version of a package in unstable.  Or have
a generic translation (that never conflicts with upstream) and a Debian
translation where all the changes from the generic version are
completely Debian specific.

> A nice feature would also be translation memory and translation
> policies. If one would one day go so far to implement smart
> translating with machine learning, versioned translations would come
> quite handy. Or at least versioned in such way to see what the

These are basically interface issues (therefore they do not concern me
much right now), nevertheless, the ideas are interesting and I will have
them in mind.  Thanks a lot for your input!

Best regards,
Gintautas Miliauskas

Attachment: signature.asc
Description: PGP signature

Reply to: