According to the European Medical Device Directive (MDD) amendment of 2010, software is now included in the definition of a medical device. It doesn’t matter if the software is integrated into the actual device or a standalone product. This inclusion is an acknowledgment of the fact that software is integral to the functioning and therapy of a device. According to the MDD, software must also be validated, taking into account the principles of development life cycle, risk management and verification. Given this new attention on software by global regulators, proper medical software localization is more important than ever.
The good news is that while software translation has its own complexities and unique issues, medical software uses much of the same technology as any other kind of software, so the technical side of localizing medical software is not any more complicated. Differing, of course, are the audience and venue for its use and the gravity of mistranslation or improper localization. If the software that runs a packaging machine is translated poorly, it can result in production downtime, wasted product and lost revenue. But if a pacemaker’s programming software contains an erroneous translation, it can result in injury and possibly death.
Medical device companies have no choice but to embrace and understand the regulations while devising new ways of working. The companies that are most successful with their software localization are the ones building project specifications with internationalization in mind from the start, leaning on their translation providers from project inception to final testing. Preferably, the translation provider will have specific expertise in medical translation and use linguists who are experienced with not only software but specifically with medical device software.
First of all, let’s differentiate between localization and internationalization. Both words refer to ways of adapting software to specific locales and overlap in many ways. However, there are important differences. Internationalization comes first in the adaptation process and is directed at designing software applications so that they can be used in different regions and with different languages. Why internationalization should be the root process is obvious. Redesigning and reengineering a software program for a new linguistic environment after the fact are clearly going to be extremely expensive.
Localization is the process of adapting internationalized software for a specific locale through translation and perhaps the addition of culturally specific elements. Sometimes, the two processes are jointly referred to as globalization. A locale is a country (or even a region of a country) plus a language. Even the same language can vary between countries (for example, trunk and boot in US and UK English), and some countries are multilingual. Internationalization and localization are complex processes that involve software designers and engineering, marketing teams, translators and in-country specialists. However, careful planning can ensure the success of a localized product.
Internationalization
Before moving to localization, it is vital to know whether the software involved is internationalized. If it hasn’t been, there may be some substantial roadblocks to translation. To take a basic example, if the date and time format is hard-coded in the original software, the program will be difficult to localize. In the United States, dates are often written with two digits for the month, two digits for the day and two digits for the year. However, in much of Europe, the day comes before the month, while in Japan the year comes first.
Another thing to consider is whether the software supports foreign characters. If China and Japan are in the marketing plan, the code needs to support double-byte characters. While it is technically possible to represent Asian languages with single-byte code, this would be extremely difficult and costly.
In preparing software for localization, you want to have no hard-coded strings. Therefore, any fonts or other user-visible configurable data in the source code should be isolated. In other words, text that will be displayed to users should be kept in a different location than the code that actually runs the program.
Designers should ideally make use of the operating system resources. For example, with Windows, it is possible to use the Windows glossary and screens so that developers don’t end up redoing work that has already been done. In this case, make sure to use Windows-approved terminology to ensure consistency and make the interface easier for the user.
A good recommendation is for developers to use comments in their code. Comments are useful for clarifying what strings of code are for or where they actually appear in the software. Another helpful hint is to use pseudo-localization, which permits you to insert “fake” translation in the software to make sure that it will still run after being translated.
Software code needs to be able to handle different characters such as diacritical marks, as well as user inputs. User prompts need to be unambiguous and clear, especially since the prompts can be presented at times of user stress and emergency situations. Some device companies have started to use cognitive debriefing techniques, which were, until now, reserved for the validation of pharmaceutical patient-reported outcomes, in order to evaluate the effectiveness of software interfaces. Having to carry this out in multiple languages and geographies can complicate development pro-jects, not to mention the costs involved. On the translation side of medical device software, there is a narrow skill set for linguists, who must be able to translate software strings out of context, understand medical terminology and, in many cases, be savvy enough to test localized software on different platforms.
Internationalization can benefit from the creation of localization kits that identify the scope of the project, the files involved, the word counts and whether the audience is technical (physicians) or nontechnical (patients). You should write clear instructions for each group of people who will be working on the project. If time allows, it is a good idea to run a pilot project — perhaps a subset of the files — to make sure there won’t be major issues later in the process. After confirming that the software has been internationalized, the project can move on to localization.
Localization
Terminology is crucial in preparing for localization. Planners need to prepare a glossary with a list of terms relevant to the materials and to use the terms consistently. Basically, you want to identify terms that are important in the context and use one term for one meaning. For example, you want to say Enter key every time rather than sometimes using Return key. You want to use the verb strike or press or type or depress consistently in your material so that there’s no confusion as to what each term means. In general, you want to disambiguate as much as possible to make the translation easier.
For complex terms, you would want to provide a definition, a grammatical function and a context. The grammatical function is especially important in English, where nouns and verbs are sometimes spelled the same way. It’s important to know that you’re using a term that is either a noun or a verb so that the translator can find the appropriate translation for the glossary. In general, we recommend that you work with developers, in-country resources and your vendors in order to clarify any terms that might be complex or confusing. Try to keep complex terms to a minimum, but if you need to use such terms, provide a thorough definition so that the linguists can find a correct equivalent in the target language (TL).
Style guides are important in preparing for localization. Style guides contain information about how you want the name of your company or product to appear, as well as information about font guidelines. This is particularly important when software is involved because a different font may be used for commands, for example. Having capitalization rules set out (such as ALT or ENTER) also helps the translators because capitalization rules vary among languages. The style guide should include punctuation guidelines as well as information about how acronyms and abbreviations are to be handled. Guidelines for measurements are also important and are absolutely vital for medical software, where even slight errors in volumes or voltage settings can injure or kill. As we noted with terminology, consistency is the key to successful localization. Style guides should cover requirements specific to branding, such as company and product names, font guidelines, capitalization guidelines, punctuation guidelines, acronyms and abbreviations, and measurement guidelines — dates, times, temperatures, units of measurement and so on.
Translation
In preparing for translation, it is important to use simple sentence structure in the source text document to make the translation more fluid. It’s also important to avoid messages that are culturally loaded and to avoid using humor and colloquialisms. While three strikes and you’re out may speak to a US audience, the phrase is meaningless in many other cultures. Religious or political undertones should be avoided because they are difficult to translate and may be offensive in another culture. Tone is also important. Tone can be quite casual in the United States, while some materials and subjects require a more formal approach in other countries.
In general, you don’t want to squeeze your layout. For example, if the software contains dialogue boxes, you don’t want to put too much text in a box because the content often expands when the text is translated. In translating from English, French expands roughly 20%, German roughly 25% and Chinese about 30% to 40%. Such expansion can result in dialogue boxes that are either completely packed with text or that have become unreadable. This is also an important consideration for buttons. A button that is just large enough for the word Cancel may truncate the word Cancelar (Figure 2).
Text in graphics should be avoided for the same reason. If much text appears in a graphic in English, once the graphic is translated, the graphic might either need to be enlarged — which may not be possible — or the font reduced to the point that the text becomes illegible. Also, graphic localization is more expensive, so the less text appears in graphics, the better. As a further note on graphics, symbols that are perfectly acceptable in one culture may be offensive in another. Therefore, mainstream symbols such as those developed by the International Standards Organization are usually safest and the most accessible. Something else to consider is the issue of hot keys. Because the translator may have to choose a different key for some functions (think of the change from Close to Fermer), it’s vital to keep a running list to ensure that one key corresponds to one function only.
Designers also need to keep in mind that word order will change in translation and to write user interface sentences and commands that have logical syntax or units that allow the translators to create translations that are viable for the target audience. Grammatical gender is something else that nonlinguists may overlook. While we can say the patient’s name is ready in English without any reference to whether the patient is male or female, in many languages the phrase will need to be repeated to include both genders.
Other translation considerations include documentation cross-referencing between user guides and the software, and privacy laws, which are very strict in some countries. Here, you need to pay attention to what information you’re asking the user to input because that may not be in line with the local laws. We recommend consulting with your localization vendor and also with your in-country representative and counsel. The laws change frequently, so the best route is always to consult with a legal specialist to make sure that you are compliant.
Post-translation activities:
builds and testing
The build is the step at which the localized software starts to run. Obviously, an important question here is the operating system to be used (Mac, PC, Unix) and whether a specific or localized version of the operating system is necessary. At this point, some testing can also be done — for example, simulating error messages. This is also another point (the design stage was the first) to consider whether training is required to run the software and what sort of test plans exist.
You want to go through a linguistic validation — ideally run a version of the software in the TL — so that the translators can review the software in context. We recommend doing an in-country review with your in-country stakeholders to make sure that everything is being translated appropriately. The software should have a bug reporting and bug fixing mechanism so that if your translators or localization vendors find a bug, they are able to report it but also, ideally, to fix it. Performing regression testing is also a good idea.
The overall environment surrounding medical device software is one of heightened scrutiny due to the regulations that oversee its approval and use. While this places more demands on device companies and developers, it has the obvious benefit of ensuring better, safer medical devices for patients.
