David McDermit

You are using the Bilingual Word file export for something it is not meant to do. You have to create a project with the EN-SC file and work from there. If you use AnyTM and the project TM of the EN-TC file project, the TM will suggest the TC content to the translator (you could even use it to pre-translate and populate all target segments like this).

Daniel

They actually use this bilingual file option all the time to help speed up all the jobs that they have to translate.  When they have over 60 translation requests a month in multiple languages this process helped them, and has not been an issue on any other file type.  It is not even an issue with other XLF jobs they translate.  It is just that unique coding within that xlf file that is the issue.

I will look into AnyTM to see if this might be an option.

David

David McDermit said:

They actually use this bilingual file option all the time to help speed up all the jobs that they have to translate.

That unfortunately doesn't mean that they are not doing completely WRONG thing!
I've seen people doing - due to their ignorance - many completely BAD and WRONG things... and then wondering why they've come to a dead end... :(

Use software and processes ONLY the way they were INTENDED to be used and done and things will start working.

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