When software is localised, it’s adapted to make it more acceptable to a chosen market or audience. It’s an activity that tends to encompass more than just language translation. Depending on what issue the software tackles, the localisation process can include updating the currency, product sizing, mapping and geo-locational elements, to suit the intended audience.
When the interface that is being localised is medical in nature, there are additional complicating factors. In most markets, medical software has to go through rigorous QA processes and jump through multiple regulatory hoops prior to getting released. This usually means that the project cycle is typically much longer than it is for other types of software.
When software is localised, it isn’t just the language that changes. The process includes adapting the product to better match local cultural expectations. This might include updating any graphics images used in the software and accompanying materials to make them culturally appropriate.
Localisation may also include changing how the software matches gender role expectations, social hierarchies and other cultural elements for the new market.
When the software is medical there may also be other aspects to consider. For example, local cultural approaches to health may need to be taken into account.
You may need to consider how users interact with health practitioners, how their health is managed in a family context and factors such as how their medical care is funded. These elements may affect how you tailor your product to a local market.
Managing the process
If you’re managing a medical software localisation project using an external localisation team, you need to plan your approach carefully. Start by choosing the right partner – if it’s a medical software project then you’re likely to need one with specific regulatory knowledge and experience for that market.
Writing a robust specification is valuable because that helps set expectations and keep the project on track. Everyone working on the project should review the spec carefully to make sure it’s all understood and everyone is involved in agreeing to it. At this stage of the project, risks should be identified and contingency strategies agreed for meeting them.
Building a collaborative relationship with the localisation team is a key factor in the success of the project. You need to be actively involved in the project right the way through, rather than just handing it over to the localisation team and returning at the end.
To ensure a more efficient and cost-effective localisation process, your localization project should be one of end-to-end collaboration rather than merely handing over documents to your localisation team.
Your involvement is an important part of the project’s success. For practical reasons, it may help if you can assign a dedicated project owner to handle the localisation project and manage the localisation team. This helps you continue with your regular tasks and ensures the project isn’t neglected as a result.
One of your most important responsibilities is helping to build a localisation kit. This helps guide the translation team and advises them on terminology and any other specific medical or specialized knowledge that the localisation team requires.
You should help provide input into developing any glossaries or terminology banks that the project requires, and help oversee style guides as they are created by the translation team. If you’re localising the software into more than one market, you may need to duplicate this work for other languages and cultures.
Remember also to make any collateral material available in a format that the localisation team can use. This will include elements such as your brand logo, any graphics used on the original software, fonts and images.
It may be helpful to use file-sharing software to give access to external teams. Don’t forget to check the copyright on any purchased images, as these may not automatically be covered for use in the way you expect.
One of the reasons your input is important is that this can really help speed the project through to conclusion. By making yourself available right the way through the project, decisions can be made quickly and issues resolved early on. If your localisation team can’t get what they need from you when they need it, it risks delaying the project.
Quality is key
To some extent, managing a medical software localisation project should be approached in the same way as managing any other type of localisation project.
Choosing the right team with the appropriate language and cultural understanding is vital; initial work can sometimes be handled by machine translation, and then human translators oversee the rest of the work.
The key difference is how the quality control is managed. Medical products tend to require a much higher level of quality control compared to other types of software. This is to ensure patient safety and to help avoid any business risk associated with giving the wrong information.
It’s also likely that your software will be reviewed by external regulators to ensure it meets local compliance and regulatory standards. Your project needs to undergo a thorough internal review process to ensure it will successfully pass these assessments.
It’s advisable to start quality control early in the project rather than leaving it right to the end, for example, reviewers should start to examine samples from the project as soon as any are available. This helps identify any emerging concerns before they are replicated at scale.
Quality control has to take into account all elements of the project, including how the software works overall in its new environment as well as the more obvious parts of the localisation project such as how effectively the text has been translated.
It would be wise to remember that medical software projects usually require not just the main interface to be localised, but also other elements such as any online or printed help materials or instructions, clinical trial paperwork, release notes and supporting documentation.
Read More: How to Achieve Quality in Software Translation and Localisation Projects
You can also help input into the important quality control process by making your local teams available to help review the project at every stage.
If your organisation has local teams and native speakers, it’s really helpful to get them involved in reviewing the localised software. A good tip is to book their time in when you expect to need them to review stages of the project, as this help ensure QA happens quickly and efficiently.
Achieving success
So what does success look like? A software localisation project can be judged a success if it could easily pass as software that’s been developed in the local market rather than adapted for it.
This implies a level of cultural fluency and an understanding of the needs of the target market, which tends to mean the product is much more likely to succeed there. This is what you should be aiming for when you localise any software project.