Detecting language please wait for.......
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:
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 184.108.40.2061.
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?
Hi Lydia, if you are unsure about which file type is picking up your XML files in the new Studio version, you will need to find out about this, first, as follows:
If Any XML is picking up your files,…
Hi Lydia Schleinitz
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…
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:
Lydia Schleinitz said:Parser rules are:
Then you said this:
Lydia Schleinitz said: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?
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 regardsLydia
I'm sorry... but now I'm more confused than I was before!
Lydia Schleinitz said: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.
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 https://multifarious.filkin.com/2014/06/01/custom-xml/.
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 220.127.116.111 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.
I remember Frank Lempp 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 firstname.lastname@example.org
Lydia Schleinitz said: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.