Localizing strings: creating “Do Not Translate” list

Localizing software is finicky business: translations have to be close in length, match the context of the UI and the use case, be unambiguous, sound native – and sometimes you don’t want the strings to be translated at all.

Typically the “do not translate” list includes brand or product names that the customer wants to keep in the source language, as well as any other terminology that may have been adopted as from the source language (let’s say English) in the target language (let’s say, German). For example, consider Oracle line of products from A to Z  – the list is immense. How would a language provider know what to translate in the list of resource strings or marketing materials they are sent, and what to keep as is?

There are two approaches here: one – customer reviews the translations after each iteration, sends back the list of items they would like to keep as is, and the language vendor then updates the translation memory (TM) post-translation. This is doable, but tedious: now there’s an extra cycle of editing the TM, and, potentially distributing it to all individual translators if the language vendor isn’t leveraging a centralized repository server.

Additionally, this creates an extra burden on both parties: translators are likely to inquire with the vendor, which terms should be kept as is, and the language vendor, who really can’t make absolute decisions – has to channel these questions back to the customer, and then relay the answer to translators. Each individual translator in a specific language pair now has to be kept updated of the global decisions made by the customer, and the language vendor has to check the final translations tha this indeed has been implemented.

The second approach is pre-emptive: the customer, working with its own internal marketing team decides which terms should stay as is in the source language – without any translation, thus creating a “do not translate” list. The “do not translate” strings are marked as such in the source files and sent over to the language vendor. Now when the language vendor prepares files for translation in their TM software, these segments are automatically locked out – and may be even hidden from view from translators – so they don’t have to worry about them.

This approach is much more flexible: you can include not only the marketing terms, but also strings that are coming in future releases or functionality that is not going to be localized at all. This way the customer does not have to create multiple versions of resource strings and merge them back later: it is extremely easy for engineering or doc teams to mark the terms as “do not translate” on their end and submit the next revision to the language vendor for translation.

Of course, when using Translation Memory, as we wrote in the another blog post, with each iteration the turnaround gets quicker, so the whole translation and localization cycle between the customer and the vendor accelerates.

Now, there’s only one issue left: how do you tag resource strings that should not be translated?

The answer is: any way you like, as long as it’s consistent. For example: customer is localizing .NET resource file, and would like to keep certain strings from being translated by inserting the keyword “[locked]” into the comment tag:

Now you can set up a rule in SDL Trados Studio to parse the comment section, and lock out the string if it contains this keyword. Here is the rule (it is using RegEx. If you are not familiar with RegEx, here is a great tutorial):

And the last step is to decide on priority of the rule compared to all the other out-of-the-box rules that came with the file parser. Considering this should be triggered before any other processing takes place, it makes sense to move this rule to the top:

And now you are set. All the terminology loaded in and marked as “[Locked]” will not be available for edit by translators.

Questions? Comments? Contact us today for your translation and localization needs!