Re: Google summer of code: i18n infrastructure

[Zejn Gasper <zejn@owca.info>]

On Thursday 11 May 2006 12:43, Gintautas Miliauskas wrote:
>
> Absolutely.  In fact, this news has motivated me to already start
> looking at the other large translation projects and their potential
> usefulness to the new system.  I plan to share my findings here (even
> if my project is not accepted in SoC).

One thing the debian people were sceptical about when evaluating pootle as a 
possible candidate was it's high ram usage. How is this expected to be with 
zope? Would integration to plone be possible?

I took a bit closer look at the pootle code and found they were using minidom 
for xml parsing, which is supposed to be quite memory hungry and slow. 
Instead of minidom I think it would be smarter to use ElementTree, which has 
a C implementation and a part of it is also going to be included in Python 
2.5. PO file parsing could be done in pure python or in with a help of C 
library, I was thinking about python-mxtexttools package. For spellcheck 
there's python-enchant (in unstable) and aspell-python which I dont think is 
in Debian yet. 

So there's a lot of things just waiting to get used.

One thing I am not sure about and probably needs more discussion is how would 
the storage get implemented; would it be a separate svn repository or just an 
API bridge to upstream repositories that would also implement format check 
and QC and so on. 

What I'm trying to say is that these decisions are quite political and pretty 
important for future developement of Debian's i18n infrastructure. One key 
thing to have in mind here is to create a single point of translation 
exchange, but not make it web interface only. So instead of creating another 
Rosetta we would create a bridge to link all the different storage backend 
that Debian uses to a single point for message exchange and a solid web based 
translation portal that would know how to use this bridge. This portal would 
have a svn repository for storage backend instead of bridge as this would 
also be alternative way of accessing translations for more technically 
knowledgeable and/or offline translators.

This is basically what my proposal for building Debian's i18n infrastructure 
was.

regards,
Gasper