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?


  • Can we see your setting files and also have a sample of te source?  That might help stop all the guessing?  If you don't want to post them into th forum feel free to drop me an email to

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

    So, as Paul already mentioned, you should just specify rules for "DO translate this" and then use "//*" set to "DO NOT translate this" as last rule in the list.
    You do not need to specify rule for every element/attribute present in the XML.

  • Okay, thanks, Paul. I sent you everything.

  • Hi

    I have replied to your email yesterday, but it seems to be getting bounced.  So this was my response... I made two changes and things seem to be picked up correctly::

    I have not addressed all your other rules… I’m assuming you have them there for a reason?



  • Hi Paul,

    thank you for your reply. I've just tested your project settings, but unfortunately it doesn't work either.

  • Please can you be very specific about what doesn't work because this seems to be working for me.

Reply Children
  • Yes, of course. So I set up the project settings the way you described it.

    The result is that the values in $ characters are still translated. However, they must not be translated because they are code.

    <content language="de">$VORGANGSPOSTKORB_NAME+$</content>
    <content language="fr">NOM_DE_PANIER_DE_POSTE_DE_TRANSACTION_DE_COURRIER_+$</content>

    And now the German source text is also translated, which of course should not be the way it is.

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

  • And now the German source text is also translated

    Surely it is, since that's what your parser rules say!
    At the very top you clearly define the "de" language to be "Immer zu uebersetzen"...

    Are you really sure you actually understand how the parser rules work and how you should define them?!?!

  • Hi Evzen,

    with all due respect, but I really don't have to put up with your rude manners. Do you really think you can make yourself more heard if you use the punctuation marks excessively?

    I didn't make the rules, I just followed what Paul told me in his last post. And I have confidence in that. Of course I know that the German parts are now going to be translated. For this reason we have set them to "Do not translate" in the original rules. I just want to leave nothing untried.

  • All I'm trying to do is to make you focus on the core problem. You seem to be going in circles all the time, and that for the only reason - that you actually don't understand how to rules work.

    If that's true, it's absolutely unclear to me why you hesitate to admit that. You would get proper help much faster then.

    Paul never said he tailored the COMPLETE rules for your needs. If for nothing else, then at least simply because you are the only one to actually know all your needs; we don't.
    So Paul clearly stated the fundamental changes he made. The rest is on you. Including proper definition of the embedded content rules, so that the $-content does not get translated.

    What exactly are you expecting from the community? To do everything for you? Without knowing what exactly you actually need? How exactly do you expect the community to do it?

  • Thanks

    I am a bit confused with what you want here.  Perhaps you could simplify things and just explain like this:

    Element name

    Translatable or not

    That's all I need to know and then I can suggest something that may be more helpful for you.  I understand which char strings you need hidden so that's clear, but I'm not clear at all on what content should be exracted from the elements in your file.

  • Hi Paul,

    OK I try to simplify my question:

    By the parser rule //content[@language="fr"] translate everything in <content language="fr"> will be translated.

    <content language="fr">Die Datei wurde geändert.</content> will be translated to: <content language="fr">Le fichier a été modifié.</content>

    This works perfectly.

    But I also have resources like this: 

    <content language="fr">Die Datei $FILENAME+$ wurde geändert.</content>

    which will be translated to: <content language="fr">Le fichier $FICHIER+$ a été modifié.</content>

    I do not want $FILENAME+$ to be translated to $FICHIER+$

    I prefer the following result: <content language="fr">Le fichier $FILENAME+$ a été modifié.</content>

    How can I do that?

    Thank you very much.

  • ok - the test file you sent me only contained DE and EN, no FR, so I adapted it like this:

    <?xml version="1.0" encoding="iso-8859-1"?>
    <localization cid="7025" project="SP_EPA" version="1.00" source="de" destination="en">
    <localization1 project="SP_EPA" version="1.00" view="Aktenaufgaben" kid="3" table="FFTN_DATAPOINT" column="SHOWNORSLTMSG">
    <entry desc="NoResultMessage of a datapoint [kid=3] of view[Aktenaufgaben]. (Will be used if this kind of node has no hits and if there is a need to show this fact in tree)">
    <content language="fr">Es wurden noch keine $SOMEOTHERNAME+$ hinterlegt oder es fehlen Ihnen die entsprechenden Berechtigungen.</content>
    <content language="en">You have not yet defined any $SOMEOTHERNAME+$ or you do not have the relevant authorizations.</content>
    <localization1 project="SP_EPA" version="1.00" view="Anker" kid="1" table="FFTN_DATAPOINT" column="SHOWNORSLTMSG">
    <entry desc="NoResultMessage of a datapoint [kid=1] of view[Anker]. (Will be used if this kind of node has no hits and if there is a need to show this fact in tree)">
    <content language="fr">Die Datei wurde ge�ndert.</content>
    <content language="en">The file has been modified.</content>
    <localization1 project="SP_EPA" version="1.00" view="Anker" kid="4" table="FFTN_DATAPOINT" column="SHOWNORSLTMSG">
    <entry desc="NoResultMessage of a datapoint [kid=4] of view[Anker]. (Will be used if this kind of node has no hits and if there is a need to show this fact in tree)">
    <content language="fr">Die Datei $FILENAME+$ wurde ge�ndert.</content>
    <content language="en">The $FILENAME+$ has been modified</content>

    I then created a filetype for the main content like this:

    The embedded content reference like this:

    I called it "legacy" because it wasn't the new XML filetypes... but I did use this one:

    Then I created the embedded content processor like this:

    The result:

    Which seems to be what you're after.

  • Thank you Paul,

    yes, as I have already mentioned before we have several XML files. One for each language. 

    In the example I sent you, it was English, exactly.

    Your example looks quite good, but of course the German text has to be translated. 

    Die Datei $FILENAME+$ wurde geändert.

    The file $FILENAME+$ has been modified.

    Just like our original XML file I sent you. There it is, as I said, correctly. The translation memory is also used here. Our problems relate only to machine translation. Our problem is that we didn't come back to these settings after the Trados update. :( 

    I actually think I did exactly the same settings you did. Look at that.

    Embedded content rule:

    Embedded content processor

    And this is waht I get:

    And unfortunately, as I said, this is wrong.

    Could it be due to some other setting?

  • You may have noticed that on Paul's screenshot some of the parser rules were grey - they are deactivated. Try deactivating the first, second and fourth parser rule. As pointed out above, it's also a good idea to create a last rule "//*" -> "do not translate".


  • Hi Daniel,

    OK I really missed the element //*.
    I've now run the translation again with these settings:

    and that's the result:

    And I've now run the translation with these settings:

    and that's the result:

    What did I miss?

  • It must be inserted at the very last position, as I already mentioned long time ago.

  • Hi Evzen,

    OK, I´ve run again with these settings:

    This is the result:

  • Then you have something wrong on your side ;-)
    Since none of us knows what you do on your side, it's you who has to investigate and use your knowledge to understand what's going on.
    All the needed information were mentioned here several times. The rest is on you, I'm afraid.

  • Perhaps it’s related to your templates? Maybe you’re not using what you think you are?

  • OK, I'll try to find the error in the template somehow.
    Thanks to all of you anyway!