Yes, I understand ;-)

And I'm saying that this has absolutely nothing to do with the problem.
Because even the original untouched, only autotranslated, document has the target text "invisible"... simply because the translation (in single, not merged, segment) is longer than what can fit in the fix-sized table cell.

And there is absolutely nothing Studio can do about it.
What may be fine and required by one (i.e. letting the table cells to autosize) can be a big problem for someone else.

In fact it's all rather a Word problem - wouldn't you expect that Word actually indicates somehow that there is actually more text, but it's not visible because it doesn't fit in the cell?!

Evzen Polenka said:

Because even the original untouched, only autotranslated, document has the target text "invisible"... simply because the translation (in single, not merged, segment) is longer than what can fit in the fix-sized table cell.

ok.  From that perspective you are correct.  Sorry, I misunderstood what you meant.  In this case the problem is completely down to the Word file and DtP is required as it would be with any localization task where there are boundries around the space available for text.

I fully agree with Evzen here. The problem is, that the shape or line spacing in the target application is fixed. It does not matter, if that is a table cell or a text field - when you enter the translation there and the shape is fixed, you may end up with invisible text. How could Studio change that? It would need to modify the shape, but this is something a tool like Studio MUST NOT do. This is a task to be done in final layout. If you for example have a catalogue set in InDesign, full of shapes and pictures, and Studio would simply change the sizes of the shapes, the layout afterwards would simply be unusable.

So the entire problem here is not how the software works, but how the user does understand what is happening and why. And in the end of the day the user MUST accept the limits of the software used, resulting of the purpose for which the software is used. Studio is for translating text, NOT for any formatting. Period. All the formatting shall be done afterwards in the final format, for example Word or InDesign.

In situation like this, when merging does not bring you the result you expect, so is merging the wrong way. In that case the translation must be entered in segments like is and - in order to prevent writing nonsense to the TM - set on "Sign-off rejected" and locked. This way you can achieve exactly what is needed - the target file will show the translated text (provided you do not exceed the size of the shapes there). As Evezen says, if you exceed the length, even if the segments will not be merged the text in target will not appear properly. And this is in no way Studios fault. Only the user is to blame here. Should the user not understand his fault, so he does not understand the process and should learn that properly. This is realy as simple as that. The user does not need to be experienced localization engineer. A "simple" translator must be aware of text size, text formatting, table cells, shapes and so on. Otherwise such a peson cannot be called a translator in 21st century.