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..

Paul Filkin said:

If you read the rest of my post you surely see the problem?

no there are no problem at all.

and

there are no solution at all too.

Yeah, the example was a bit extreme ;-)

I just disagree here...nonsensical requests are still nonsensical, no matter if they are made by people paying me.

"A better way of handling PDF" was known for ages - get the source format from which the PDF was created. Period.
And only if there is really really REALLY REALLY no chance to get the source, use the convert-to-word workaround, clearly understanding that it's just an emergency workaround with lot of drawbacks, not an easy-peasy day-to-day process.

That should be the message from big localization players towards the clients... because they don't believe poor translators, they believe only to big companies.

If the poor translators had their backs covered by such clear statements from big players, they would be able to argument with the ignorant clients... and won't be pushed to corner by "translate this PDF, or I'm going to ask someone else" requests.

EDIT::
Actually, getting back to the teleport example - I'm pretty sure that the salesmen most probably even DON'T request the teleport, simply because it's widely and publicly known that it's not possible.

It really doesn't help to look down on me and say "you have no idea about the technicalities". If I bought a BMW that gave conflicting readouts, I wouldn't expect to be sneered at by a BMW technician... Hopefully I would get it fixed. 

Nor would I expect or be interested in known "notorious" problems. 

Nor do I know for a fact that this came from a PDF... But from the way the lines are broken up it would appear blazingly obvious... Again, it's like taking the beamer back to the garage and them expecting you to tell them how the engine was originally constructed.

I'm a simple translator, trying to get a solution, that's all.  I've used pdfs and word countless times without problems.

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

Which puts the ball back in the Trados court, since it either falsely shows merged and translated text in the editor view or falsely shows missing text in the preview. Blame whatever you want, but this problem continues unresolved.

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

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.

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.