Translating ODF files on Pootle

l10n
#1

Hi,

Von: Rimas Kudelis
Gesendet: 27.12.10 15:10 Uhr

Are you sure? There were plenty of placeholders in the file exported by
Sophie. To me, it looks like most of the problem is actually in Pootle
itself, because it simply ignores XML tags in the translatable string.

The problem might look "simple" - but afaik, all (but one) free translation
editors share the same problem.

Pootle has the problem, I'd bet virtaal (based on the same toolkit) has the
same problem. Wordforge Editor removes the inline tags (just tested). OLTE
removes them (spent some days on trying to find a solution, but it woult mean
a major redesign of the internal translation handling in the editor).

Afaik, only Lokalize handles inlines correctly. I did not check other
tools like OmegaT yet.

So after all, for document translation XLIFF is the better (because more rich)
file format, but it lacks the tools :frowning:

regards,

André

#2

Hi André,

2011.01.06 17:06, Andre Schnabel rašė:

Are you sure? There were plenty of placeholders in the file exported by
Sophie. To me, it looks like most of the problem is actually in Pootle
itself, because it simply ignores XML tags in the translatable string.

The problem might look "simple" - but afaik, all (but one) free translation
editors share the same problem.

Pootle has the problem, I'd bet virtaal (based on the same toolkit) has the
same problem.

Nope. In fact, I was explicitly suggested by Pootle/Virtaal's authors that we use Virtaal for XLIFF because of much better support for this file format.

Wordforge Editor removes the inline tags (just tested). OLTE
removes them (spent some days on trying to find a solution, but it woult mean
a major redesign of the internal translation handling in the editor).

Afaik, only Lokalize handles inlines correctly. I did not check other
tools like OmegaT yet.

So after all, for document translation XLIFF is the better (because more rich)
file format, but it lacks the tools :frowning:

Rimas

#3

André,

Yes, it was a problem of the toolkit, and they just fixed it. We will apply the patch in WordForge, as we are still using the same code.

This does not really solve the problem, which is to get a working filter for ODF-XLIFF, but so far it can be done with Omega-T

The main issue with the toolkit is that it does not keep the structure of XLIFF files internally, but it creates its own internal representation. If something is not specifically represented internally, then it is not stored, and therefore not saved back in the file. This is why WordForge ia moving away from the toolkit, because not being native to XLIFF it is very hard to work on implementation of XLIFF features.

Lokalize does not have this problem because it keeps all the data of an XLIFF file, independently of understanding it or not.

Javier

Rimas Kudelis wrote:

#4

So, OmegaT and Lokalize can handle this conversion and WordForge might
handle it in future if necessary code updates are added (after using patches
for the toolkit)? Seems ok.

How could then the workflow for localizing ODT files look like? Could
ODF-XLIFF transformation be offered by the translation system (Pootle?) so
that the user does not bother with that? Localizers would localize XLIFF
files (how does that relate to localization of pictures and other objects in
the ODF?).

Lp, m.

#5

So, OmegaT

Sorry, I confused the names, not Omega-T, but Okapi, for the ODF to/from XLIFF filters.

Lokalize, WordForge 0.8RC1 and Virtaal should be able to handle the XLIFF files.

and Lokalize can handle this conversion and WordForge might
handle it in future if necessary code updates are added (after using patches
for the toolkit)? Seems ok.

How could then the workflow for localizing ODT files look like? Could
ODF-XLIFF transformation be offered by the translation system (Pootle?) so
that the user does not bother with that? Localizers would localize XLIFF
files (how does that relate to localization of pictures and other objects in
the ODF?).
  

Once good filters are available, they will probably be integrated in the different tools that can handle XLIFF. We will definitely do it for WordForge.

Integrating Okapi is a little complex at the moment because the filters are in Java, and this means integrating new dependencies or converting the code to Python.

The question about pictures is interesting. Editing text or culture in images is not something that editors will be doing in the short run (an image editor like Gimp is necessary), but at some point it will be important to be able to display pictures attached, to clarify the text.

Cheers,

Javier

#6

Javier Sola <lists <at> khmeros.info> writes:

> So, OmegaT
Sorry, I confused the names, not Omega-T, but Okapi, for the ODF
to/from XLIFF filters.

OmegaT does not require XLIFF to translate ODF. And you still get a
TMX memory from the process. The TMX can later be used for other
parts of the localization process.

Jean-Christophe Helary
OmegaT l10n manager

#7

Hi Jean-Christophe,

OmegaT does not require XLIFF to translate ODF. And you still get a
TMX memory from the process. The TMX can later be used for other
parts of the localization process.

I seem to recall that OmegaT doesn't handle numbering styles very well,
or at least it didn't when I last tried it a few months ago. This was
the real blocker for me with regard to OmegaT , but maybe it is just my
inexperience with using it.

Alex