This guest blog is written by Rohan Darar from Transcom Global Ltd, expert translators for the life sciences. Also available in French and German.

The software developers at Firefinch support innovative life science companies to ensure their software is user friendly, compliant and scalable to international markets. Firefinch work with companies of all sizes, but a common mistake that we see with some of our less experienced clients is not building scalability into their architecture from an early stage.  

At Transcom Global, we see the same blind spots from the language side: translation treated as an afterthought, bolted on just before or after launch, rather than woven into the architecture from day one. 

If your software is destined for international markets translation requirements are not a post-development concern. They are a core design consideration, a regulatory obligation, and, if handled poorly, a direct route to audit findings. 

This blog sets out the key translation considerations every development team should be thinking about from the very beginning.

Why Translation Is a Regulatory Issue, Not Just a UX One 

Translation in regulated software is not simply about making your product accessible, it is about ensuring it is safe, compliant, and accurate. Whether you are developing software that controls GMP/GCP instrumentation, a medical device application, or an IVD (In Vitro Diagnostic) platform, regulators expect that end users can understand and interact with software correctly, in their own language. 

A mistranslated unit, an ambiguous warning message or an incorrect instruction can have serious consequences for patient safety, data integrity, and regulatory compliance. For this reason, regulators are increasingly explicit: user-facing software must be localised for the markets in which it is deployed. 

User centricity is a regulatory expectation. If an operator cannot understand the software interface in their working language, that is not an accessibility gap — it is a compliance risk. 

Regulatory Differences Around the World 

An important consideration early in your software design process is: where will this product be sold? The answer shapes your entire translation strategy, because regulatory language requirements vary significantly across jurisdictions. 

European Union (EU MDR / IVDR) 

Under EU MDR (2017/745) and IVDR (2017/746), instructions for use must be provided in the official language(s) of the Member State(s) where the device is placed on the market. While neither regulation explicitly mandates localised software interfaces, broader obligations around usability, safety, and risk management extend the principle beyond requirements. A device whose interface generates misunderstood alerts creates demonstrable risk. 

United States (FDA) 

The FDA does not specify English-only requirements and increasingly expects labelling and software interfaces to be accessible to the actual population using the device. 

Asia-Pacific (PMDA, NMPA, TGA) 

Japan’s PMDA requires Japanese-language documentation and software interfaces. China’s NMPA requires Simplified Chinese labelling and user interfaces. Australia’s TGA mandates English, but broader Asia-Pacific distribution typically requires local language versions. Each of these markets has specific submission requirements, and translation quality is subject to regulatory scrutiny. 

GMP and GCP Instrumentation 

For software used in GMP (Good Manufacturing Practice) and GCP (Good Clinical Practice) environments, the principle of user centricity is fundamental. Operators must be able to correctly interpret system messages, prompts, error states, and alerts without ambiguity. Where operators’ primary language is not English, software operating in English alone introduces an unacceptable risk of operator error. 

The AI Translation Problem: Why Automated Tools Cannot Be Your Answer  

It is tempting, given the rise of modern AI translation tools, to treat translation as a largely automated exercise. Run text strings through a large language model, and add it into the language module of your software without reviewing the output. 

In regulated environments, this approach carries serious risk. 

AI-generated translation, where it cannot be demonstrated to have been reviewed and validated by a qualified human translator, is a known audit failure point. Regulators and auditors expect translation to be a controlled, documented process, not an automated output.

AI translation tools, however sophisticated, introduce a number of specific risks in regulated software contexts: 

• Risk of undetected inaccuracies: AI-generated translations may introduce subtle factual errors or hallucinated content that are difficult to detect without thorough subject-matter review. 

• Context blindness: Software strings are often short and stripped of context. An AI tool translating isolated UI strings may misinterpret meaning, selecting a technically valid word that is functionally incorrect in context. 

• Lack of documented validation: Regulators expect evidence that translations have been reviewed and approved by qualified individuals. An AI-generated translation lacks the audit trail a human-led, CAT-tool-supported process provides. 

• Cultural and linguistic nuance: Medical and scientific communication requires precision. Culturally inappropriate phrasing, even if technically accurate, can mislead users or create safety issues.

The right approach is professional, subject-matter-expert human translation, supported by controlled translation memory and glossary tools all documented in a way that can withstand regulatory scrutiny.

Build Translation In From the Start: Design-Stage Considerations 

Here is the single most important piece of advice we can offer: translation cannot be a retrofit. By the time you realise your software architecture does not support multiple languages, you are already looking at significant rework. 

The Technical Challenges of Multilingual Software 

Beyond the organisational and process considerations, there are a number of technical challenges that arise specifically in multilingual software development. Below are a few of the common ones.

Special Characters and Font Support 

Not all languages use the Latin alphabet. Japanese, Chinese, Korean, Arabic, Hebrew, Greek, and many other scripts require specific Unicode character ranges and font support. Your chosen fonts must support all the character sets you intend to display. 

Beyond character support, right-to-left (RTL) languages such as Arabic and Hebrew require layout mirroring. If your software may ever be deployed in an RTL market, this must be designed in from the start. 

Accents, umlauts, cedillas, and similar characters common in different languages must also be handled correctly at every layer. A validation report that renders an umlaut as a question mark is not an acceptable document in a regulated environment. 

Text Expansion and UI Layout 

One of the most frequently overlooked translation challenges is text expansion. A phrase that fits neatly in a button in English may be 30–40% longer in French or Spanish, or 60% shorter in Chinese. If your UI is designed with fixed-width components and English text in mind, translated interfaces will break: text will overflow, be truncated, or wrap in ways that make the interface unusable. 

Date, Time, Number, and Unit Formatting 

Locale differences extend beyond language. Date formats (DD/MM/YYYY vs MM/DD/YYYY vs YYYY-MM-DD), decimal separators (comma vs full stop), thousands separators, and unit conventions all vary by locale. In regulated environments, particularly in GMP/GCP instrumentation and IVD software, incorrect unit or number formatting is a data integrity issue, not merely a cosmetic one. Use locale-aware formatting libraries and validate that all numerical outputs render correctly in each target locale. 

What Good Translation Management Looks Like

A robust, audit-ready translation process for regulated software should include: 

• A controlled translation memory that ensures consistency across releases and reduces cost for repeated or similar strings. 

• A managed glossary of approved translations for key technical and regulatory terms, reviewed by subject matter experts. 

• A documented review and approval process with named, qualified reviewers for each language, ideally combining professional translation with in-country expert review. 

• Integration with your change control process, so that any change to English source strings triggers a managed translation update. 

• Audit trail documentation demonstrating who translated what, when, with what tools, and with what review and approval. 

This is precisely the kind of structured, documented translation programme that Transcom Global provides, built to integrate with the software development lifecycle as managed by teams like Firefinch.