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

no

you'd better do not touch the source

and most of the time, it is NOT allowed

Unknown said:

no

you'd better do not touch the source

and most of the time, it is NOT allowed

In this case of course it is.  The whole problem comes from converting the original source, a PDF in a really poor way.  If you read the rest of my post you surely see the problem?

You didn't notice that the source is a Word file converted from PDF... which is a source not only allowed to touch, but actually required to touch.

so, what you have said is just one line.

"I will talk to tech part and wait/see" Right ?

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.

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.