Re: [Fle3-dev] Migrating translation files to .po format

[Tarmo Toikkanen]

> I suggest the usage of the products "Localizer" which is used
> successfully by Plone

Thanks for the info. I looked at Localizer and it's a bit much for
what we need. A web based UI for the translation work isn't necessary,
I think. So there's lots of overhead in that product. Plus Fle3 would
be dependent of one more additional software, which makes installation
yet a bit more difficult.

On the other hand, the MessageCatalog class from Localizer has some
nice code for importing and exporting translations to/from .po files,
so that at least can be used (with appropriate credits). So we could
just move from python format vocabularies to gettext format (.po)
translation files.

Also Python has its own module gettext, which can handle .mo files
(compiled .po files) and product catalogs out of them. So using that
is one alternative.

One more issue to decide on is whether to continue using the short
keywords (as we do now) or the complete english strings. I ran some
tests and apparently Python's hashes are built cleverly enough so that
the length of the key string doesn't really affect performance. So we
could migrate away from the keywords, which would make the .po file
handling much simpler.

In the DTML files the change would be something like this:

CURRENT SYNTAX: <dtml-var L_keyword>

NEW SYNTAX: <dtml-var "gettext('Whole english string to be translated')">
       OR: <dtml-gettext>Whole english string to be translated</dtml-gettext>

Which is a bit more complicated (the method name "gettext" can be
something else), but we wouldn't need to explicitly write a new
keyword and its translation in the vocabulary.py for each new string
we make. On the other hand, having to do it explicitly makes each
modification more deliberate and thought-through.

Also, moving all the way to using .po files would really require that
we could use all the tools that can extract translatable strings from
source material (dtml files AND python files), identify them, notice
if they've changed and so on. Even Localizer had only limited support
for these functions.

Hmm, I can't see a clearly superior way of doing this. Any and all
ideas are still appreciated.

--
Tarmo Toikkanen
http://www.iki.fi/tarmo/
The Fle3 Team
http://fle3.uiah.fi