DeepL plugin not preserving some formatting in Trados 2022

I recently upgraded from Trados 2021 to Trados 2022. 
I do a lot of MTPE for which I use the DeepL plugin, but unfortunately with Trados 2022 some important formatting and URLs are omitted, an issue I did not have with Trados 2021.
For example, the source says:
I accept the&nbsp;<a target="_blank" href="{{url}}">terms & conditions</a>.
DeepL translates this to:
Ich akzeptiere die Allgemeinen Geschäftsbedingungen.
When it should be:
Ich akzeptiere die&nbsp;<a target="_blank" href="{{url}}">Allgemeinen Geschäftsbedingungen</a>.
Could someone please help me solve this issue, if possible? I'm including my DeepL settings in Trados below (same ones I used in 2021).
emoji
Parents
  •  

    Thanks for posting in here.  I did ask you to provide a file as this makes it easier to support you as I won't be giving you an "it works here" response which is what I will do.  I created a file to test like this:

    <!DOCTYPE html>
    <html lang="en">
    <head>
        <meta charset="UTF-8">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <title>Sample File</title>
    </head>
    <body>
        <p>I accept the <a target="_blank" href="{{url}}">terms & conditions</a>.</p>
    </body>
    </html>

    Add to a project and translate with DeepL... like this:

    Screenshot of RWS AppStore Applications interface showing a translation project. The source text 'I accept the terms & conditions' is translated to German as 'Ich akzeptiere die Allgemeinen Geschaftsbedingungen'. No visible errors or warnings.

    Can you provide a sample of the file you are working with?  Even the filetype you have would be better than nothing but a proper sample would be better.

    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



    Generated Image Alt-Text
    [edited by: RWS Community AI at 7:01 PM (GMT 1) on 3 Jun 2024]
  • Unfotunately, I'm not entirely sure how to create a sample file, but I think there might be a misunderstanding - I will try to be clearer: The files where I'm encountering these issues with Trados 2022 are exported from Phrase and CrowdIn - when I load the exact same files into Trados 2021 (which I'm still running on my laptop) the DeepL plugin does not exhibit the issue.

    The formatting I'm referring to is right in the text, please see below:

    I accept the&nbsp;<a target="_blank" href="{{url}}">terms & conditions</a>.
    DeepL in Trados 2022:
    Ich akzeptiere die Allgemeinen Geschäftsbedingungen.
    DeepL Trados 2021:
    Ich akzeptiere die&nbsp;<a target="_blank" href="{{url}}">Allgemeinen Geschäftsbedingungen</a>.
    Please also see screenshot below (Trados 2022):
    Screenshot of a translation software interface showing a comparison between source and target texts. The source text includes HTML anchor tags with placeholder URLs. The target text shows the translated version without visible HTML tags.
    emoji


    Generated Image Alt-Text
    [edited by: RWS Community AI at 7:17 PM (GMT 1) on 3 Jun 2024]
  • Again, I believe there is a misunderstanding. 

    Using the exact same files, with the same method of preparation, DeepL does not consider the formatting (please refer to previous screenshot) in Trados 2022 but does consider it in Trados 2021. 

    It can't be due to the file type, as I'm using the same files (.xliff) in Trados 2021 and Trados 2022. 

    emoji
  •  

    DeepL does not consider the formatting (please refer to previous screenshot) in Trados 2022 but does consider it in Trados 2021. 

    In your screenshot you are showing a file that has not been prepared for translation and this can only lead me to believe your settings are not the same.  I don't think DeepL has anything to do with this problem.  Please confirm the following:

    1. which filetype in Studio is being used to process the file?  Please check 2021 and 2022.
    2. is the embedded content processor being used in 2021 and not in 2022?  This is not turned on by default.

    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

    emoji
  • Can you please let me know how to check for this information to avoid further confusion?

    If the Embedded Content Processor is not enabled by default, I have not enabled it myself in either version of Trados.

    Regarding "prepared for translation", I usually add any files for translation to a project and let Trados do its thing - I have done this since Trados 2017, so I'm a bit lost what you mean by the file from my screenshot not having been prepared for translation? 

    I'm guessing there's something in Trados 2022 that changed from the previous versions, hopefully only some option I can enable globally.

    I'm not sure whether the screenshot below will help, but this is what I see for Embedded Content Processors in both 2022 and 2021. The file in editor is shown as .xliff.sdlxliff (again, I'm not sure if this is what you wanted to know).

    Screenshot of RWS Trados Options dialog showing Embedded Content Processor settings with file types Plain Text, Microsoft Excel 2007-2019, and HTML 5 listed.

    emoji


    Generated Image Alt-Text
    [edited by: RWS Community AI at 9:19 PM (GMT 1) on 3 Jun 2024]
  •  

    ok - perhaps this short video is better:

    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

    emoji
  • Thank you for taking the time to do this video, much appreciated.

    I did verify the file type and checked for the according Embedded Processor settings - unfortunately, they were turned off in both Trados 2021 and 2022. Turning it on in 2022 has not changed the DeepL behavior.

    For reference: Screenshot showing a software version label 'XLIFF 1.1-1.2 v2.0.0.0'.

    emoji


    Generated Image Alt-Text
    [edited by: RWS Community AI at 9:42 PM (GMT 1) on 3 Jun 2024]
  •  

    Did you prepare the project yourself?

    Would you be able to send me the source file (if acceptable)?  You have my email so no need to share in here.

    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

    emoji
  • Thank you for offering, but unfortunately, I can't send the file as to not violate the agreement with my client. The file was exported as XLIFF from a platform called "CrowdIn", then added to the project - I have done this many times over the years (same file types, same procedure in Trados), the issue only started with Trados 2022 for me.

    As additional information, I'm using the exact same file(s) in 2022 and 2021 here. I'm also experiencing the issue with mxliff files (exported from Phrase).

    For the time being, and if we can't find a different solution, I guess I could prepare the MT on my laptop for future files, then transfer them to my desktop for final editing in Trados 2022 - or just install 2021 next to 2022, if my license permits. It wouldn't be an elegant solution, and I hope this issue won't persist in Trados 2024.

    emoji
  •  

    ok - understood.  I am almost certain that the problem here is the preparation of the file.  I cannot comment 100% though without seeing the file.  If you were able to create a sample based on the one you have it would have been helpful.  For example, XLIFF is structured in a simple way so if you were to take a copy of the file (so as not to damage the original) and open it in a text editor you will something like this:

    <?xml version="1.0" encoding="UTF-8"?>
    <xliff version="1.2">
      <file source-language="en" target-language="de" datatype="plaintext" original="messages">
        <body>
          <trans-unit id="1" resname="accept_terms_conditions">
            <source>I accept the <a target="_blank" href="{{url}}">terms & conditions</a></source>
            <target>I accept the <a target="_blank" href="{{url}}">terms & conditions</a></target>
          </trans-unit>
          <trans-unit id="2" resname="welcome_message">
            <source>Welcome to our application!</source>
            <target>Welcome to our application!</target>
          </trans-unit>
          <trans-unit id="3" resname="login_prompt">
            <source>Please enter your username and password to log in.</source>
            <target>Please enter your username and password to log in.</target>
          </trans-unit>
          <trans-unit id="4" resname="error_message">
            <source>An unexpected error occurred. Please try again later.</source>
            <target>An unexpected error occurred. Please try again later.</target>
          </trans-unit>
        </body>
      </file>
    </xliff>

    Note that the structure is all quite logical and the file consists of a series of elements called <trans-unit>.  Delete all the trans-units apart from one like this that contains the problem code you already shared:

    <?xml version="1.0" encoding="UTF-8"?>
    <xliff version="1.2">
      <file source-language="en" target-language="de" datatype="plaintext" original="messages">
        <body>
          <trans-unit id="1" resname="accept_terms_conditions">
            <source>I accept the <a target="_blank" href="{{url}}">terms & conditions</a></source>
            <target>I accept the <a target="_blank" href="{{url}}">terms & conditions</a></target>
          </trans-unit>
        </body>
      </file>
    </xliff>

    See if you can reproduce the issue with just that one trans-unit.  If you can just share that file with me.

    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

    emoji
  •  

    Thanks for sending me a file that reproduces the problem.  The file you have sent me is not an XLIFF… or rather it is an XLIFF but a very specific XLIFF with the MXLIFF extension.  If you open this up in Trados Studio 2022 it will use the MXLIFF filter so I do not know how it could possibly be the XLIFF 1.2 filter you showed in here.  It will be this one: 

    Memsource Xliff v 1.0.0.0

    This filter is designed specifically for Memsource (Phrase) XLIFF files and handles the content appropriately using the custom extensions that Memsource have in their flavour of XLIFF.  However, the filetype doesn’t support any customisation which is a drawback because when it doesn’t cater for some tags out of the box you will have the problem you have shown, and frankly I don't know why we don't support br tags so I think this is something we should fix.  I'm sure this has been raised before.

     The solution is actually quite simple and that is to use the XLIFF filetype instead.  So just add *.mxliff to the XLIFF filetype here:

    Screenshot of RWS AppStore Applications settings showing XLIFF file type options with *.xliff, *.xlf, *.mxliff extensions added.

    Then out of the box the br tags will be picked up.  So for example, using your file in the segment you referred me to I would see this:

    Partial view of a text editor displaying code with 'br' tags not being recognized, indicated by a purple box around 'br'.

    In addition to seeing this you now also have the possibility to use the embedded content processor to tag up anything else you'd like.  So fairly straightforward to use to solve this problem. 

    2021 also has the memsource filetype available but based on what you have said about everything being fine there I think you may not be using it and could have disabled it... but I'm guessing again!

    The problem you are experiencing, based on this file, is not a DeepL problem, it's entirely down to the files not being prepared to recognise these tags in the first place... not your fault as you would expect the memsource filetype to handle this, but it's important to note the files that are being used.

    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

    emoji


    Generated Image Alt-Text
    [edited by: RWS Community AI at 7:58 AM (GMT 1) on 4 Jun 2024]
  • Thank you, Paul.

    I think I need to further clarify my issue - I'm not looking for a way to show the formatting code as tags in Trados. My problem is that DeepL is removing the formatting code entirely from the target - only in Trados 2022.

    If the source is 

    I accept the&nbsp;<a target="_blank" href="{{url}}">terms & conditions</a>.

    DeepL reads this as plain text, omitting &nbsp;<a target="_blank" href="{{url}}"> and </a>

    Same goes for the br and a multitude of other formatting code. By the way, I have not set the DeepL plugin to use plain text in either 2021 or 2022.

    To reiterate, I'm happy with how Trados shows the code in the source, the problem is that DeepL ignores it in the target.

    I think my best bet for the moment is to install Trados 2021 and hope that 2024 will not have this issue. 

    emoji
Reply
  • Thank you, Paul.

    I think I need to further clarify my issue - I'm not looking for a way to show the formatting code as tags in Trados. My problem is that DeepL is removing the formatting code entirely from the target - only in Trados 2022.

    If the source is 

    I accept the&nbsp;<a target="_blank" href="{{url}}">terms & conditions</a>.

    DeepL reads this as plain text, omitting &nbsp;<a target="_blank" href="{{url}}"> and </a>

    Same goes for the br and a multitude of other formatting code. By the way, I have not set the DeepL plugin to use plain text in either 2021 or 2022.

    To reiterate, I'm happy with how Trados shows the code in the source, the problem is that DeepL ignores it in the target.

    I think my best bet for the moment is to install Trados 2021 and hope that 2024 will not have this issue. 

    emoji
Children
  •   

    But that can only be because it is not tagged up.  You are providing DeepL with the chars as if they are plain text.  The only way DeepL knows they are tagged is if you make sure the code is tagged before sending it.

    If you are telling me that you are sending the code to DeepL as tagged up code and it strips them out then I do wish you would isolate the actual part of the file you have that contains this and provide it so I can check it.  I had a go to come up with this:

    <?xml version="1.0" encoding="UTF-8"?><xliff xmlns="urn:oasis:names:tc:xliff:document:1.2" xmlns:m="http://www.memsource.com/mxlf/2.0" version="1.2" m:level="1" m:version="2.10">
    <file datatype="x-undefined" original="some file" source-language="en" target-language="de" m:begin-group-id="0" m:end-group-id="843" m:file-format="XLS" m:job-uid="Ht4QCWxqn5UD1Gwp6iJZC7" m:project-uid="FbYNF1Z8O2S7bi119zgoKo" m:task-id="Kfxyokl06NPB09ZB1_dc2" m:transmem-ignore-tag-metadata="yes">
    <header>
    </header>
    <body>
    
    <group id="0" m:para-id="2-tu1">
    <context-group>
    <context context-type="x-file-part">xl/sharedStrings.xml</context>
    </context-group>
    <trans-unit id="Kfxyokl06NPB09ZB1_dc2:0" m:confirmed="0" m:created-at="0" m:created-by="" m:gross-score="0.0" m:level-edited="false" m:locked="false" m:modified-at="0" m:modified-by="" m:para-id="2-tu1" m:score="0.0" m:trans-origin="null" xml:space="preserve">
    <source><![CDATA[I accept the <a target="_blank" href="{{url}}">terms & conditions</a>.]]></source>
    <target><![CDATA[Ich akzeptiere die <a target="_blank" href="{{url}}">Allgemeinen Geschäftsbedingungen</a>.]]></target>
    <alt-trans origin="machine-trans"><target /></alt-trans>
    <alt-trans origin="memsource-tm"><target /></alt-trans>
    </trans-unit>
    </group>
    <group id="1" m:para-id="2-tu2">
    <context-group>
    <context context-type="x-file-part">xl/sharedStrings.xml</context>
    </context-group>
    <trans-unit id="Kfxyokl06NPB09ZB1_dc2:1" m:confirmed="1" m:created-at="0" m:created-by="" m:gross-score="0.0" m:level-edited="false" m:locked="false" m:modified-at="0" m:modified-by="" m:para-id="2-tu2" m:score="0.0" m:trans-origin="interactive" xml:space="preserve">
    <source>You have had {0} attempts to login.</source>
    <target>Sie haben {0} Versuche gehabt, sich anzumelden.</target>
    <alt-trans origin="machine-trans"><target /></alt-trans>
    <alt-trans origin="memsource-tm"><target /></alt-trans>
    </trans-unit>
    </group>
    </body>
    </file>
    <m:extra>
    <m:users>
    </m:users>
    </m:extra>
    </xliff>

    Uses the MXLIFF you sent me with something that is appropriate for the XLIFF to still be valid enough to work.  Perhaps you can take this and correct the content so it reflects what you have?

    I tested this file like this:

    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

    emoji
  • Apologies, but I don't know how to do what you're suggesting, but maybe the following two screenshots will help to clarify the issue I'm facing:

    Trados 2021

    First screenshot showing text with HTML-like tags visible, indicating an issue with code not being processed correctly.

    Trados 2022

    Second screenshot with similar content to the first, showing text with HTML-like tags, suggesting a persistent issue with code handling.

    As you can see on the screenshots, there is something in Trados 2022 and/or the DeepL plugin, at least on my end, that strips the code out - which is not the case in Trados 2021.

    emoji


    Generated Image Alt-Text
    [edited by: RWS Community AI at 3:17 PM (GMT 1) on 4 Jun 2024]
  •  

    ok... this is all you have to do:

    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

    emoji
  • Thanks for the video, Paul, but it's rather confusing me further because I don't know how you even get to the view of the text that you want me to copy and open in Notepad. 

    And while I'll be happy to send you another file if that helps, I would like to keep things simple for the moment - why do you think this issue is related to the files to begin with? I'm loading identical files in 2022 and 2021, and the DeepL plugin only strips the code in 2022 (please see previous screenshots). This behavior occurs in .mxliff (from Phrase), and XLIFF (from CrowdIn), it occurs with the Embedded Content Processor and without it.

    I noticed that the DeepL plugin for Trados 2021 is different than the one from Trados 2022 (unfortunately, there doesn't seem to be an option to use the older plugin in 2022) - don't you think the issue could be as simple as an error / glitch with the new DeepL plugin for 2022?

    I'm just going by logic here, but again, I'm using the exact same files, adding them with the same method and settings - but Trados 2022 strips out important code pieces. 

    emoji
  •  

    why do you think this issue is related to the files to begin with?

    Because I cannot reproduce this problem at all.  I do not believe there is anything wrong with the DeepL plugin as it's returning the correct behaviour for me no matter what I try.  The only thing I can think of here is that the source files you have are vastly different to the ones I am trying to recreate to mirror your problem.

    Until you can provide me with a file that actually behaves the way you see this I can't do anything more.  Certainly the latest plugin for DeepL in Trados Studio 2022 does not behave this way for me so we have nothing to fix.

    I'm just going by logic here, but again, I'm using the exact same files, adding them with the same method and settings - but Trados 2022 strips out important code pieces. 

    I'm sure this is logical for you, but given the content of our engagement so far I'm sure you'll understand my hesitancy to take this as read without the actual files you have a problem with.  Even the one you sent me doesn't behave the way you see it.

    Maybe one more thing we can try without your files.  Remove the DeepL plugin completely and make sure you have installed the latest one.  Here's how to do that:

    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

    emoji
  • I have sent you some more files, and I had already tried reinstalling the DeepL plugin. I tried again, but the issue persists. 

    As a user of Trados, without much of the background knowledge that you have, I'm simply trying to understand / find a fix for why Trados 2022 with the DeepL plugin would suddenly introduce an issue that I never had before, an issue which I can't reproduce myself in Trados 2021 (now installed on the same computer).

    I personally don't care if this is an error in Trados or DeepL, or if this is simply a few settings in Trados 2022 that need to be adjusted - I just would appreciate it if it worked, as it has in 2021, 2019, etc. 

    If there's no way I can get it to work, I'll just keep using Trados 2021 until it does. But if you say that my issue is not reproducible on your end, I'm hopeful that there is a fix.

    Right now, I also copied one of the strings into a plain .txt document, created a new project in Trados 2022, added said .txt file and the result is the same as in all the other files. 

    Screenshot of Trados 2022 software with DeepL Translator plugin showing a translation segment error. The source text 'Obtain Star-Up Crystals, depending on your Production Center level.' is highlighted with an orange border indicating an issue. The target text 'Erhalten Sie 1-3 gewohnliche Star-Up-Kristalle, je nach Stufe Ihres Produktionszentrums.' is displayed in the translation results pane.

    emoji


    Generated Image Alt-Text
    [edited by: RWS Community AI at 5:36 PM (GMT 1) on 4 Jun 2024]
  •  

    Hello. I do have the same problem. Trados just strips the tags out. Some it doesn't. I tried everything what was suggested here. But didn't help. Using the newest DeepL plugin. Formatted the Excel as "text" didn't help either.

    emoji