Software localisation in the area of medical technology and pharma
A service provider specialised in medical technology and pharmaceutical translations that has also mastered software localisation? As a result of our customers’ needs, this specialisation has become part of our day-to-day business too.
Most medical devices used for diagnostics today are either directly installed in the device by means of a graphical user interface or are connected to the end user’s device for control purposes. Other devices that can be operated by end users and patients also often use apps that show measurements or enable controlling the device.
App
App in the area of pharmaceuticals
Our customers in the pharma sector use apps, among other things, to
App in the area of medical technology
Localising your software is essential in many respects and fulfils the following functions:
Most users will only accept software in localised form. This is why we explain how you should localise your software.
Translation and localisation
Software-Strings – Software-Codes
Localisation of software can differ significantly from the translation of instructions for use. It doesn’t have to, though. Depending on how the software strings are further processed on the customer side, we adapt our translation methods to your needs. There are still a few fundamental differences:
Programming languages and strings
If you can code it, we can localise it
Unlike with conventional documents, there are many different methods for including texts in software source text. Protecting the program code and only translating the visible text is fundamental in terms of being able to run the program in the target language and creating a functional product. In an ideal world, the visible text will already be separated from the program source text using suitable libraries and tools. Regardless of the form that your software texts are in, we have the right tools to provide an efficient translation.
Specialised software localisation tools generally offer similar functions to normal translation memory systems but go even further.
Example: WYSIWYG – “what you see is what you get”
One of the most important extensions is the WYSIWYG editor with a real-time view and the option to change the software interfaces. This means translators can view their translations directly in context and adapt them if a string is too long or a different translation would be more suitable in the given context.
Different labels/methods – same meaning
Of course we only translate the text content, but lots of programming languages include different special characters that have a meaning. Various programming languages and libraries use different labelling methods/tags for content that goes beyond the text such as special characters, bold font, keyboard shortcuts etc.
mpü test run – your security
Before we start the translation, we always carry out a test import and export to ensure that our customers can reimport the product we deliver without any problems.
mpü solution
If we need to adapt individual strings after the test run, our experts program individual filters for your file format.
We treat your code like code, not like continuous text.
Context and ambiguity
With our tools, translators can make the right decisions
The biggest difference from a conventional translation is that the context is often difficult to grasp.
Example
Individual words can be translated in different ways. Without context, for example, it’s not clear whether the word “button” means
- a digital button on the touchscreen display etc.
- the Guided User Interface of the device or
- a physical button on the device itself
Even short sentences can have different meanings.
In the code for software, lots of ambiguous words or short sentences without context appear together in strings, and it’s the translator’s job to match the strings to a particular context.
The solution
- An overview of the app, the way it works and its available functions is helpful.
- Our CAT tools, though, can display a preview of the translated strings even for some programming languages. This helps the translator to allocate the lines they have translated within the app or software.
- Comments from the developers or entries in the termbase can also help to situate the term within the software so the translator can make the right decision.
Quality control
We are aware of and recognise mistakes – trust in our experience
Quality control in particular needs to be carried out in a more differentiated way than for operating instructions. Again, this is because of potential ambiguity – not all words need to be translated consistently. Quality control needs to be aware of these details and differentiate.
“Button”, for example,
- could be the button within the app,
- but the same word in continuous text might describe a knob that the user has to push.
In this case, the word should not be translated the same way.
Tags
Tags can also cause unwanted error messages when checking for inconsistencies. Two sentences may perhaps only differ from each other by use of another tag.
Tags can have many functions withing the program, from simple “bold” typeface for individual words through to automatic date functions and on to complex designs in the background.
Lots of tags are irrelevant to the actual sentence content, but essential to the functioning of the software or whether it can be imported back into a CMS. Here at mpü, we counteract this by adjusting or creating filters. Tags selectively detected by the filter can then be hidden during the quality check.
We do test runs so your import goes smoothly.
LQA
Localisation Quality Assurance
Of course we know that you would prefer to do your Localisation Quality Assurance on the completed product yourself, but companies that are growing often don’t have testers in the
target language.
Findings for multiple languages – avoid sources of error
During the LQA, mpü always sticks to your specifications from the source language tests. When LQAs are carried out in multiple languages, the findings are shared so potential sources of linguistic error can be identified and remedied more quickly.
Communication platform – direct line to testers
Consulting with you as the customer and the software creator is particularly important in this phase, so we set up a communication platform for you and our testers. It is moderated by our project manager, but you can communicate directly with the testers.
Source text – extraction of the text
The code the software is written in mostly determines the approach that will be used.
If the customer extracts and inserts the text themselves, we often just get an Excel file with strings that need to be translated. This approach, though, can result in significant manual effort for very large projects. In an ideal world, we will advise you before we even do the first translation so we can keep the work involved to a minimum and enable automated workflows to be used as much as possible.
Test run
We can of course also translate directly in the files sent by the customer. In this case, the file is initially imported into our system as a test, then exported again to check whether any important parts of the string get lost or changed. Only after a successful test export and feedback from the customer do we start with the translation.
