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

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 said:

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.

Sorry man, but this clearly indicates that you have no idea about the technicalities behind the whole story and therefore make totally wrong conclusions.

First of all, if you would mention right at the beginning that the source was a PDF, the entire discussion would have been MUCH shorter!

It's notoriously known that PDF as a source is evil and very bad idea.
PDF was ALWAYS meant ONLY FOR VISUAL CONSUMPTION and NEVER meant for editing... therefore it lacks some information needed for editing... therefore the applications attempting to edit PDFs have to GUESS these information since they have no way to know the original intentions of the creator of the actual source format from which the PDF was created... and therefore the result is way too often just as sh*tty as in your case.

It's also notoriously known that Studio uses 3rd party automatic PDF-to-DOCX conversion behind the scenes.
Since it's automatic, the above paragraph applies...
And since it's 3rd party, Studio has no way to influence the result... hence it's NOT Studio problem.

Second, it's also notoriously known and mentioned everywhere that the intermediate DOCX file coming from the automated conversion should be manually edited and cleaned from the sh*t before stuffing it to any localization software (i.e. not only Studio!!!).
So yes, it's indeed about lack of user knowledge (either knowledge about the required cleaning, or the knowledge WHAT and HOW to clean)....

And third, the entire problem has nothing to do with merging segments in fact, the same issue - caused by the sh*tty Word source! - can be seen without merging as well.
The preview DOES contain the entire text, indeed... it's just not/hardly visible due to the fixed table row height.
The following screenshot shows the hard-to-see artifacts of the remaining text without any merging, just previewing the SDLXLIFF you posted.

Evzen Polenka said:

John Kingsmore said:

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.

Sorry man, but this clearly indicates that you have no idea about the technicalities behind the whole story and therefore make totally wrong conclusions.

I don't disagree with you that the source is poor, but in general I agree with John and I think we should be able to handle this better.  I don't think it is the job of translators to understand the technicalities in the same a way a seasoned localization engineer would.  If Studio was sold as a tool designed only for these specialists I think you might have a point, but it's not.  So I personally think we should fix this.

I beg to disagree a bit. The translators must know, how the tool works and they MUST know, what happens with a PDF file, when it is simply thrown on Studio without taking care about the post processing. The life has changed and we live in 21st century. But TBH the "translators not understanding technicalities" was never valid. Even as we translated from paper, you had to know how formatting in Word works. Now things got more complicated and we have to deal with many more formats than just plain paper. Understanding how your tool works is a necessary prerequisite to deliver high quality translation. Otherwise you deliver crap - even if the translation as such is lingusticaly OK.

There is no excuse for translator not to know the tool used. Exactly as there is no excuse to a nurse not knowing how to enter the data of the patient in her computer. If other processions can learn using computer to their need, I do not see why should translators be excused here.

Jerzy Czopik said:

I beg to disagree a bit. The translators must know, how the tool works and they MUST know, what happens with a PDF file, when it is simply thrown on Studio without taking care about the post processing.

Well, this is an interesting twist ;-)  Translators telling us we don't need to fix something!!

It is certainly a good idea for everyone to learn as much as they can about their software, but that doesn't excuse the software from being able to make this easier and reduce the effort required to mirror the source files provided.  Just because the source files are a poor conversion does not excuse the software from being able to handle them.  We can extract the text ok, so it seems logical that we should be able to preview it and save the target too.

Let's keep this to a discussion on this specific problem... I doubt we disagree about the rest.

IMO, SDL made a kind of mistake when they implemented this "easy for translator" process for translating PDFs.
Something what perhaps originally looked like a competitive advantage turned very quickly to a pain-in-the-ass...

If I would be a product manager, I would seriously think about removing this feature....

Paul Filkin said:

Translators telling us we don't need to fix something!!

But well, there is really nothing to fix... everything works just fine, as I just showed...

Paul Filkin said:

it seems logical that we should be able to preview it and save the target too

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

Paul Filkin said:

Translators telling us we don't need to fix something!!

But well, there is really nothing to fix... everything works just fine, as I just showed...

Paul Filkin said:

it seems logical that we should be able to preview it and save the target too

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

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.

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.