Detecting language please wait for.......
Hi, I have started using SDL Trados 2019 since March this year and everything was going smoothly. However, after receiving a notification requesting me to update my Trados to the recent one, I started experiencing difficulties as my translated XLIFF files are now having the following sentence "state=translated which has nothing to do with my translation. I spent the whole shift yesterday trying to fix it, and I was not successful. Can anybody assist please.
This is how it appears
<xliff version="1.0"><file original="f101_114_p27_en_fr.xlf" source-language="en" target-language="fr" datatype="html"><header /><body><trans-unit id="S-5-27-101"><source>RAIL_CALLING_ORDER_LINES</source><target state="translated">RAIL_CALLING_ORDER_LINES</target></trans-unit><trans-unit id="S-6-27-101"><source>RAIL_CALLING_ORDER_LINES</source><target state="translated">RAIL_CALLING_ORDER_LINES</target></trans-unit><trans-unit id="S-12-27-101"><source>No help is available for this page.</source><target state="translated">Aucune aide n'est disponible pour cette page </target>
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 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.
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.
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.
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