Idea Delivered Partially

There are several methods:

- Use XLIFF - this is a standardised bilingual XML format and can handle partial translations out of the box

- Use macros/tools as discussed here in comments

- Develop a bilingual file type using a) developer community or b) inhouse development

Setting to "Delivered partially".

Provide filetype for bilingual (or even multilingual) XML

  We often have XML files that are bilingual e.g. like this (its a Safexpert XML file for translation, by the way):

<Item>
    <de>German text</de>
    <en>English text</en>
</Item>

Or it could also be like this:
<item language="de">German text</item>
<item language="en">English text</item>

Yes, we know this link and the method described there: https://multifarious.filkin.com/2015/11/22/a-little-learning/. We also know, that it is possible to save the XML file as a bilingual Excel file.

The problem is that

  1. Some of the English/target language elements already contain translations that need to be preserved.
  2. We need to re-import the XML file after translation.

So, none of the above workarounds works.

We need it like that way, that the text from the <de></de> element is taken as source language and the translation is written into the <en></en> element.

I can't imagine why Trados is not able to handle these bilingual XML files. You are able to do it with Excel, so why is it not also possible with XML?

Please provide a filetype for translating bilingual XML.

Tamara Roth
Parents

  • For method one, you don't work with a custom XML format in the first place, but with XLIFF. Many CMSes standardise on this. This then means you don't have to do any customisation, as the XLIFF would already contain the source/target segments. But it does require a solution upstream - i.e. with your particular XML files, it is already 'too late' and needs to be changed upstream to save the info in XLIFF format as a first step, instead of using the XML route.

Comment

  • For method one, you don't work with a custom XML format in the first place, but with XLIFF. Many CMSes standardise on this. This then means you don't have to do any customisation, as the XLIFF would already contain the source/target segments. But it does require a solution upstream - i.e. with your particular XML files, it is already 'too late' and needs to be changed upstream to save the info in XLIFF format as a first step, instead of using the XML route.

Children
No Data