Parser Rules XML Filetype doesn´t work


at first, I want to apologize for my bad English. Here is my question:

I have created a new file type at Trados: XML: Localization

For this file type, I have defined parser rules that define what to translate and what not to translate.

Parser rules are:

//content[@language="en"] translate

//content[@language="it"] translate

//content[@language="fr"] translate

Context is paragraph and rule type is XPath.


In Verarbeitung eingebetteter Inhalte I have defined an XML parser. The new rule in inline tags is:


Tag Type: Platzhalter

To translate: Falsch


This has worked perfectly so far.

See the screenshots.


So now my problem, I updated Trados to

And now it doesn't work anymore. Please have a look at the screenshots, the elements are translated now, which is wrong.

I guess Trados now uses the file type Any XML instead of XML: Localization. But in Any XML I can't define parser rules.

But, when I create a new project, I see that XML: Localization is selected.


What I've tried is to create a whole new file type with these settings or disable all other XML types.


Do any of you know any advice?


Best regards


Top Replies

  • I'm trying to make sense of your post which is a little confusing for me.  In here you seem to have created rules to extract the content of the content element as translatable text:

    Parser rules are:

    //content[@language="en"] translate

    //content[@language="it"] translate

    //content[@language="fr"] translate

    Then you said this:

    Please have a look at the screenshots, the elements are translated now, which is wrong.

    Your source file will only extract the fr as you don't have en or it in the example you show and the screenshot here seems to reflect this:

    But looking at this one which has the inline strings tagged, I'm thinking that this is your problem... the one above is not reflecting the inline tags:

    So it looks as though your inline rules are not being catered for.  Is this the problem?  Can you share a screenshot of your filetype settings?

  • Hi Paul,

    thank you for your answer. Here are the screenshots of the project settings.

  • And excuse me, I wrote something confusing, I think.
    I used //content[@language="fr"] to define that the terms in the XML file should be translated.

    Just like here:
    <content language="de">inbox: $VORGANGSPOSTKORB_NAME+$</content>
    <content language="fr">Boîte de réception $VORGSPOSTKORB_NAME+$</content>

    But I want to make sure everything is not translated into $$.

    Thank you.
    Best regards

  • I'm sorry... but now I'm more confused than I was before!

    I used //content[@language="fr"] to define that the terms in the XML file should be translated.

    ok... so you want to translate the content elements where the attribute value is fr.  Understood... and this would mean that you replace the contents of the fr text, presumably with French?

    You have created these rules:

    In here you are saying this:

    - extract the text in the content elements for en, fr and it and expose it for translation.  Then your source file, which only contains two languages (de and fr), can be easily handled as only the fr should be extracted:

    So far so good.  But you then asked for everything else to be extracted as well since its not protected at all:

    I'm assuming these are the parts you don't want?  So why don't you delete all your rules and just use these two rules for the sample file you provided for example:

    //content[@language='fr']             Always translate

    //*                                                 Never translate

    In that order.  And add the structure for the embedded content to the top rule.

  • This is not the first time I see such completely wrong XML parsing rules, apparently created by following some weird videotutorial instructing the users to create rules by importing the source XML file:

    This is the worst way of creating the parser rules EVER!
    Especially for n00bs which have no clue what they are doing...

  • I think importing the rules had some value as they were then easier to select (if you didn't need xpath).  I always import first too... but I then delete them all so only do the import for the selection convenience when I don't need more complex xpath.

  • And that is exactly the problem - you know what to do and why, but the average Joe Translators don't... and they end up with something completely weird what may work only by coincidence, or due to some bug or something, what gets eventually fixed/changed and everything breaks down.

    Plus, nowadays the XMLs are rather complex, so this way does way more harm than good. Again, especially for n00bs.

  • Hello again,


    The other parser rules //entry, //localization, //localization1 etc. refer to deeper elements of a much bigger and complex XML file. I have used the small XML file only for testing purposes and to demonstrate the following to you.

    So we have several such complex XML files. One for each language. Source language is always German in <content language="fr"> for example. For Italian it would be <content language="it"> etc., depending on the file and the language we want to translate into.

    Now I would like to say Trados, translate everything that is written in <content language="fr"> etc., but don't translate what is written in <content language="de">, because that should remain German.

    The elements in the $$ are buttons of our application. They must not be translated.

    We have tried to follow what you Paul described in your article

    Exactly with the settings I have shown to you everything worked perfectly. See the screenshot. All elements or FormatFunctions in the $ characters were not translated.

    Here is the example:

    <content language="de">Eingangskorb: $VORGANGSPOSTKORB_NAME+$</content>

    <content language="fr">Boîte de réception $VORGANGSPOSTKORB_NAME+$</content>


    As you can see, only the actual text was translated.

    After the update to it is no longer possible to use exactly the same project template. Also other changes don't apply to our file format “XML:Localization” anymore. For example, if I want to convert HTML entities. We found out that we now have to make these settings for the file type “Any XML”. So we assume that the new file type “XML:Localization” doesn't work anymore.


    Here's the example where it doesn't work anymore:

    <content language="de">inbox: $VORGANGSPOSTKORB_NAME+$</content>

    <content language="fr">Boite de réception : NOM_DE_PANIER_DE_POSTE_DE_TRANSACTION_DE_COURRIER_+$</content>


    I hope you've been able to follow me more clearly now and see what the problem is.


    Thank you very much.

    Best regards


  • I remember  reported a problem with XML parsers in the Beta group - that was just before the release of SR2. Could that be connected?


Reply Children
No Data