Re: Google summer of code: i18n infrastructure
- To: firstname.lastname@example.org
- Cc: Gintautas Miliauskas <email@example.com>
- Subject: Re: Google summer of code: i18n infrastructure
- From: Zejn Gasper <firstname.lastname@example.org>
- Date: Fri, 12 May 2006 09:15:48 +0200
- Message-id: <email@example.com>
- In-reply-to: <firstname.lastname@example.org>
- References: <email@example.com> <20060511061953.GA19876@djedefre.onera> <firstname.lastname@example.org>
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