You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
A German contract document (PDF) contains the words AUFTRAGGEBER (Client) and AUFTRAGNEHMER (provider). These 2 German words are both translated to CONTRACTOR or both to CUSTOMER, effectively corrupting the resulting document.
Adding the correct translation to a glossary does not change the behaviour.
Testing a empty Word document with only these 2 words and a glossary does translate correctly.
To Reproduce
Steps to reproduce the behavior:
Have a PDF document with these 2 words in amongst many other text
Post it to the API with or without a glossary
The result is as described above
Expected behavior
Both words should not be translated the same AND the glossary should enforce the right translation.
Screenshots or sample code
Original
Translated
** Additional context **
Selecting the one sentence and translating with the desktop app gives the exact same bad result.
The text was updated successfully, but these errors were encountered:
Thanks for the report! In case you can change the document, avoiding the upper casing fixes this for me:
"Jegliche Verlagerung von Betriebsaktivitäten des Auftragnehmers im Bezug auf Services erfolgt anhand eines vom Auftragnehmer erstellten und Auftraggeber genehmigten, formellen Migrationsplans für die ordnungsgemäße TRANSITION und SERVICE-MIGRATION sowie ununterbrochenen Service."
gets translated to
"Any relocation of the Contractor's operations with respect to Services shall be based on a formal migration plan for proper TRANSITION and SERVICE MIGRATION and uninterrupted service prepared by the Contractor and approved by the Client."
We'll check why glossaries don't work for this and if we can fix the translation problem itself.
i confirm JanEbbing's observation that without capitals, the translation works. It's really weird that capitals make such a difference.
The glossaries not working is interesting and I believe issue DeepLcom/deepl-dotnet#16 is related (it's the same me but I lost access to the other email when I switched providers ...).
I can also confirm that when I pass the text to the DeepL API, the correct GlossaryId is included in the TextTranslateOptions object.
Describe the bug
A German contract document (PDF) contains the words AUFTRAGGEBER (Client) and AUFTRAGNEHMER (provider). These 2 German words are both translated to CONTRACTOR or both to CUSTOMER, effectively corrupting the resulting document.
Adding the correct translation to a glossary does not change the behaviour.
Testing a empty Word document with only these 2 words and a glossary does translate correctly.
To Reproduce
Steps to reproduce the behavior:
Have a PDF document with these 2 words in amongst many other text
Post it to the API with or without a glossary
The result is as described above
Expected behavior
Both words should not be translated the same AND the glossary should enforce the right translation.
Screenshots or sample code
Original
Translated
** Additional context **
Selecting the one sentence and translating with the desktop app gives the exact same bad result.
The text was updated successfully, but these errors were encountered: