Trados 2022 Download

0 views
Skip to first unread message

Alacoque Whitchurch

unread,
Aug 3, 2024, 5:53:48 PM8/3/24
to geamelermo

Using RH 2022.2.22. I sent some xlf files to my translation team. They ran the files through Trados Studio and returned a test file. I saved the test file in a separate folder (not the RH project or the child language project). I copied the mapper file into the folder. When i try to import the xliff file into RH, it says 1 file will be imported but it doesnt show any files in the window. If I click OK to proceed, I get a red box with the msg: Application Error - the application has run into an error. pls save your work and restart Robohelp.

My first suggestion would be to talk to the translation team in the hope they can work something out with you. An external agency might have worked with RoboHelp users before but if your team is internal, maybe not.

After that I can only suggest trying Adobe Support. See -support.other.html#robohelp for your Adobe Support options. The email link tcs...@adobe.com is recommended as it reaches a team dedicated to Technical Communication Suite products including RoboHelp.

Thanks Jeff. I did see that thread. I wasn't able to glean the required file format when importing xliff files back into RH. I will keep looking on the web. I think something is not right with files Im getting abck from Translation, but I can't tell them what files to produce until I find out myself.

Hi,
From your post I can understand that you have generated XLIFF files from RH app itself and then sent it over to translation o the vendor that uses SDL trados studio for translation of XLIFF files.
The file extension seems to be changed when the XLIFF files were modified in SDL trados studio. Does reverting the extension to .xlf e.g. contents_Settings_Change_password_for_non-admin_users_htm.xlf_test-bilingual.sdlxliff changed to
contents_Settings_Change_password_for_non-admin_users_htm.xlf fix the issue for you?

If possible, can you share one sample XLIFF file that gets generated from RH, and then the same XLIFF file that gets modified in the SDL trardos studio?

Thanks!

@Sudhanshu Monga, Thanks for your reply. I was able to get the Translation team to save their files as xlf before sending them back to me. And RH imported them successfully in 2 seconds. However, when I open the child project (French Canada), the English content has disappeared and the French content is there but only in bits and pieces. I believe the xlf files contain all the French content - I can open the files using Notepad and I see both the English text and the translated french text. But somehow RH is not able to parse the xml correctly. I am attaching 3 files:

Hi Bob,
The xlf file generated by RH is pre-segmented, whereas when it comes out of trados, it loses the segmentation. In RH upon import we expect a segmented xlf file, therefore you experience content loss.
This is how a segmented translated xliff file should look like:

Thanks for pointing out that the translated files were not segmented. The translation team enabled segmentation in Trados, and sent me a new test file for the Receipt topic. RH got stuck during the import and I had to click Dismiss. I opened the translated file in Notepad and i see that the contents are indeed segmented. here is some of the code produced by Trados:

Could you have a look at the attached files: the xlf file from RH and the xlf file from Trados. I am not sure why RH is unable to successfully import the file from Trados. (FYI, I wrapped the xliff code in XML to allow me to upload the files to this forum since it does not permit XLF files - can this rule be changed? )

Thank you for your advice. I removed the "trailing spaces" attribute. There were no instances of "leading spaces" attributes. RH was able to import the file successfully. The French content is all there which I am happy to see. It is a vast improvement over the previous results. The only issue now is that some spaces are missing. For example, bold text next to regular text (not everywhere but in some spots) and some sentences have no space after the period (full stop). Is there any other way to get RH to parse the files without removing the atritube for spaces? The correct spacing is there in the HTML files when I generate xliff. Is there a way to tell RH to simply preserve existing spaces in xliff?

I was working on a language translation project in trados on a virtual machine. Half of the work was done and the translated words were exported into a Word docx file. Upon restarting the virtul machine, the project file appears to have been corrupted as trados shows no signs that the project was worked on. When I manually open the sdlproj (trados project) file, trados cannot open the file mentioning the following:

I have tried creating a new project and used pre-translate using batch tasks but that did not seem to have imported the previously translated document. I need to figure out how to recover my project so that I can recover the translated document (so I do not have to redo the work) as well as recover the translation memory for trados. The translation memory folder is present inside the original project folder. I would really appreciate any suggestion to further troubleshoot and fix this issue. I have tried their support desk but they do not appear to be available today. Two solutions I observed from their forum suggested:

In my case, I was able to open the sdlxiff file from the translated language directory. This opened the project with the text that had previously been translated. I am not certain whether I need to remove the sdlproj file or simply save the project hoping that it will overwrite the corrupted file. In either case, I will update this post once I get an answer to that.

I am doing a test in trados 2024 on a translation of a German > Catalan text. I have implemented in trados a gpt4 model and it seems to work. My surprise is that when it translates it does not respect spacing, all the words appear together and also adds words that do not make sense. I ran the same text through gpt4 directly and it translates it correctly.

c80f0f1006
Reply all
Reply to author
Forward
0 new messages