John Kingsmore

Is this a refresh issue?  What happens if you close the file, switch projects, then come back to this one again and preview it?

Would also be good to know what type of file this is and maybe share a screenshot too (you can simply copy/paste into the forum)?

It's a regular sdlxliff file sent containing a single .docx

John Kingsmore

My guess is that the preview is based on the original file which is held inside the sdlxliff and the updated text, whilst part of a merged segment is actually linked to the first segment in the merged group.  So the other merged parts are not seen and as segments #75 and #76 are now removed (since the merge is really an automated hack) the preview misses them out altogether.

This looks like a bug in the preview, but the target file should be fine.  Press Shift+F12 to quickly create a target file and tell me if everything is ok?

Nope ... target file is identical to the preview ... text missing

Is the text part of a table? Do the merged paragraphs belong to the same document structure level? Are there any tags (possibly invisible?)?

No tags[tried all that, toggling to see if theere were any, even removing all formatting]; logically, the merged paragraphs would appear to belong to the same document structure level since they are all the same sentence; as seen from the images, there would appear to be no visible table involved - all i got was a single sdlxliff file. 

Even if there was some invisible table, surely the merge would have merged the segments - i.e. the cells? Again, the source AND target text both only show the first line of text after merging... so the merge function seems to have removed the text in segments 2 and 3, for example - both in the preview and in the F12 target file - ...even though it all looks good if the sdlxliff file is opened in Trados...

[I should add, it all works fine elsewhere in the document - i.e other merged segments show ALL the text, both source and target, both embedded and Word previews...

How do you check the source? And what will happen, if you NOT merge the segments, but use "Edit source" and put all the text from the broken segments in the LAST segment?

And does the text appear in target without merging?

John Kingsmore said:

Even if there was some invisible table, surely the merge would have merged the segments - i.e. the cells? Again, the source AND target text both only show the first line of text after merging... so the merge function seems to have removed the text in segments 2 and 3, for example - both in the preview and in the F12 target file - ...even though it all looks good if the sdlxliff file is opened in Trados...

If you merged across parapgrah segments this could be the cause of the issue... because it's a hack.  That's where Jerzy is coming from by asking about table cells for example.  There was a reason why Trados never supported merging across paragraph breaks for years and the eventual implementation was an automation of simply taking the text out of the subsequent source segments and copy/pasting into the first one.

If there are tags between they will be left where they are and the content between them will now be missing.  This is explained here:

https://multifarious.filkin.com/2016/11/21/bridging-the-divide-merging-segments/

So for some filetypes it's not a good idea to enable merging across para segments.  In this case, woth word, it's fne.  But it seems the preview is broken as mentioned before.

Oh, even in Word you must be careful. It is enough, that an anchor point is in one of the merged segments or - even worse - was between these! In that case you can create target, but won't be able to open it in Word.

As for the method of merging - this was possible since 2009 or at least 2011, afair. Simply as soon you allowed to edit source. But from my experience edit source does not cause ANY problems in ANY format, while merging will damage some.

Oh, even in Word you must be careful. It is enough, that an anchor point is in one of the merged segments or - even worse - was between these! In that case you can create target, but won't be able to open it in Word.

As for the method of merging - this was possible since 2009 or at least 2011, afair. Simply as soon you allowed to edit source. But from my experience edit source does not cause ANY problems in ANY format, while merging will damage some.

Jerzy Czopik said:

But from my experience edit source does not cause ANY problems in ANY format, while merging will damage some.

It will if you use the edit source to remove the content and copy into another segment Jerzy.  You can end up with markup files that are missing content where it must be there.

Ironically, I tried it and it worked! I unlocked the second [erstwhile merged] segment, and cut and pasted from both the source and the target... now it looks fine [except that the 3rd merged segment shows as a blank line]... but what a complete waste of time!

I do not leave the source segments empty, but place XXX there. The translation is then two spaces. It worked until now in 100% of all cases.

Jerzy Czopik said:

I do not leave the source segments empty, but place XXX there. The translation is then two spaces. It worked until now in 100% of all cases.

It wouldn't work in all cases though Jerzy.  If it was important for the target application to take the content of the, now empty elements (spaces are empty), and use this in a specific location it would now fail to be suitable for purpose.  It would require additional work from a localization engineer to fix them.

C'mon, this is a rare problem. Try to work with any other tool and then compare this "waste of time" with what you can or cannot do there. You've spent hours on discussing this "problem" here, which most probably will not occur in the vast majority of other Word docx files. Same can happen to you on a motorway: you'll drive it for years, until one day there will be a nail and you will waste time replacing your tyre...

Then this will be the price he has to pay for preparing a file with not translatable content. Broken segments may not harm in English, but can lead to huge problems in other languages.

Try to translate this into English:

<p>Mit der Maschine können</p><br>
<ul><li>Dosen</li><br>
<li>Flaschen</li><br>
<p>produziert werden</>

What do you put in the last segment?

Now imagine, you have confirmed this translation and stored in your TM. And then you go for this:

<p>Mit der Maschine können</p><br>
<ul><li>Dosen</li><br>
<li>Flaschen</li><br>
<p>abgefüllt werden</>

This is a typical example of a badly written and formatted text. If that is Word, an empty segment will not harm. But if as you say, an empty segment makes a problem in another format, the author MUST not produce such crap. Otherwise he'll pay afterwards, if his content does not work As simple as that.

Jerzy Czopik said:

This is a typical example of a badly written and formatted text. If that is Word, an empty segment will not harm. But if as you say, an empty segment makes a problem in another format, the author MUST not produce such crap. Otherwise he'll pay afterwards, if his content does not work As simple as that.

Agreed.  Source content has an important part to play in the whole process, and it's often misunderstood.

It's a Word document: why "try to work with any tool " at all? Trados has not helped me in any way. I only use it if I have to. For this very reason. Not only do I waste hours trying to fix problems I wouldn't have if I just used Word, I can't even physically see the Word document - or it shows problems I can't fix in the xliff file that I could fix if it was a simple word file. Why send ac xliff for a single word doc in any case? This one has no charts/tables etc. ... And I'm not seeking to discuss anything - I just want the answer, to fix what shouldn't be happening.

And as Jerzy alludes to, the TM is completely pointless when the German text is chopped up into 'untranslatable' segments that can't be merged properly: it defeats the purpos of using Trados at all.

Jerzy Czopik John Kingsmore

Come on guys... we concluded at the start this is a bug.  We need to fix it... that's all there is to it.

John Kingsmore

John Kingsmore said:

And as Jerzy alludes to, the TM is completely pointless when the German text is chopped up into 'untranslatable' segments that can't be merged properly: it defeats the purpos of using Trados at all.

Yes, but note that this is a source document problem and should be resolved there.  We can't expect a CAT tool to take content and handle it perfectly when it's been prepared without any thought towards localization.

If you handle it in Word you are effectively working in the source application, so of course that will help to avoid any problem over segmentation isues.

The preview issue is something else.  We need to fix this.