How to structure a XLIFF export to be usable by a translator?

Question

The main question is: How should I build the structure of the XLIFF to be usable?

What I have:

A Symfony (3.4) project where I want to export the translatable content as XLIFF. I don't mean bundle translations, but dynamic content from the database.

I have written a bundle so far that uses the MessageCatalogue to collect the content and the XliffFileDumper to write the XLIFF file.

This gives me a flat XLIFF with the content to be translated. I guess this is not very usable. Example: Pages have content. At the moment I just collect all content in a flat XLIFF. Giving this file to a translator, he/she wouldn't know which content belongs to which page. This is bad, right?

The MessageCatalogue => XliffFileDumper method I use at the moment seems a bit limited in this way. I can add metadata (notes), but I can't use groups for example. It seems also not to be possible to add more than one segment to a unit. What I can set is a "domain" which results in <file id="content.fr"> tag (domain=content) for example.

I would be great to build a useful XLIFF this way, but tell me if I can't. Than I need to write a customized XLIFF dumper.

Ideas: I could use one domain per page, which results in many files? Good practice? I could add information about the parent page in the metadata / notes. Could a translator even make use of it?

What would be the best practice for file structure? If anybody knows a symfony bundle that is helpful, please tell me.

Answer 1

You cannot build a best practice based, useful XLIFF given the current dumper limitations you stated.

If you are going to refine the dumper I recommend reading this first https://galaglobal.github.io/TAPICC/T1/WG3/rs01/XLIFF-EM-BP-V1.0-rs01.xhtml

Based on the above, make the new dumper parametrize output as XLIFF 1.2, XLIFF 2.1, or XLIFF 2.0. XLIFF 2.1 http://docs.oasis-open.org/xliff/xliff-core/v2.1/os/xliff-core-v2.1-os.html is the latest release backwards compatible with XLIFF 2.0 but NOT backwards compatible with XLIFF 1.2. XLIFF 1.2 support in CAT (Computer Aide Translation) tools is still bigger than XLIFF 2, but XLIFF 1.2 is no longer maintained by the OASIS Technical Committee.

Your new dumper should support recursive grouping and decoration of the extracted files/groups/units with source asset metadata, see the best practice document above on how to do it. If you do it so, the CAT tools will be able to display it to translators who will find it very useful. Basically each structural element has a dedicated attribute to store the id of the extracted resource, @original on file, @name on group and unit. U can also store a private nmtoken: prefixed string in @type. In case this is not enough u can store more round-trip data in the skeleton, or resource data module.. both can be internal or external.

Also recommended to start with XLIFF 2 core and only add module data after you've succeeded with the core roundtrip.

A very useful and easy to implement module is the fs module that makes it easier to generate HTML previews for translators. Notes <note> should not be used for roundtripping metadata only for human readable instructions/warnings/comments for translators.

As you guessed, the dumper should be able to create a hierarchical structure. You don't need to bother with segmenting the units. But it's OK to create units with more segments. Look again at the best practice document to see when it makes sense.. You should be always able to receive back a different number of segments within any unit. Content must not migrate across unit boundaries though.

The segmentation encoding within a unit is the major difference between XLIFF 1.2 and XLIFF 2. You need to look into the specs for details.