Hi,

I'm one of the developers at OnTheGoSystems, the creators of WPML.

We decided to deliver this basic solution (dump the content into CDATA blocks without any processing) to help our clients to extract content from the websites and avoid a lot of copy/paste work. We are aware that XLIFF files we generate are not perfect (but still valid according to XLIFF 1.2 specification). We are checking solutions to improve it for some time but still do not have anything that would guarantee that we will be able to recreate translated page (based on the XLIFF with previously extracted and segmented content) without any issues. We do not want to release anything that would generate even more problems for our clients and translators.

We are really interested to make our clients and translators live easier. As mentioned by Paul, the problem is that it is a very tricky task to extract only text from the content, generate sentences (segmentation), generate trans-units and put it back together when translation is ready. This is the result of how WordPress itself is designed and how data is stored in WordPress database (content mixed with HTML tags). We can not forget that this should work not only for English but also for all other languages (different segmentation rules).

WPML 3.6 release brought a lot of improvements including better support for content generated by Page Builders. Thanks to that you won't see a lot of shortcodes ([] tags) in your XLIFFs anymore.

I'm pretty sure that we will finally find also a solution to generate XLIFF files that will make translators happy.

I will keep you posted :)

Pawel

Hi,

I'm one of the developers at OnTheGoSystems, the creators of WPML.

We decided to deliver this basic solution (dump the content into CDATA blocks without any processing) to help our clients to extract content from the websites and avoid a lot of copy/paste work. We are aware that XLIFF files we generate are not perfect (but still valid according to XLIFF 1.2 specification). We are checking solutions to improve it for some time but still do not have anything that would guarantee that we will be able to recreate translated page (based on the XLIFF with previously extracted and segmented content) without any issues. We do not want to release anything that would generate even more problems for our clients and translators.

We are really interested to make our clients and translators live easier. As mentioned by Paul, the problem is that it is a very tricky task to extract only text from the content, generate sentences (segmentation), generate trans-units and put it back together when translation is ready. This is the result of how WordPress itself is designed and how data is stored in WordPress database (content mixed with HTML tags). We can not forget that this should work not only for English but also for all other languages (different segmentation rules).

WPML 3.6 release brought a lot of improvements including better support for content generated by Page Builders. Thanks to that you won't see a lot of shortcodes ([] tags) in your XLIFFs anymore.

I'm pretty sure that we will finally find also a solution to generate XLIFF files that will make translators happy.

I will keep you posted :)

Pawel

Unknown said:

We are aware that XLIFF files we generate are not perfect (but still valid according to XLIFF 1.2 specification).

Pawel Wawrzyniak: You are missing a fundamental point - the content of the file is what makes the file "logically valid" and processable, not the structure itself and its compliance with specification.

If I create Word file with binary noise inside (see screenshot below) and save it, I get perfectly valid DOCX file, which will pass all Office OpenXML format validations.
But the file is still useless because of the nonsensical content. And that's what is happening with XLIFFs produced by WPML.

Document1.docx

Unknown said:

the problem is that it is a very tricky task to extract only text from the content, generate sentences (segmentation), generate trans-units and put it back together when translation is ready.

Pawel, WHY do you insist on doing all that segmentation, etc. - for which you apparently don't have all the needed knowledge - in the WPML?!?!
Why don't you simply put the ENTIRE CONTENT PARTS (the complete HTML code) into a XML structure and that's it?
Everybody can then extract and segment the text using their preferred method or tool... And the only thing handled by the WPML would be the export/import...

Basically, you would do all what you were doing all the wears so far, just without putting it in XLIFF structure (which is NOT just another form of generic XML, as you guys apparently thought), but in a real generically-structured XML 'envelope'.
Basically no effort from your side, but huuuuuge relief for whole translation world...

The point here is to explain - and hopefully also FIX! - the CAUSE of the problems (i.e. the 'invalid' XLIFFs), not keep working around the CONSEQUENCES again and again and again.

Not mentioning other issues like explaining such technical problem to clueless managers ("It's an XLIFF, right? And the tools do support XLIFF, so what's the problem?!)... :(

That's certainly a start but does anyone know how the WPML segmentation and merge app works? I'd thought of using Okapi to segment the WPML XLIFF files but I read that the Okapi XLIFF filter doesn't support true subfiltering  of CDATA yet.

See bitbucket.org/.../xliff-filter-true-subfiltering-of-cdata and related issues. Any news or suggestions? A hosted app is not an option for some of the projects I am involved in. 

All the best,

Daniel

I take it this didn't go anywhere? I've just run into this issue with WPML xliffs just coming in large chunks. In export anyway, their own editor of course 'understands' it   

Are there any WP translations tools that are known to produce kosher xliffs? The client apparently isn't married to WPML and would consider switching.