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?

Adrian Komiński 

Nothing is so straightforward.  These things are always due to something unexpected in the file and just because you see this same error message again it doesn't mean it's for the same reason.  If only life was that simple.

I have offerred to investigate this for you and can't do more than that.  For the development team to be able to fix anything we need to be able to verify that this is a really a problem that the software can be expected to be able to handle, this isn't always the case, and we need to be able to cut down the file to something that can do this for us so the dev team know where to focus their attention.

In reality it would probably be trivial for you to at least try the following if you would like us to investigate this:

1. Split the file until your left with a small section that behaves this way, then anonymize the text, or

2. Run a pseudo-translate on the file so the text is nonsense, save the target then anonymize what's not handled and send us the file

But it's your call Adrian.  We're trying to help.

Trados is what, 20 years old now? And you're telling me "there's always something unexpected" in files that you haven't been able to sort out for at least 10 years now? Jesus, how many scenarios can there be? Do you fire your entire dev team every year and then hire a new one, preventing the staff from gathering experience and keeping debugging records?


The thing is I don't really need your help per se - I had to do a time-wasting and disadvantageous workaround to meet the deadline, as always. Even if you helped me with this particular file, I would probably need help again some time in the future, when I run into "something unexpected". And this time, instead of wondering whether this is something "that the software can be expected to be able to handle", I'll just switch to more reliable competition (MemoQ), without looking back.

Tried to pseudo-translate the project but nothing came out of it. Do the segments need to be cleared first? 

Adrian Komiński 

A lot more scenarios than you might think. Studio is made up of millions of lines of code and we are always dealing with moving parts that can come from the operating system, third party software, the files you handle, and also from Studio itself. Just because you get the same headline message doesn't mean anything. I don't expect you to understand this as you are clearly not a developer, but I would ask you to keep the conversation more civil.

You brought up the problem. I responded and offerred to help you find the source of it. If you are not interested then fair enough.

Yes... if you have already got translations in there then you nneed to clear them first.

There is no headline message - there is only one symptom, and that is text suddenly going original mid-file, for no apparent reason. Had there at least been an error message… but no, Trados leaves you with a worthless export and that's it. Good luck with fixing that. Super frustrating.

Of course there can be different scenarios, files, etc. but there are also patterns, as with any software - and there's the dev team that's supposed to determine and troubleshoot them. This is not early 1980s, for heaven's sake, and this is not noobish freeware.

Find attached the problematic (target) file. I deleted almost all the original text left behind in the target file, leaving only two or so segments for proof.

troubleshooting file.docx

Adrian Komiński 

Please can you tell me how to reproduce this problem. I opened the file, pseudo-translated again but this time used dollar symbols so any missing text would stand out and the entire contents of the file gets translated.

You probably need to clarify a few things:

1. Which version of the Word filetype are you using?
2. Did you do anything like try to reuse an old project template from a previous version
3. Which part of the file is being left untranslated?

It might be helpful for someone else to verify this to avoid any thoughts I might be doing something special. It's clear to me that the problem is not a general one and in many ways illustrates the sort of problems we have to filter out. We need proper steps to reproduce so we know exactly what you did to cause this effect.

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.