Bad segmentation - missing </mrk> tag in the target XLIFF file

Hello,

I have a problem regarding the marker element </mrk> a of a target *.xlf file. Sometimes, a target translation of a segment is not enclosed correctly by </mrk> tag, but reamins unclosed with the opening tag in this form: <mrk mtype="seg" mid="[number-of-segment]" />. This problem seems to affect the segments randomly: target files, results of work of different translators who worked with the same source file, do not follow any pattern in distribution of this problem. See the example below:

This is a source

<trans-unit id="834" datatype="plaintext" resname="apm_AlertMessages.DaemonNotRunning" extradata="First batch">

<source>APM has stopped.</source>

<seg-source>

<mrk mtype="seg" mid="1">APM has stopped.</mrk>

</seg-source>

</target>

<note/>

</trans-unit>

This is a target translation in Spanish. Note the correct presence of </mrk> tag in <target>:

<trans-unit id="834" datatype="plaintext" resname="apm_AlertMessages.DaemonNotRunning" extradata="First batch">

<source>APM has stopped.</source>

<seg-source>

<mrk mtype="seg" mid="1">APM has stopped.</mrk>

</seg-source>

<mrk mtype="seg" mid="1">Se ha detenido APM.</mrk>

</target>

</trans-unit>

And this is a target of the same source, now in French. Here, the </mrk> is missing:

<trans-unit id="834" datatype="plaintext" resname="apm_AlertMessages.DaemonNotRunning" extradata="First batch">

<source>APM has stopped.</source>

<seg-source>

<mrk mtype="seg" mid="1">APM has stopped.</mrk>

</seg-source>

<mrk mtype="seg" mid="1" />APM s'est arrêté.

</target>

</trans-unit>

I'd like to know how to adjust the source file to make it work properly - this way the targets do not show up at all in SDL Trados. It doesn't seem to be a problem of the source file though, because some targets can cope with the above-mentioned form of empty target translation (<mrk mtype="seg" mid="[number-of-segment]" />) just fine. The translators use SDL Trados 2011.

Does anyone have any idea? I'd be grateful for any comments and suggestions.

Thank you!

Best Regards,

Jonáš.

Translate

Rate translation

Suggest better translation

Moderator UI

Thread Subject & Description
Bad segmentation - missing </mrk> tag in the target XLIFF file Hello, I have a problem regarding the marker element </mrk> a of a target *.xlf file. Sometimes, a target translation of a segment is not enclosed correctly by </mrk> tag, but reamins unclosed with the opening tag in this form: <mrk mtype="seg" mid="[number-of-segment]" />. This problem seems to affect the segments randomly: target files, results of work of different translators who worked with the same source file, do not follow any pattern in distribution of this problem. See the example below: This is a source <trans-unit id="834" datatype="plaintext" resname="apm_AlertMessages.DaemonNotRunning" extradata="First batch"> <source>APM has stopped.</source> <seg-source> <mrk mtype="seg" mid="1">APM has stopped.</mrk> </seg-source> <target> <mrk mtype="seg" mid="1"/> </target> <note/> </trans-unit> This is a target translation in Spanish. Note the correct presence of </mrk> tag in <target>: <trans-unit id="834" datatype="plaintext" resname="apm_AlertMessages.DaemonNotRunning" extradata="First batch"> <source>APM has stopped.</source> <seg-source> <mrk mtype="seg" mid="1">APM has stopped.</mrk> </seg-source> <target state="final"> <mrk mtype="seg" mid="1">Se ha detenido APM.</mrk> </target> <note /> </trans-unit> And this is a target of the same source, now in French. Here, the </mrk> is missing: <trans-unit id="834" datatype="plaintext" resname="apm_AlertMessages.DaemonNotRunning" extradata="First batch"> <source>APM has stopped.</source> <seg-source> <mrk mtype="seg" mid="1">APM has stopped.</mrk> </seg-source> <target state="final"> <mrk mtype="seg" mid="1" />APM s'est arrêté. </target> <note /> </trans-unit> I'd like to know how to adjust the source file to make it work properly - this way the targets do not show up at all in SDL Trados. It doesn't seem to be a problem of the source file though, because some targets can cope with the above-mentioned form of empty target translation (<mrk mtype="seg" mid="[number-of-segment]" />) just fine. The translators use SDL Trados 2011. Does anyone have any idea? I'd be grateful for any comments and suggestions. Thank you! Best Regards, Jonáš.
Get AI Suggestion

AI Reply

Accept answer Reject Answer

0 Paul over 7 years ago

Hi Jonáš Pospíchal ,

I seem to recall this problem in an older version, and as your translators are using 2011 which is certainly well out of support I think your only resolution is to upgrade them. Or use their TMs to pretranslate the source file prepared in a more modern version of the tool. Perhaps test it with the trial to satisfy yourself this is the problem.

Paul Filkin | RWS Group

________________________
Design your own training!
You've done the courses and still need to go a little further, or still not clear?
Tell us what you need in our Community Solutions Hub
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Reject Answer

Cancel

Share
Documentation Survey: help us offer you better documentation! Translate
0 Evzen Polenka over 7 years ago in reply to Paul

Do you mean that Studio 2011 "corrupts" the SDLXLIFF in a way that generating the target file from that SDLXLIFF in a newer Studio version creates this effect?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Share
Documentation Survey: help us offer you better documentation! Translate
0 Paul over 7 years ago in reply to Evzen Polenka

Not sure how you interpreted that from what I said Evzen? I meant what I said, this was a problem in an older version. So processing the XLIFF file in an older version at some point did, under some circumstances I can't remember, leave out the closing mrk tag.

Paul Filkin | RWS Group

________________________
Design your own training!
You've done the courses and still need to go a little further, or still not clear?
Tell us what you need in our Community Solutions Hub
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Share
Documentation Survey: help us offer you better documentation! Translate
0 Evzen Polenka over 7 years ago in reply to Paul

My understanding of the situation is that the translators do NOT generate the final files, but that the workflow is "standard LSP workflow", i.e. translators return packages/SDLXLIFFs and generating the target files happens on the LSP's side, i.e. that the target files are generated by Jonas, NOT the translators.
That's why I asked what I asked...
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Share
Documentation Survey: help us offer you better documentation! Translate
0 Paul over 7 years ago in reply to Evzen Polenka

ok, I see what you mean Evzen. It would probably be helpful to know who prepared the files, and what version of Studio was used as well as confirmation of the workflow. I definitley didn't mean anything about the later versions here as this is a problem I was only aware of when we only had the older versions. To be honest I only remember something like this anyway... I have not tried to find evidence. So more information and even a way to reproduce the problem would be useful.

Paul Filkin | RWS Group

________________________
Design your own training!
You've done the courses and still need to go a little further, or still not clear?
Tell us what you need in our Community Solutions Hub
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Share
Documentation Survey: help us offer you better documentation! Translate
0 Jonáš Pospíchal over 7 years ago in reply to Paul

Hello,

thank you both for your answers and suggestions.

Unfortunately, the workflow doesn't look as described by Evzen (although that I would prefer), because my Trados 2017 doesn't cope with Trados 2011 SDLXLIFF files from the translators - a problem we were (literary Evzen and me) discussing earlier here: community.sdl.com/.../55621 .

That's why I work with XLF files only, which is a workflow that causes the above-mentioned problem. However, solving the previous problem with SDLXLIFF would also solve this new problem completely. Paul , do you think there might be a way how to do this?

Thank you.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Share
Documentation Survey: help us offer you better documentation! Translate
0 Evzen Polenka over 7 years ago in reply to Jonáš Pospíchal

Jonas, so how about not letting the translators create the SDLXLIFF (which then gets created using the outdated XLIFF 1.1-1.2 v 1.0.0.0 file type), but creating the SDLXLIFFs by you (using the current XLIFF 1.1-1.2 v 2.0.0.0 file type)...
I.e. don't send out source XLF, but prepared packages or SDLXLIFFs instead.

Then your problem with generating the target XLFs from the other thread will be solved... and problem from this thread will wanish away too.

(Yes, translators will then get that information message that the SDLXLIFFs were "created using file type definition which does not exist on their system and that some functionality will be restricted or unavailable", but that's fine, that does not prevent them from translation.)
Cancel
Vote Up 0 Vote Down

Sign in to reply

Reject Answer

Cancel

Share
Documentation Survey: help us offer you better documentation! Translate
0 Jonáš Pospíchal over 7 years ago in reply to Evzen Polenka

Hello Evzen,

I'll be brief: this works.

Or, at least, the translators can read it and edit it, which should be the same.

Thank you very much for this suggestion.

Jonáš.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Share
Documentation Survey: help us offer you better documentation! Translate

Trados Studio > 1. Trados Studio

Bad segmentation - missing </mrk> tag in the target XLIFF file