ah.. found it

It is not related with the Merge

It is the problem of "some kind of MS Word vertical arrangement", I guess..

It is a TABLE, the height of CELL has restriced with unknown reason.

Just let it go, then you will be happy again

Bye..

If you'd buy a BMW with LHD, you will have a bit of trouble driving it in the UK. And if the car needs gasoline and you fill it up with diesel, it will end in a disaster. When you drive the car and it has a manual gearshift, you'll damage the engine, when you swicth the 2. gear while driving 200.

What you get from Studio are not conflicting readouts, but a file formatted as the source was. The problem here is, that you seem not to accept, that the software has its limits, which are no problem, if you know how it works. Same as with the car - it delivers what you expect, if used properly.

Evzen Polenka said:

But you DO show it in preview and you DO save it in the target too...
It's all about just the bad formatting of the source and the VISUAL(!!!) result...

I disagree Evzen.  The reason this is a problem is because of the way Studio handles the merged segments.  By adding more content into the first row it no longer fits.  There must be a smarter way to deliver this so that we allow the merge and put the content back into two rows.  I there could be difficulties in deciding which part of the translated text goes into which row but I'm sure doing something smart (maybe counting chars for example) could help to solve an issue like this this.

If we solved it then we would go some way towards solving the problem seen when people merge in markup files too.

I know in this case the source is a pile of crap, but I also think there is a real problem to try and solve here, and not by repairing the target file afterwards as this is only something you could do after seeing it needs to be done.  If the merge was handled in a smarter way, and I know this is actually very difficult to achieve because of the way we work with files, then a repair of the target file might not be needed at all.

Make a virtual merge for that - instead of physically moving the text into the first cell like it is done now, simply connect the segments only for TM purposes, but leave them in the cells like is.

Such kind of merge would be done AFTER having inserted all the translations row by row and then selecting the segments to be merged virtually. As this would not change the structure of any kind of file, it should work literally for all file formats.

So Studio would then be able to physically merge segments or to merge them virtually. Virtual merge should be available all the time, merging across paragraph breaks should be optional as it is now. There should be a warning when switching it on, telling to take care of the merged segment in the final file and to make sure the file format does support such a merge.

Just leaves the problem of deciding which part of the translation goes into which segment.  Can be done mathematically, but this may not be the rght way, so some editing would be required.

But you can see this isn't a simple solution, and the more we talk about it the more I'm inclined to think it wont happen... as much as I'd like it to.  The effort, compared to the number of times this is needed, don't really match.  So even if everyone thinks it's a good idea it will always get a lower priority than anyting else.

Paul Filkin said:

The reason this is a problem is because of the way Studio handles the merged segments.  By adding more content into the first row it no longer fits.

Nope... as I demonstraed on my screenshot, it has NOTHING to do with the merging.

The problem appears even if you translate each segment separately - when the translation gets longer than can fit in the fixed space, it "disappears".

Just look at the screenshot with the two marked segments where the barely-visible traces/artifacts of the text are marked.

Robert Kingsmore said:

It really doesn't help to look down on me

I'm not looking down on you. I'm just stating the pure truth.
It may not sound pleasant, but that's not my fault. It's just a naked truth; it doesn't always sound good.

Robert Kingsmore said:

Nor do I know for a fact that this came from a PDF

Hmmm, how comes then that YOU mentioned that fact yourself:

John Kingsmore said:

As with many projects worldwide, a pdf was machine translated and the bilingual file sent to me for post-editing.

Robert Kingsmore said:

And if I had a PDF or the doc file, without trados, I would be fine.

But you DO have the DOC file! You can save it from Studio using Advanced Save... didn't you know that?

Robert Kingsmore said:

And if I wasn't using Trados I wouldn't have this problem.

You mean, if you would be typing in the Word file directly?
Then you would have exactly the same problem, just try it...

Or you mean, if you would use different CAT tool?
Then I truly believe that you would have exactly the same problem either, because the cause is the source Word.

Evzen Polenka said:

Nope... as I demonstraed on my screenshot, it has NOTHING to do with the merging.

I probably didn't explain that well.  But the "merging" across paragraph breaks is not a true merge.  What we do, as I'm sure you know, is we cut the content out of the second segment, hide it, and add the content to the first segment.  So when I say this is about how we are merging segments that's what I mean.

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.

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.