John Narins Hello, this might have happened because some segments were merged or split and a structural element of the target file is no longer correctly placed, so the target file is not correctly created.

You can troubleshoot this by

- re-creating the project (re-import the package or re-open the Source file in Trados),

- then pre-translating with your TM, to retrieve the translations (maybe lower the match threshold from 100%, to get more leverage),

- then check the segments for which there is no translation, or there are fuzzy matches. Do not merge or split the segments again. 

Let me know if this helped.

Yes!

But... it was a lot of work. It would have been far, far less work if there were a way of knowing which pair of merged segments caused the problem.

Really this program, given its level and cost, shouldn't fail with an error message. It should bring up a window saying something like: "You merged these segments, that caused a problem. Choose a fix."

I beg your pardon, but merging segments across paragraph breaks is your own responsibility. It is well known, that this may cause problems.

This said, you can simply translate the file anew from the TM. When merging segments, do NOT merge such, which contain a picture tag. It's very easy to see and notice.

Next time you will know. In my previous home country Poland we have a saying, that Polishmen are very smart after the problem happened... Well, this time you were the guinea pig. Shit happens.

As for the error message: maybe the name "illustration xxx" will show you, which one it was.

What a ridiculous answer. The program finds the problem, but doesn't tell you where it is. Your answer: screw the user, why should the program tell you where it is? There's a function to merge cells, the user should know not to use it.
That's just silly. If merging cells were "bad," there wouldn't be that function. If the problem were impossible to locate, we'd have to resign ourselves to it. But neither, of course is true. The "merge cells" function is often extremely useful and there is no stigma rationally to be attached to it. And the program has found the problem and therefore knows precisely where it is. But you wouldn't want it to tell you?

In what world is asking for improved functionality, when it's both obvious and easily attainable, the wrong approach? Better just to hobble your own practice by voluntarily renouncing useful functions built into the program.

John Narins 

Hi John, I agree with Jerzy Czopik. His answer is not ridiculous, it is logical

If the 3rd party software from which your source files were converted is unable to reimport translated files because they have sections that have been manipulated in such a way that they break the reconversion/import rules of that 3rd party software, you cannot expect Studio to override those rules. Studio is very powerful but, in short, it has no influence over 3rd party  software behaviour.

All the best,

Ali

I know the merge function very well. And keep showing users in various conferences, where the limits are. And there are limits. There is a valid reason, why you have to explicitly allow it, before you can use it. And there are reasons, while in packages received from customers this function is switched off. Sorry, but lack of knowledge does not protect you from punishment for doing something wrong. Have you merged so many paragraphs, that it is a problem now to recreate the translation from TM? In that case your source file has not been properly prepared. Maybe prepare the file properly to avoid merging segments in Studio.

And merging segments is not "bad". It just has limits. This is why nearly all CAT tools do not allow doing that over paragraph breaks. In Studio you can do that, but you should be aware how it works.

So - irrespective of the abilities and limitations of other programs - it's preferable that our program, when it encounters a problem, not only not offer a solution, but not even tell you where it encountered the problem. Is that really what you mean to say?

My only point is to suggest an easy potential improvement.

John Narins

John Narins said:

Really this program, given its level and cost, shouldn't fail with an error message. It should bring up a window saying something like: "You merged these segments, that caused a problem. Choose a fix."

In fact I absolutely agree with you.  Not so much the level and cost part as this is irrelevant, but I do think that if it is possible to provide that level of improved assistance when something fails then we should be doing it, or at least attempting to do it.

Generally, we do try to be helpful.  But it's not always obvious where the problem comes from as there are many dependencies which can cause an error and unless the application can see something obvious in there to help we may not actually know exactly where the problem is.

I think that whether you know how to work with the potential problems that can cause errors or not doesn't change the fact that the more help the software can provide the better.  If you know how to work around it or what to avoid then you do have a better experience.  But this takes some time to reach that level of expertise, and is exactly why the more the software can do to help the better it will be.

So, points noted, and I'm sure the development team will continue to do what they can to improve the user experience going forward.