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

I have my own language MS Word version, so UI naming should be different from English one, pls consider..

1. click Your contents - I mean the "TABLE" part
2. You see "TABLE tool > Layout" at top right side of Your screen
3. click small triangle at "CELL size"
4. Table attribute > Row > Height setting > UnCheck it. and.. Click "Confirm"
5. Done

hmm, I am not good at this kind of tedious manual job - I prefer to use VBA.

You'd better do it "One Go" style, I mean...  find "All Select TABLE" something and do the procedures I mentioned above.. OK ?

Good Luck To You

if you want..

Dim myTable
If ActiveDocument.Tables.Count > 0 Then
For Each myTable In ActiveDocument.Tables
myTable.Rows.HeightRule = wdRowHeightAuto
Next
End If

Unknown said:

It is a TABLE, the height of CELL has restriced

That's EXACTLY what I thought when I saw the original post the first time...
And that's what also Jerzy asked right away...

So the whole story is rather about lack of user Word skills than a Studio problem.

SDL Trados Studio's translated final docx has lots of "<w:trPr><w:trHeight w:val="someFigure" w:hRule="exact"/></w:trPr>" element.

I my opinion it is NEEDLESS.

And it is the root cause of SDL Preview's unusual behavior too.

So, if possible, it should be disappearead. 

If that is in the source file as well, Studio MUST NOT remove it.
And yes, if that is in the source file, the source file is formatted stupidly not localization friendly, as also already mentioned in this thread.

So again, not a Studio problem in fact.

This is entirely a Studio problem, since

1. a) the original source xliff/project was made by Studio and
2. b) the target file, also produced by Studio, is also coming out wrong when segments are merged.

To say "the whole story is rather about lack of user Word skills than a Studio problem" shows a complete ignorance of the process:

• As with many projects worldwide, a pdf was machine translated and the bilingual file sent to me for post-editing.
• IE at no stage was there ever any "user Word skills" involved in the xliff file sent to me.
• The machine translation was obviously done by machine and the file created was created by Studio.

Second, DL Trados Studio's translated final docx is also necessarily nothing to do with a user and everything to with Trados.

Equally, if the source file [created by Trados] has these errors, why were thy not flagged up by Trados when the source xliff was created?

If "the source file is formatted not localization friendly", why?

Why has Trados not caught this?

Finally, regardless of all this, the fact remains that while the merged segments work in most cases, the translator will see the translation as perfect in the editor view of Trados, but will only know about this problem by generating a preview.

Clearly this fact alone is entirely a Trados problem and nothing to do with the user or with word: Trados [not the user, not Word] shows the translation as complete in the editor view, but not in the preview.

easy, my friend

you are quite right

"Machines are idiot" including the most advanced DeepLearning and AbyssLearning WhatSoEver...

It needs smart people's touch, just like you.

And never mind biased opinions, just ignore it.

Regards

it is hard to say as a BUG, but it is very clear that something should be done form SDL side not from user side. 

John Kingsmore

Thanks for the "sample" file.  I created the sort of file I was looking for from your file by saving the source, editing the source and then using that.  File attached so you can see what I was getting at:

small_test.docx

The conclusions I can draw from this are these:

1. The docx is really poorly prepared so I 100% agree with Evzen here.  You for example see that these two rows are on completely different table rows... separate paragraphs:
   
   
   
   And here, the second part of the sentence is a header and also part of a separate table row and different paragraph:
   
   
   
   
2. Studio should still be able to handle the preview in my opinion.

You can sort of see what's happening since a merge with the initial preview shows the highlighted segment of the first one even after the merge took place and it doesn't pick up the fact that there is more text there.  So the link between the original source file where this is a completely separate table row is still there and the preview associates the merged text with the second row in the table and not this segment.  As soon as you refresh the preview it won't see this additional text at all:

So yes, the document that has been presented is a terrible (or really good) example of a file given to anyone to localize when they are using a CAT tool that really does care about formatting to the extent Studio does.  But sometimes I think Studio needs a "lenient mode" where it's a little more forgiving to make the translation process easier for the translators since we will never change the ability of our clients, or many translators (by this I mean technical ability AND the time they have available to turn the translation around), to be able to fix a document like before translating.  Might be worth looking at the tools being used for the PDF conversion though as there may be much better ones available that don't put things into lots of tables like this.  I think I've seen some free online PDF converters do things like this and in these cases it would be simply better to hand the PDF to the translator since most CAT tools can do a better job handled the right way.

It's also another very good example of why we never supported merge across paragraphs before as it can present some challenges because of the way Studio handles paragraphs to provide additional information to the user that most CAT tools don't.

I'll log this example as a bug and let you know when I have some comment on this from the deveopment team.

John Kingsmore

Thanks for the "sample" file.  I created the sort of file I was looking for from your file by saving the source, editing the source and then using that.  File attached so you can see what I was getting at:

small_test.docx

The conclusions I can draw from this are these:

1. The docx is really poorly prepared so I 100% agree with Evzen here.  You for example see that these two rows are on completely different table rows... separate paragraphs:
   
   
   
   And here, the second part of the sentence is a header and also part of a separate table row and different paragraph:
   
   
   
   
2. Studio should still be able to handle the preview in my opinion.

You can sort of see what's happening since a merge with the initial preview shows the highlighted segment of the first one even after the merge took place and it doesn't pick up the fact that there is more text there.  So the link between the original source file where this is a completely separate table row is still there and the preview associates the merged text with the second row in the table and not this segment.  As soon as you refresh the preview it won't see this additional text at all:

So yes, the document that has been presented is a terrible (or really good) example of a file given to anyone to localize when they are using a CAT tool that really does care about formatting to the extent Studio does.  But sometimes I think Studio needs a "lenient mode" where it's a little more forgiving to make the translation process easier for the translators since we will never change the ability of our clients, or many translators (by this I mean technical ability AND the time they have available to turn the translation around), to be able to fix a document like before translating.  Might be worth looking at the tools being used for the PDF conversion though as there may be much better ones available that don't put things into lots of tables like this.  I think I've seen some free online PDF converters do things like this and in these cases it would be simply better to hand the PDF to the translator since most CAT tools can do a better job handled the right way.

It's also another very good example of why we never supported merge across paragraphs before as it can present some challenges because of the way Studio handles paragraphs to provide additional information to the user that most CAT tools don't.

I'll log this example as a bug and let you know when I have some comment on this from the deveopment team.

Paul Filkin said:

Thanks for the "sample" file.  I created the sort of file I was looking for from your file by saving the source, editing the source and then using that.  File attached so you can see what I was getting at:

Woo..

You wrote "448 words" and I have failed to find Your solution for this problem.

Did I miss something ?

If so, can you please tell me that a little bit more briefly ? 

regards

Unknown said:

Woo..

You wrote "448 words" and I have failed to find Your solution for this problem.

Did I miss something ?

Yes.  There isn't one!  At least not without correcting the source file first.

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.