• State Suggested Answer
  • Replies 12 replies
  • Answers 3 answers
  • Subscribers 433 subscribers
  • Views 4274 views
  • Users 0 members are here
Options
Related

Coded specific XLF file and problem with Target file

David McDermit

I am the PM for the translators in our department.  We are having an issue with an XLF file created from Articulate Rise has within its coding unique ID markers so that only that file can be uploaded back into the program.  Rise is an e-learning software program.

There are two XLF files sent for Translation in English.  The department is looking to have them translated into Traditional Chinese(TC) and Simplified Chinese(SC).  Language translation is not important for the problem.  It is the translation process I believe causing issue and looking for options.

What happens is this.  Our translators take the TC file, after translation, and export a Bilingual word file.  When they open this file in Word their is a translation application that allows them to convert the TC characters to SC.  They then import this translated SC file and update the TC file so that it is now in SC.  They clean up the file in Trados and Saved the Target file as the SC xlf file. 

This is where the problem comes in.  The department that sent us the SC xlf file is unable to import the translated file. 

I was finally able to get from Articulate that yes there are unique ID codes throughout the file that only allows that specific file to be uploaded.

Thus the issue.  When the TC file is exported and the new bilingual Word file updates the TC file into SC the XLF file still has the unique codes within it for TC.  Have everything translated, but are unable to upload the file as SC.

I could take the time and look over the file and fix the unique id codes, but depending on size of the translation that option becomes problematic.  Plus, if I am not around to do this code editing...

This brings me to my question.   How can we bring the SC Word bilingual file and SC xlf file together and have a good Save as Target file created so that it will be able to be imported by the other department.

Thanks

David
Rate translation
×
Suggest better translation
×
Moderator UI
×
  • Get AI Suggestion
Parents
  • 0

    Have you stored the final XLF with segmentation or WITHOUT segmentation? From my experience with such processes, the final file should NOT contain segmentation. However, Studio does store segmentation in the target XLF by default. So if not yet tested, simply open the project settings, go to XLIFF file type, Settings and select "Do not store segmentation information in the translated file".

    Trados Studio project settings window showing XLIFF file type options with 'Do not store segmentation information in the translated file' checkbox selected.

    _________________________________________________________

    When asking for help here, please be as accurate as possible. Please always remember to give the exact version of product used and all possible error messages received. The better you describe your problem, the better help you will get.

    Want to learn more about Trados Studio? Visit the Community Hub. Have a good idea to make Trados Studio better? Publish it here.

    emoji


    Generated Image Alt-Text
    [edited by: Trados AI at 12:16 AM (GMT 0) on 29 Feb 2024]
  • 0 in reply to Jerzy Czopik

    Yes, that was one of the first things that we had all the translators do before translating.  I even remind them and the freelancers to double check prior to starting project.
  • 0 in reply to David McDermit

    In that case the process used might indeed be the culprit. Why isn't the recoding done in Studio directly?

    _________________________________________________________

    When asking for help here, please be as accurate as possible. Please always remember to give the exact version of product used and all possible error messages received. The better you describe your problem, the better help you will get.

    Want to learn more about Trados Studio? Visit the Community Hub. Have a good idea to make Trados Studio better? Publish it here.

  • 0 in reply to Jerzy Czopik

    Expediency is the reason.  The number of CH/SC translations they have to do has been growing, and since there is not a HUGE difference between characters it is faster to do the process this way for them.  As I mentioned, it is not an issue with other file formats including other XLF files.  It is just those unique identifiers in this particular XLF file that is the issue.

    If I can just determine an effective way for them to either use the Word bilingual technique now, or if AnyTM works, to help ease their workload all the better.
  • 0 in reply to David McDermit

    Use SDLXLIF ti Legacy Converter to convert to Word and then to import. This is a process designed for external translation. Other way is to use the XLF (or SDLXLIFF) and recode there. Both are simple text files, so it should be no real difference to doing that in Word.

    _________________________________________________________

    When asking for help here, please be as accurate as possible. Please always remember to give the exact version of product used and all possible error messages received. The better you describe your problem, the better help you will get.

    Want to learn more about Trados Studio? Visit the Community Hub. Have a good idea to make Trados Studio better? Publish it here.

  • 0 in reply to Jerzy Czopik

    The word translation going out and coming back in does not seem to be the issue.

    What seems to be the issue is the Target file.  When the Word file is first exported it is from the CH translation of an English file project.  It is when that SC word file is brought back in they are still using the CH file and the import changes just the CH characters to SC.  Unfortunately, when they go to Save Target As and save the xlf with the proper SC name it still has within it the unique coding for CH.

    Someone did try bringing in the English SC XLF file that has its unique code markers and uploaded the SC Word bilingual file in.  Not surprisingly the translation did not populate.

    How to use the Word file with the SC characters and the somehow get a translation with the unique code markers for the SC xlf is what looking to do without having to manually translate each file.

    The one suggestion to use AnyTM might be the way.  Have to wait for translator to get back from trip to test that out.

    Other possible ideas I might be able to test.  Thus my question here.

    Thanks for suggestions.
Reply
  • 0 in reply to Jerzy Czopik

    The word translation going out and coming back in does not seem to be the issue.

    What seems to be the issue is the Target file.  When the Word file is first exported it is from the CH translation of an English file project.  It is when that SC word file is brought back in they are still using the CH file and the import changes just the CH characters to SC.  Unfortunately, when they go to Save Target As and save the xlf with the proper SC name it still has within it the unique coding for CH.

    Someone did try bringing in the English SC XLF file that has its unique code markers and uploaded the SC Word bilingual file in.  Not surprisingly the translation did not populate.

    How to use the Word file with the SC characters and the somehow get a translation with the unique code markers for the SC xlf is what looking to do without having to manually translate each file.

    The one suggestion to use AnyTM might be the way.  Have to wait for translator to get back from trip to test that out.

    Other possible ideas I might be able to test.  Thus my question here.

    Thanks for suggestions.
Children