DeepL plugin not preserving some formatting in Trados 2022

Question

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 terms & conditions. DeepL translates this to: Ich akzeptiere die Allgemeinen Geschäftsbedingungen. When it should be: Ich akzeptiere die Allgemeinen Geschäftsbedingungen. 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).

Paul · Answer

Markus Meuter 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: Sample File

I accept the terms & conditions.

Add to a project and translate with DeepL... like this: 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 · Answer

Markus 
 ok - so the problem is that you are not preparing the file for translation and the content in the files you provided have not been prepared properly either. Assuming that the editor view looks the same as the Translation Results window you have shown here Studio is extracting this all as text and has not tagged up the code. 
 I guess this is an XLIFF file perhaps containing CDATA? If it is you can prepare it better using the embedded content processor. But unless you tell me exactly what you are dealing with I am really only guessing. Perhaps this clinic session we ran last week will be helpful for you? 
 (240529) Working with embedded content

Paul · Answer

Markus 
 Markus said: 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: 
 
 which filetype in Studio is being used to process the file? Please check 2021 and 2022. 
 is the embedded content processor being used in 2021 and not in 2022? This is not turned on by default.

Paul · Answer

Markus 
 ok - perhaps this short video is better:

Paul · Answer

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

I accept the terms & conditions I accept the terms & conditions

Welcome to our application! Welcome to our application!

Please enter your username and password to log in. Please enter your username and password to log in.

An unexpected error occurred. Please try again later. An unexpected error occurred. Please try again later.

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

I accept the terms & conditions I accept the terms & conditions

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

Paul · Answer

Markus Meuter 
 Thanks for sending me a file that reproduces the problem. The file you have sent me is not an XLIFF&hellip; 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&rsquo;t support any customisation which is a drawback because when it doesn&rsquo;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: 
 
 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: 
 
 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 · Answer

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

xl/sharedStrings.xml

terms & conditions.]]> Allgemeinen Geschäftsbedingungen.]]>

xl/sharedStrings.xml

You have had {0} attempts to login. Sie haben {0} Versuche gehabt, sich anzumelden.

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:

RWS AppStore > 2. RWS AppStore Applications

DeepL plugin not preserving some formatting in Trados 2022