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

Re: Google summer of code



On Wednesday 03 May 2006 06:58, Christian Perrier wrote:
> (keeping CC for the moment. I suggest to keep -project CC'ed as long
> as the topic is still close to Google Summer of Code)
>
> Quoting Martin Michlmayr (tbm@cyrius.com):
> > * Gasper Zejn <zejn@owca.info> [2006-05-02 22:36]:
> > > I intend to apply for Google's summer of code for Debian's I18N
> > > infrastructure plan. Is there somebody I should discuss this with or
> > > should I just submit the application?
> >
> > Reviewing the discussions that happened on the debian-i18n list
> > recently would certainly be a good idea.
>
> I was thinking about GSoC for the recurrent topic of i18n
> infrastructure.
>
> However, our ideas about it are currently not clear. The planned i18n
> meeting in Extremadura/Spain next September is mostly aimed at drawing
> these ideas into a real plan to have something setup.
>
> I also want to take the opportunity of the Debconf next week to throw
> out early ideas and prepare that meeting.
>
> Up to now, various existing solutions have been evaluated and
> discussed, such as Pootle, transdict or even Rosetta. But, my own
> personal opinion is that going for this or that tool befre having a
> clear idea of what we need is a bit wrong.

I agree with this. 

I've also read the paper to be presented at Debconf, and it's a good reading 
to see what the current status is. 

That's why I've been thinking about this for some time now. This is how I see 
translation "portals" in next few years.

Translation portals are going to evolve from centralized to distributed, with 
each portal serving only a couple of languages. This will lead to only one 
portal for one language, but with good quality, instead of one for every 
project, eg. Rosetta for Ubuntu and the new web portal for Debian.

That's why Debian should consolidate access to messages needing translation 
through one central point, be it a central subversion repository or a more 
advanced "message exchange" server that would work directly with different 
backends and would not require to synchronize messages from this repository 
with upstream (eg. for d-i messages with d-i svn repository).

After this step, access to messages is greatly simpified. This can then be 
used as a base for web based translation portals. They could be hosted by 
Debian or, if translator community for a specific language is strong enough, 
by translator communities and messages would get exchanged by a yet unknown 
protocol. This would shift a lot of hardware burden away from Debian and 
could greatly help improve quality of translations with help of capable 
computer aided translation software, that would use translation memory along 
with policies for different projects, eg. KDE has different terminology than 
GNOME. And some governments fund l10n and i18n of open source software so 
such a translation server could improve odds for funding.

These "portals" also need to take care of translation "robots", or better said 
the lists that help coordinate translators and message status. We need this 
because some prefer mailing lists, other web interfaces. For those who prefer 
mailing lists, such a portal would need to support versioned messages, 
probably the most simple solution here actually is subversion repository. 
Those who translate through web portal, the server software would 
automatically commit translations for them, others who use mailing lists 
would lock translations for them through mailing list robots, checkout their 
messages and, after translating them, manually commit them back.

I see this Summer of code as a great opportunity to speed things up. Debian 
gets nearly 3 months of full time work for their i18n project, and I get a 
stipend for doing something that I would probably anyways start doing, it 
just gets done sooner as I don't have to seek for paid job elsewhere.

Regards,
Gasper Zejn



Reply to: