Re: Work on a centralized infrastructure for i18n/l10n
conversion tool translation tool
original file <--------------> po file <---------------->
With this, package maintainers are free to use the format/tools they
want (xml with xml2pot, sgml with po4a, ...); translation teams
to use the translation tools they want (text editors, pootle, mail
Or XLIFF editors since there is curently a relatively stable po-XLIFF
conversion framework being developed.
This does not prevent us to propose translators to get the translation
material in whichever format they would like to use....this is what I
understand from your above scheme.
But is it necessary to convert all the localisable files to .po ? .po
is not a translation memory industry standard. It may work for most
of the gettext based localisation process but is not appropriate for
"the rest": documentation etc. Because the rest is based on XLIFF
(TMX) in the non-gettext world.