Idea Delivered

Updating this to delivered (as an app) - see https://appstore.rws.com/Plugin/13. Thanks Daniel Hug for the note!

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

  • 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.

  • I don't think any of the proposed methods addresses the problem:

    - method 1: Is it possible to convert an existing XML file to XLIFF and re-convert it after translation? Or can the XLIFF filetype be used for any bilingual XML? If yes, how?

    - method 2: the method Christine Eulriet uses, is  basically, what we have to do now in default of other options. It's, what is described here: multifarious.filkin.com/.../. As I already stated, it is not only a workaround, it does not even solve the problem. Some target language elements in the XML file already contain translations. These will be deleted, when copying the source text into the target language elements.

    - method 3: "We" are not an agency. We (which is 'me and my collegues') are a documentation department. We don't have the means to develop anything by ourselves.

  • We (an inhouse translation team without access to IT/developping resources) were facing the same issue. We solved the problem in a non-sophisticated and not fully automated - but working - manner, using a) a macro and b) an adaptation of the xml file type.

    When a new file needs to be translated, the first preparation step consists in having the content of the <de></de> elements copied in the <en></en> elements. For this purpose, we defined a macro in Notepad++ which needs to be run on each file. Basically, it identifies the <de></de> elements and copies the content within the tags before pasting it between the <en></en>-tags.

    For Studio, we use a specifically created file type which classifies the <de></de> elements as non translatable. After completion of the translation, you can generate your target file as usual and use it in your CMS wihtout any further handling.

  • You said "we" which makes me think you are an agency perhaps?  I think the effort is trivial for a developer to create a filetype for this using the API, particularly because there is an example already there, so it would only need a small amount of work to ensure it covers what you need.  This was done by two other agencies I'm aware of, but neither have shared their plugin for others.  Perhaps you could tackle it yourselves?