A new online community dedicated to improving the quality of medical and life sciences translations
Login | Not signed up? Register here.
Discussion Board » Desktop Publishing » Handling UI terms in your localized software documentation
8 Posts in 5 Topics by 4 members
| Page: 1 | Go to End | |
| Author | Topic: Handling UI terms in your localized software documentation | 1340 Views |

10 December 2009 at 12:59pm Last edited: 10 December 2009 3:15pm
You take great care to ensure your medical software documentation contains step-by-step instructions on how to use the software, with screenshots. The clarity and readability of these instructions are essential to the end user and the lack thereof could lead to critical and possibly life threatening errors.
It is important that the user interface (UI) terms in the documentation of the software are consistent with the software itself. For example, the documentation may have instructions to:
"Press the Setup button".
The French documentation will say,
"Appuyer sur le bouton Configurer".
However, when the French end user looks on the screen, there is no button that says "Configurer" because the software is in English. The most common way to deal with this is to provide the English UI term with the translation in parentheses immediately following.
"Appuyer sur le bouton Setup (Configurer)."
The French end user now knows what button to look for as well as what it means.
Down the road you may decide to localize the software. In this case, you would need to remove the English UI terms from the documentation and add localized screenshots of the software. For screenshots, you can replace all of the graphics in the graphics folder with the new ones and then go into the document to resize them as necessary. If you took care to make the screenshot dimensions identical to the English, no adjustments would be necessary.
With the UI terms, it will take a desktop publisher time to go through the localized documentation, manually remove all of the English UI terms, and handle the reflow of the document text. However, if you are authoring in Adobe FrameMaker, here's an ideal way to create your English document with localization in mind:
Create and apply one condition to the English UI term, create a copy of the English immediately after and apply a second condition, and then use a third condition for the parentheses around the second instance and the space between. Note, this is one of the few times it is recommended to use multiple conditions in the same sentence.
In this example, the three colors represent the three conditions, the underscore represents a space:
Press the Setup_(Setup) button.
During translation, only the second instance will be translated. This will enable you to use the show/hide conditional text feature to switch between English only (blue), translation only (red), or both (red+blue+green) in the localized document. This provides flexibility and will save time and cost when you are unsure if the software will be localized.

14 July 2010 at 1:05am Last edited: 14 July 2010 1:07am
In my experience, another good approach to handling the UI terms is a descriptive translation.
Example:
English: Check for proper ECG signal again on the Gating Control Window.
Russian: В окне управления синхронизацией повторно проверьте наличие надлежащего сигнала ЭКГ.
A descriptive translation is very appropriate in the two scenarios below:
1. The UI is not highlighted specifically in the sentence, e.g. by using a bold font or quotation marks.
2. The actual UI was already mentioned above and localized using a translation in brackets.
Benefits
The main benefit of a descriptive translation is that it doesn't directly refer the reader to a specifically named UI term on the screen. This almost eliminates the risk of potential confusion mentioned by Ben in the initial post—the end user looking for a non-existent name on the screen. Instead of looking for a specific UI term, the user would identify the necessary UI by using deductive thinking.
Another benefit is shortening and simplifying the translation. Instead of providing the source UI term + translation in brackets each time in your translation, you can provide the translation in brackets just for the first occurrence of the UI term and use the descriptive translation thereafter. As the text becomes shorter and therefore easier to understand, the end user will be happier with the documentation. The DTP team will be happier as well, because the length of the translation will be closer to the length of the source, resulting in less adjustments at the typesetting step.
The descriptive translation also helps keep the translation current, even if minor changes are introduced to the source UI afterwards. For example, a developer may decide to change “Gating Control” to “Gating Monitoring” in the next version of the software. If the old documentation translation included specific references to “Gating Control,” all of these will need adjustment. However, if a descriptive translation was used, little or no changes will be required, because such translation will normally remain valid for the changed UI term as well—the change is minor and doesn't affect the translation.
A descriptive translation isn't always appropriate though, so caution should be exercised when you consider using it in your current translation.
| 1340 Views | ||
| Page: 1 | Go to Top |
Currently Online: There is nobody online.
Welcome to our latest member: Xupzuvsv
© 2010 ENLASO Corporation. All rights reserved. Rhonix is a trademark of ENLASO Corporation. ENLASO is a trademark of ENLASO Corporation.