Kasongo Bajika

Why is this a problem?  The state attribute is normally expected in XLIFF files.  You can change the translated attribute-value to be something else, but there is no way to avoid writing something in there.

Hi Paul, thank you for your reply to my concern. Let me tell you that this is a urge problem. I am busy translating a big document in HTML language. I think you know that even an extra single dot is a big issue in this type of document. Therefore, the client is complaining that the document cannot be downloaded as he is receiving errors message. I am currently obliged to restart the work done all over again as Trados seems to be not helping me in this particular project. 

Kasongo Bajika

Two things...

Kasongo Bajika said:

I am busy translating a big document in HTML language.

Then why is XLIFF even an issue here?  You can translate the HTML directly.

Kasongo Bajika said:

the client is complaining that the document cannot be downloaded as he is receiving errors message.

Can you share the error message?  If the state is really causing this error then your client is the one at fault here for not supporting XLIFF correctly.

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

Kasongo Bajika

Are you returning the generated target file or the XLIFF file to your customer? It almost sounds like you are sending the XLIFF file back.

If you finalize a project, Studio will generate a target file in the original file format. That would be HTML in your case. In the same folder will be the bilingual translation file (SDLXLIFF).

The target file (ICML in the above screenshot, HTML in your case) is what you send back to your customer.

Daniel

Kasongo Bajika

Are you returning the generated target file or the XLIFF file to your customer? It almost sounds like you are sending the XLIFF file back.

If you finalize a project, Studio will generate a target file in the original file format. That would be HTML in your case. In the same folder will be the bilingual translation file (SDLXLIFF).

The target file (ICML in the above screenshot, HTML in your case) is what you send back to your customer.

Daniel

Hi Daniel, thank you for your answer. The client did sent me XLIFF from his HTML document. On my side I've loaded the said files in Trados for translation. After translation, I do save them as XLIFF and that's when the state="translated" issue appears. Currently I am deleting it manually for each segment, which is time consuming.

Kasongo Bajika

I don't know which program your client used to convert the HTML to XLIFF, but it's unusual that he should not be able to import your XLIFF. As Paul said, it's correct.

If deleting the state attribute solves your problem, you could do a "replace all" and replace <target state="translated"> with <target> in Notepad++, which is free software. All these batch operations carry a certain risk, so make a backup copy before you start.

The whole thing is a bit surprising - that your client's software can't read a nomal XLIFF file. But a similar issue was dicussed here, it seems: https://community.sdl.com/product-groups/translationproductivity/f/studio/5779/tu-contains-target-state-translated-in-xlf-file

Daniel