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".

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".

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.

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

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.

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.

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.

Hi David McDermit

I was curious whether AnyTM would really do the job, so I set up a micro-project with German (Germany) as source and EN-GB and EN-US as target languages. I first translated DE-DE -> EN-UK, then ran the batch task "update main translation memories" (this was necessary) and then opened the DE-DE -> EN-US file for translation:

Works like a charm. I defined different TM settings for the De-DE -> EN-US language pair: AnyTM with the same TM as DE-DE -> EN-GB. 

Daniel

Thanks.  Good to hear.

I was having great trouble and tried many suggestions from the Community. Things worked for me when I used these settings and opened the XLF files as a single document. THANKS SDL Community!!