Hanno Willemsen 

Hanno Willemsen said:

- hexadecimal value 0x02 is not valid

- the element named "xliff" is an unvalid child for the XliffProvider element

Does anybody have an idea what could be the problem?

Your XLIFF files on the basis of this explanation!

Can you share one that doesn't work?

Hanno Willemsen 

In fact better share two as you have XLIFF 1.2 and XLIFF 2.0 in the errors.

Dear Paul,

Thank you for your quick response.

As these our files from our client could I send them to you directly?

Regards,

Hanno

Hanno Willemsen 

Sure... pfilkin at sdl dotcom

Thanks a lot.

I just sent you an email with the two files.

Hanno Willemsen 

Thanks for sending me the files.  As far as I can see the problems in both files seem to come from the use of the xhtml:style attribute in the "g" element.  Your files have things like this:

<source><g id="orkz5RjWv9Gr0yP1" ctype="x-html-P"><g id="nI4PrtI72CLqVcqf" ctype="x-html-SPAN" xhtml:style="color: rgb(255, 255, 255); font-size: 30px;">Klik op de balk hieronder om naar het <g id="Jxucshm1a6IDxDKD" ctype="x-html-STRONG">volgende hoofdstuk</g> te gaan.</g></g></source>

Non-XLIFF attributes like xhtml:style can technically be placed within <g> tags, as you've done in your example, according to the XLIFF 1.2 specification as long as the namespace is declared... and your files do that too. The specification does not explicitly forbid this kind of usage.

But, this practice can lead to complications since some XLIFF parsers and tools won't understand or correctly handle this attribute.  Seeing errors if the XLIFF parser strictly adheres to the specification and does not recognize xhtml:style is not unexpected and Studio certainly will stick to the rules.  I also tested in a validation tool and see this:

If it is absolutely necessary to include this non-standard attribute in your XLIFF file, the location you have placed it in is technically correct, as per the XLIFF 1.2 specification. However, for broad compatibility and adherence to best practices, it's recommended to handle styling via CSS in the actual web application and not embed these details within the XLIFF files.

Hanno Willemsen 

Thanks for sending me the files.  As far as I can see the problems in both files seem to come from the use of the xhtml:style attribute in the "g" element.  Your files have things like this:

<source><g id="orkz5RjWv9Gr0yP1" ctype="x-html-P"><g id="nI4PrtI72CLqVcqf" ctype="x-html-SPAN" xhtml:style="color: rgb(255, 255, 255); font-size: 30px;">Klik op de balk hieronder om naar het <g id="Jxucshm1a6IDxDKD" ctype="x-html-STRONG">volgende hoofdstuk</g> te gaan.</g></g></source>

Non-XLIFF attributes like xhtml:style can technically be placed within <g> tags, as you've done in your example, according to the XLIFF 1.2 specification as long as the namespace is declared... and your files do that too. The specification does not explicitly forbid this kind of usage.

But, this practice can lead to complications since some XLIFF parsers and tools won't understand or correctly handle this attribute.  Seeing errors if the XLIFF parser strictly adheres to the specification and does not recognize xhtml:style is not unexpected and Studio certainly will stick to the rules.  I also tested in a validation tool and see this:

If it is absolutely necessary to include this non-standard attribute in your XLIFF file, the location you have placed it in is technically correct, as per the XLIFF 1.2 specification. However, for broad compatibility and adherence to best practices, it's recommended to handle styling via CSS in the actual web application and not embed these details within the XLIFF files.

Hello Paul,

Thank you for pointing that out.

I will ask the client if they can leave that out.

When they do, will we be able to open the files do you think?

 Hanno Willemsen 

Hanno Willemsen said:

will we be able to open the files do you think?

Well... I tried this.  FIrst I removed all these references with this regex:

xhtml:style="[^"]+?"

I just deleted everything this found.  There were 48 references in the file I tested.  Then it still failed... this time because there were invalid characters in the XLIFF.  This was the test... but Studio reported something similar:

I can remove these with this expression:

\u0002

They look like this in the file:

There were only 4 so I replaced with a space.  Then I get this problem:

But... Studio can still open it and I could copy source to target and save the target file.  So I guess if you are diligent and can remove all the flaws in the files then yes... you will be able to handle them in Studio.

Thank you.

Seems our client has some work to do ;)

Could you perhaps send me the last file you saved? Then I can try it here and use it as an example for our client.

Hanno Willemsen 

I sent you a zip by email with the source file I adapted, the sdlxliff I worked on (source copied to target... and probably the wrong languages as I didn't pay attention to that), and a target file containing populated target elements.

Hello Paul,

I received the files and can indeed open the xlf now!

Thank you very much for your efforts. We would never have found out by ourselves.

Hanno Willemsen 

You're welcome.