"notranslate" in xlf files

Question

Hi, I hope I'm here at the right place for my question. I work in Trados Studio, we receive xlf files (exported from K4) from our client. The client there marks some single words as "notranslate", e.g.: XXXXX Operating Instructions The XXXXX is the text that should not be translated. How do I tell Studio to tag this text as text, which should not be translated, I suppose it should be tagged accordingly? Thanks, Johannes

Paul · Answer

Johannes Purer In that case you're in luck as you can use the Multilingual XML filetype and handle both source and target which means if you do happen to get some with target in there it'll be covered. The process of setting up this filetype is explained here: Multilingual XML FileType The settings that seem to work for me in the test I made up (since you didn't provide one) are these: Language Root: /xliff/file/body/group/trans-unit[not(.//source//g[@ctype='x-tlf-notranslate'])] Languages: source target Looks like this: My source file... since there is no guarantee these settings will work for you, was this:

K4 crafted a file with a quirk,

DON'T TRANSLATE THIS

XLIF extensions it did surely pick,

Custom tags with a nonsensical flick,

DON'T TRANSLATE THIS EITHER

A system where translations stick.

Laugh at the code, so rich and thick,

Hopefully you'll have enough information here to manage this yourself. But please read the wiki as there are other settings you may require to make this suitable for your needs. If you only add these expressions and then come back and say it doesn't work it won't be helpful! It does for me:

Paul · Answer

Johannes Purer A bit trickier because there is no markup in the target element, so to do this I first opened the XLIFF with the out of the box XLIFF filetype, copied source to target to get the markup in there (otherwise it will exclude the notranslate fromthe target completely) and used that to translate with. I then created a new settings file and used these settings: Language Root: /xliff/file/body/group/trans-unit Languages: source/g[not(.//g[@ctype="x-tlf-notranslate"])] target/g[not(.//g[@ctype="x-tlf-notranslate"])] This seems to work nicely and if I use this test file:

Embrace the day with open arms, Night falls, and so begins the charms,

Full of life, the world in view, Stars above, a silent few,

Joyous light in every beam, Darkness brings a different dream,

With every rise, hope ascends, Twilight whispers, the day ends,

Sun's warmth on faces gleam, Moon's cold touch reigns supreme.

It successfully gets me this (machine translated after opening obviously): as opposed to this: If I save the target file I get this:

Embrace the day with open arms, Night falls, and so begins the charms, Embrace the day with open arms, Die Nacht bricht an, und damit beginnt der Zauber,

Full of life, the world in view, Stars above, a silent few, Full of life, the world in view, Sterne über uns, ein paar stille,

Joyous light in every beam, Darkness brings a different dream, Joyous light in every beam, Die Dunkelheit bringt einen anderen Traum,

With every rise, hope ascends, Twilight whispers, the day ends, With every rise, hope ascends, Die Dämmerung flüstert, der Tag endet,

Sun's warmth on faces gleam, Moon's cold touch reigns supreme. Sun's warmth on faces gleam, Die kalte Hand des Mondes hat die Oberhand.

So the notranslate parts are not translated and the rest is. However... the target elements now contain an exact copy of the source in terms of the markup and this may not be suitable for your client. So I think you need to try it, and then have a discussion with your customer to see if this is what they really needed. For all I know they may only want the translatable part in the target file in which case you can use these settings on the original XLIFF (no need to copy source to target): Language Root: /xliff/file/body/group/trans-unit Languages: source/g[not(.//g[@ctype="x-tlf-notranslate"])] target And now you'll get a target file like this: Note that the target only contains the translated part in the target element and omits all the rest of the markup. I hope you can see the problem and explain this properly to your customer? Perhaps they can do this in a smarter way and separate the notranslate parts into separate translation units or something like that. Certainly this isn't a very friendly localizable format when customised in this way which seems to defeat the objective of XLIFF in the first place.

Paul · Answer

Johannes Purer The problem you have here is that with this file you actually have nested g elements: Remove the Safe-Cone Filter. This isn't a particularly smart way to use XLIFF as there is really no sensible way to control this. It would be far more sensible to ensure that each element is its own trans-unit , and to do this your client would need to restructure the by creating individual trans-unit elements for each element within the . This makes each segment clearly identifiable and independently translatable, which is especially useful in localization workflows. For example:

Switch off the device.

Remove the

Safe-Cone

Filter.

In this structure: Each element inside the original of trans-unit TU-581-8 has been moved to its own trans-unit . Each trans-unit is assigned a unique ID ( TU-581-8-1 , TU-581-8-2 , TU-581-8-3 , etc.) to maintain the order and uniqueness. The and elements are retained within each trans-unit for consistency with XLIFF standards. This approach facilitates more granular control over the translation process for each segment and ensures that the structure is clear and manageable for translators. In fact it will also benefit your client in the long run as the whole localization process will be more economical and less likely to cause problems when they get the translated files back full of mistakes.

Paul · Answer

Johannes Purer 
 Johannes Purer said: Unfortunately this does not solve the issue the way I hoped for. 
 ok - then I think your best bet with this file is to do this: 
 
 copy source to target using the out of the box XLFF filetype. 
 save the target so you have an XLIFF with the source already in the target (although your client could probably make this easier for you and just provide an XLIFF with the target already populated with a copy of the source) 
 create a custom XML filetype that only extracts the target content (that is actually source text) and translate that 
 
 I think it should be fairly trivial to create the filetype for this, especially with all the examples you now have for the XPath expressions. 
 The downside to this approach, and it would have been the same in the Multilingual XML filetype, is that you won't be able to affect the XLIFF statuses which the XLIFF filetype can manage. Other than that I think this is the way to go... monolingual custom XML filetype translating the text stored in the target elements.

Paul · Answer

Johannes Purer 
 Johannes Purer said: we receive xlf files (exported from K4) 
 Is that vjoon K4? I don't know another with that name? More interest than anything else as knowing that won't help! 
 ctype="x-tlf-notranslate" 
 This is a custom extension and not supported by probably any CAT tool out of the box that I know of. Not supported in that the custom extensions will just be ignored. 
 However, if all the translation units follow this logic, and don't have the target pre-populated then you're in luck! You could open the XLIFF and copy source to target, then save the target. Now you have an XLIFF file with content in the target element that needs to be translated. So now you can create a custom XML filetype to translate the target element only (replace the text - that now contains the source - basically) and use a custom XPath parser rule to manage the notranslate logic. 
 That's the theory :-)

Trados Studio > 2. Trados Studio

"notranslate" in xlf files

Top Replies