TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
When localizing products at our company, I need to both translate the SW strings inside the product (in this case an infrared camera with an internal camera software) and translate the manual. Since the manual refers to things you can do in the software, a subset of the SW strings are always used in body texts, captions, tables etc when referring to the software and to screenshots. Obviously one needs 100 % identity between how the strings are translated in the camera SW and how they are translated in the manual.
The former approach was that we first translated the SW strings in Excel sheets, then - when I used strings in the documentation - I marked up these with "bold" or something like that. When the translation company was to translate a manual, they told the translators to check the Excel sheets every time they found something marked up with "bold".
However, seeing that we translate camera SW and manuals to 17 languages, and there are about 15,000-20,000 localized SW strings and 250+ manuals, even just a few translators forgetting to check the Excel sheets now and then results in several manuals where some of the strings in body texts, captions, tables etc does not match the strings in the screenshots - which is, ofcourse, not acceptable.
Enter the promising "dynamic variable idea".
In the source XML data for manuals, we changed all strings in the manuals to dynamic variables. At the point of formatting, these variables retrieve correct translations from a string library (converted to XML from the Excel sheets). Before going to the translation company and TRADOS, these variables get "notranslate" tags and are converted to "internal strings" in TRADOS. The syntax is, eg., "N0001.Browse_for_folder" where "N0001" is a dummy namespace so that different translations of "Browse for folder" on different platforms can co-exist in the string library.
Anyway, now it turns out (says the translation company) that when TRADOS finds something that is protected by internal tags, it only displays the text that can be translated, and not the whole segment. The result is that eg. a German translator (where nouns are usually in different places than in English) can not move the noun after the protected string to before the protected string, without disabling the "Document och Tag Protection" in TRADOS. Which is not a good thing, and counter-acts the whole idea about protecting the strings in the first place.
So, in TRADOS a text like "Open the <notranslate>N0001.Browse_for_folder</notranslate> dialog box" can not be changed to "Bitte Ãffnen sie das Dialogfeld <notranslate>N0001.Browse_for_folder</notranslate>" (pardon my German!). And the same problem is obvious in other languages too.
I would be interested to hear any and all ideas about this - both about the general string issue and how other companies deals with QA of SW strings in manuals=screenshots, and also about the TRADOS conundrum.
