Patrice Philippi

I have not tested this yet, but it looks as though you may have left the default rule in there which would be overruling your other rules.  Try removing the last rule.

Hi Paul, Thank you but with/without the last rule, doesn't change anything. Beside that the last rule should be considered last. 

Patrice Philippi

In fact.. the last rule is considered first, not last.  However, that isn't the issue.  I discussed this with the filetype developer this morning and your problem is because this text is wrapped in the ph inline element.  In XLIFF this element is used as a placeholder and not as translatable text, so by default it's rendering exactly as it should be... a placeholder:

http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#ph

So if you can't get your client to use this properly, and if this content really is supposed to be translated, then your best option would be to handle this as a monlingual XML filetype instead.  For example, doing this gets you this:

Which is also not what you want, and the reason for that is because your file is a mix of XML entities telling the parser to handle this as text.  So you need to convert these entities into reserved characters like this:

Now I get this:

Also note that to handle this as a mono-lingual file I needed to do three important things:

1. convert the entities to reserved characters
2. copy the source content into the target element
3. create a custom XML filetype with *.xliff as the wildcard for the filetype identifier

Patrice Philippi

In fact.. the last rule is considered first, not last.  However, that isn't the issue.  I discussed this with the filetype developer this morning and your problem is because this text is wrapped in the ph inline element.  In XLIFF this element is used as a placeholder and not as translatable text, so by default it's rendering exactly as it should be... a placeholder:

http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#ph

So if you can't get your client to use this properly, and if this content really is supposed to be translated, then your best option would be to handle this as a monlingual XML filetype instead.  For example, doing this gets you this:

Which is also not what you want, and the reason for that is because your file is a mix of XML entities telling the parser to handle this as text.  So you need to convert these entities into reserved characters like this:

Now I get this:

Also note that to handle this as a mono-lingual file I needed to do three important things:

1. convert the entities to reserved characters
2. copy the source content into the target element
3. create a custom XML filetype with *.xliff as the wildcard for the filetype identifier

Hi Paul, Thank you for this reply. That does make totally sense.

By replacing the ph inline element by a mrk element and using the embedded filter, then, everything is fine without having to convert entities. I have to see if the client can replace it on his end while generating the XLF or if I need to do it programmatically. Not sure why ph was used here.

The second solution is less optimum as it also requires also some preps on the file and I loose the client pretranslation.

But thanks, this open the door to a solution.