openerp-expert-localization team mailing list archive
-
openerp-expert-localization team
-
Mailing list archive
-
Message #00063
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