Paul,

You know troubleshooting with specific files ain't easy in this industry due to NDAs. All I can say is the file was really straightforward, with mostly just plain text in .docx (not a PDF conversion, to my knowledge).

How about we just jump back in time to 2015:

www.proz.com/.../280517-generated_translation_half_in_source_text_half_in_target_text.html

Same problem (with Studio 2009 - so, wow, it's been 10 years with the same unresolved problem now!). You posted in that thread then. Did the devs investigate into the problem at all throughout all those years? You know the problem has been occurring for many people, as it has for me (numerous times throughout the years, and always taking quite a lot of time to fix). I remember reading other peoples' posts some years ago with exactly the same problem. What conclusions did the devs arrive at?

Hi Adrian,

You can find the file type being used for each of your files in the "File Type Identifier" column in File view. In the snip shown below, it is not immediately clear which Word version is being used for my file, but you can figure this out by looking in the Project Settings under File Types, where you will find each Word file type along with its associated File Type Identifier.

As you can see from the snip below, the file type being used for my file is Word 2007-2016.

Paul was asking what file type Studio has chosen for your file. Since he had no problems with the file you sent, the first thing he wants to check is whether you are both using the same file type. If you are, then I imagine he will move on to the next troubleshooting step. (I can't imagine you are using different file types, unless you accidentally changed the file types that are active in your settings.)

Hope this helps,
Bruce Campbell
ASAP Language Services

Hi Adrian Komiński

I could not produce the problem you report, I tried translating the file you uploaded. It translated cleanly with no problem at all, there was only Target language text in the Target document I produced.

I've never had Source text appearing in Target documents unless there was some form of Source document content that had been somehow overlooked or excluded. For example, if either the client or the project manager hadn't prepared the file properly in some way such as missing text hidden inside/behind a too-small text container, locked content or 3rd party content that was inaccessible in the SDLXLIFF. Or maybe, if tagged Source content lost its properties through file manipulation so that content that should not be visible ended up exposed in the final format. 

I have been using the product to translate various file formats, not just Word, since Studio was launched and before that since the early days of Trados TagEditor... This problem you're having is honestly not something I have seen without there being a logical explanation that was resolvable, and a solution therefore that I could find. 

All the best,

Ali

WIW, I have seen this problem many times too... though only with one type of files on one particular project (as far as I can remember) - XLF files from Skype localization back in summer/autumn 2016. (I left the project after few months, so I have no information whether the problem persists or not)

The problem was totally random and though I spent quite a lot of time trying to find any pattern or the cause, I could not identify anything in the files or TMs itself.

Unfortunately I have none of the affected files available anymore, but I found one email with some screenshots... it probably won't be of much help, but perhaps better than nothing...

It's worth noting that the XLF files coming from Skype were NOT proper XLIFFs, they were crippled the same way as WPML "wannabe-XLIFFs" - they wrapped an entire HTML page content into CDATA and stuffed it in <source> element... and called it XLIFF, amateurs.
So we had to pre-process the files - by making a "copy" of the <source> element as <target> element - and then processed the files as XML with embedded HTML, not as XLIFF.
This puts any possible weirdness in the original sources pretty much out of question, since the format going into Studio was pretty clean XML.

Quote from the email:

Primary cause is Trados – although everything looks just fine in Trados, some(!) of the generated target files have a) English text added to some sections, b) only English text in some other sections. The affected files are not predictable and I did not find the cause and/or what actually triggers this behavior.

See the screenshots below.

The only cure we found back then was this crazy and time consuming workaround:

1. Prepare and Translate source files as usually
2. Once we have all the files localized:

• Clean translations into TM
• Create new Trados project (or use backup from step 1.)
• Apply perfect matches - using the files we just localized
• Pre-translate the files if necessary using updated TM we in step a.
• Export the files.
• Those exported files are fully localized now

Hi Evzen,

Thanks for the information.  I think this only helps to demonstrate how difficult it is to identify what's happenning here.  It would be good if the files had been sent to support, or if the process could be replicated somehow.  It's clearly not that common an issue, and we really need to have files and be able to reproduce the problem or we don't know what we are supposed to fix.

Unfortunately that explanation won't satisfy everyone, but this sort of reported error, which isn't that common an occurrence is never going to disappear unless we're able to reproduce the issue consistently and can explain to the development team what process to follow to reproduce it.  Without that we can't tell them what to fix, can't test anything they do fix.

Sure thing, I fully understand the difficulty.
Back then it was the usual situation - NDA, blablabla... you know :-\

Still - SDL itself does localization as well, so I'm pretty sure your engineers must have encountered this problem too. It's just physically impossible that only people outside SDL would be affected.
But well, it all comes down to the (un)ability of the engineers to identify problem and report it... most of the cheapo engineers - and let's be honest, everybody is cutting costs, including SDL - either don't care, or are just "monkey see, monkey do" cheapo manuelos required to not think about what they do...

Evzen Polenka said:

Still - SDL itself does localization as well, so I'm pretty sure your engineers must have encountered this problem too. It's just physically impossible that only people outside SDL would be affected.

Perhaps, but I will investigate this as I do know many of the teams in SDL responsible for these types of work.  I'll also check again with the support teams just in case.

Evzen Polenka said:

But well, it all comes down to the (un)ability of the engineers to identify problem and report it... most of the cheapo engineers - and let's be honest, everybody is cutting costs, including SDL - either don't care, or are just "monkey see, monkey do" cheapo manuelos required to not think about what they do...

Perhaps you really meant people taking on responsibility for things they are not fully qualified for.  I can tell you that the localization engineers in SDL either found ways to prevent problems occurring when they prepare files or they do indeed report them.  They are also very well versed in providing the information that's required to help the support teams log a bug when needed, and very often go a lot further in identifying the cause themselves.

I think people taking on the role of a localization engineer without the proper experience or knowledge of associated technologies is another story, and unfortunately many translators find themselves in this situation today as they attempt to help their clients.  All the best of intentions, but often inadequately prepared to do it properly.  Sometimes I think the role of the localization engineer is completely underestimated at best, and not even understood at worse.

And then we have the situation like this one where the files should not require a localization engineer at all and they should in fact just work so that non-technical users can get on with their job of translating.  Sadly this isn't how things work, in any CAT, and there are many variables that can cause problems as well as bugs in the CAT itself.  I think the level of complexity CAT tools deal with is also underestimated.  We can only ask for patience and try to help as much as we can, and we are doing this even for users who don't find it important to take a support contract in support of their business activity.

Evzen Polenka said:

Still - SDL itself does localization as well, so I'm pretty sure your engineers must have encountered this problem too. It's just physically impossible that only people outside SDL would be affected.

Perhaps, but I will investigate this as I do know many of the teams in SDL responsible for these types of work.  I'll also check again with the support teams just in case.

Evzen Polenka said:

But well, it all comes down to the (un)ability of the engineers to identify problem and report it... most of the cheapo engineers - and let's be honest, everybody is cutting costs, including SDL - either don't care, or are just "monkey see, monkey do" cheapo manuelos required to not think about what they do...

Perhaps you really meant people taking on responsibility for things they are not fully qualified for.  I can tell you that the localization engineers in SDL either found ways to prevent problems occurring when they prepare files or they do indeed report them.  They are also very well versed in providing the information that's required to help the support teams log a bug when needed, and very often go a lot further in identifying the cause themselves.

I think people taking on the role of a localization engineer without the proper experience or knowledge of associated technologies is another story, and unfortunately many translators find themselves in this situation today as they attempt to help their clients.  All the best of intentions, but often inadequately prepared to do it properly.  Sometimes I think the role of the localization engineer is completely underestimated at best, and not even understood at worse.

And then we have the situation like this one where the files should not require a localization engineer at all and they should in fact just work so that non-technical users can get on with their job of translating.  Sadly this isn't how things work, in any CAT, and there are many variables that can cause problems as well as bugs in the CAT itself.  I think the level of complexity CAT tools deal with is also underestimated.  We can only ask for patience and try to help as much as we can, and we are doing this even for users who don't find it important to take a support contract in support of their business activity.