← Back to team overview

openerp-expert-localization team mailing list archive

Translating OpenERP with Transifex.

 

Given the serious disadvantages of Launchpad for translations, I have spent a 
couple of hours testing an alternative: Transifex.

First note: the way Transifex v0.9 (the "production one") has been scanning 
the project directories with a glob, was unsuitable, so the attempt to use 
that one ended (a few monhts ago) prematurely.

Now, I discovered that the beta site of the *v1.0* upcoming release of 
Transifex would allow me to do a few tests and see if it suits us.

Transifex is free software, GPL, which we could theoretically setup in our own 
infrastructure, if ever needed. However, the dependency on Django and specific 
versions of its addons, make for a very narrow choice of server versions, and 
a generally difficult installation.

Transifex v1.0 features a very nice design, where the project management is 
done with a command-line tool running at the project maintainer's side. This 
tool will push the translations from the .pot and .po files to Transifex as 
needed, and then pull back any changes that are registered with the site.

( I will refer to Transifex as "TX" from now on..)

see: http://beta.transifex.net/projects/p/OpenERP/

Same drawback as with LP, TX seems /not/ to do any version-controlling of 
translations, that could be imported back to the project. So we fail one of 
the major requests for a translation tool.

Fortunately, so far, TX does not append any stupid copyright headers, that 
they own our translations, our project or anything. Nice.

I personally find the TX user interface simple and fast, your opinion may vary.

TX allows, through the cli, to register an arbitrary number or schemas of 
translation "resources". So, we can have server, clients, addons, extra addons 
etc. under a single "OpenERP" project. We can even use a prefix or a suffix, "-
xrg-60" in my tests, to mark different versions/series. Good, but I would 
prefer to have native support for variants of the same resource. 

Another nice feature of TX is the .po file upload/download capability. However, 
for uploads, I cannot tell if it handles merging multiple submissions 
correctly. 

Sadly, TX does not support "fuzzy" strings, by design. This means that it 
would _remove_ all translations that are incomplete, from the sources. This, 
IMHO, is a strong negative point, since work of people may be lost this way. 
Similarly, it would remove "merged" translations and multiple/deprecated ones. 
(note: I think LP does the same, doesn't it? )

Conclusion: Transifex is a sleek tool, free from the monopoly of MS. But it 
shares the same disadvantages that LP has suffered; it will not save our day. 
Both tools cannot get as close as maintaining the translations with a real VCS 
system[1]. However, I would gladly switch to whatever system would be the 
_best complement_ to the VCS-based translations.

[1] using a few hooks and configurations in my git repos, I have managed to 
efficiently keep track of non-linear translation history for my language. One 
main criterion was to have a system where all authors would be properly 
attributed, and that non-linear (eg. disputes, merges, splits) operations 
would be possible.

-- 
Say NO to spam and viruses. Stop using Microsoft Windows!



Follow ups