Hi Bodo Tiegel , thank you for reporting this and including the file to help us reproduce the issue.  I'll followup with the team and circle back once I know more.

Hello  Bodo Tiegel,  

Thank you for reaching out.

We've been able to reproduce the issue when using the default settings of the DeepL plugin. However, setting the tag handling to XML seems to resolve the problem, allowing the document to be translated correctly while also preserving formatting—unlike the HTML setting, which, as mentioned, converts some symbols into HTML/XML entities.

Please try updating the tag handling setting to XML and let us know if this works for you. Here’s a screenshot illustrating the setting change:

Let us know how it goes, and feel free to reach out if you need any further assistance!

Best regards,

Alexandru Florescu

Hi Alexandru Florescu ,

I've just tested the same file using XML tagging, however & is still converted into the & entitiy:

Best regards,

Bodo

Hello Bodo Tiegel,

Thank you for reaching back.

We have double-checked this issue and can confirm that it is indeed a bug.
When attempting to translate segments without a specified format, DeepL returns a response where certain elements are not enclosed in brackets, as shown in the following image:

Additionally, when sending the following text to DeepL, the translation is processed; however, some characters are returned as XML/HTML entities, as illustrated in this image:

Given these findings, we will be following up with DeepL to address this bug. In the meantime, the solution provided in our previous response remains a viable workaround to mitigate the current behavior.

Thank you for your patience and understanding. Please let us know if you have any further questions.

Best regards,
Alexandru Florescu

Hello Bodo Tiegel, 

Thank you for your patience.

We have received a response from DeepL regarding this issue. They have acknowledged that their current tag-handling system has limitations that can result in invalid XML/HTML output, duplication, or loss of tags. Additionally, when the tag-format parameter is set to HTML/XML, certain characters are intentionally converted into XML/HTML entities to ensure proper parsing and formatting.

DeepL has confirmed that they are working on improving their tag-handling system to address these issues and ensure that translated output maintains the original structure and formatting correctly.

In the meantime, the workaround we previously mentioned remains the best approach to mitigate these effects. If you encounter any additional issues or need further clarification, please let us know.

Best regards,

Alexandru Florescu

Hi Alexandru Florescu ,

I add an additional issue here... In an Abbyy Finereader-converted DOCX DeepL produces duplicated texts. In the DOCX, there are line breaks after each line and I understand that the problem is caused by these and may be related to DeepL's tag problems.

Please find sample data here:

Line breaks - text duplicated.zip

Best regards,

Bodo

Hello Bodo Tiegel, 

Thank you for reaching out again and for providing the sample data.

I have investigated the issue and was able to replicate it. Based on my findings, it appears that for some segments, the translation returned by DeepL contains duplications, as shown in the following example:

Additionally, some other segments may contain incorrect translations:

To further analyze the issue, I also tested translations into Italian, and the duplication persists in this language as well.

Given these findings, I will follow up with DeepL regarding these newly discovered issues. I appreciate your patience and will keep you updated on any developments.

Best regards,
Alexandru Florescu