- What must be translated?
- How the EU MDR/IVDR language requirements work in practice (country-by-country).
- What an audit-ready ISO 13485-style translation process looks like.
What “medical device translation requirements” really mean (in plain English)
In practice, medical device translation requirements mean two things at once:
- What content has to be translated for a target market
- How those translations need to be controlled to stay safe, consistent, and auditable.
For example, in the EU, the language(s) you must provide for device information are largely driven by each country’s national rules (it’s not “one EU language policy” you can set and forget).
And because this information is safety-critical, the translation is treated like controlled documentation inside your quality system. You work from an approved source version, you record review and approval, you manage revisions, and you can prove which translation version matches which source version.
Practically, think of it as answering two audit questions:
- Coverage: “Did we translate every required piece of information that accompanies the device for this market?”
- Control: “Can we show traceability and version control (review/approval, current revision status, and withdrawal of obsolete versions) across every language version?”
That’s the core idea.
Instead of thinking of it as “how do we translate this documentation into this language,” think about it as “how do we translate it without losing control of the truth over time.”
Translation requirements: Labels, IFU, packaging, UI/software, and “hidden” docs
In Europe, the non-negotiable baseline is the information supplied with the device. That means the label and instructions for use (IFU), as well as related packaging information.
Under MDR Article 10(11) and IVDR Article 10(10), that information must be provided in the official Union language(s) required by the Member State where the device is made available. Because countries set their own rules, language needs vary across the EU/EEA (the Commission even publishes country-by-country tables to reflect this reality).
Everything else “must” be translated in a more practical sense. If a user, patient, distributor, auditor, or authority will rely on it to use the device safely or evaluate compliance, treat it as translation-controlled content.
That includes software text (because “medical device” explicitly includes software in the MDR definition), and even promotional materials (because MDR/IVDR restrict misleading claims in labelling, IFU, making available, and advertising).
Also, some “hidden” compliance documents may need to be made available in an official Union language depending on the Member State (or notified body) context. You can treat the table below as a useful operational map to go by:
A useful rule of thumb here is to assume that the translation scope expands to cover questions like “who could get hurt” and “who could audit you.” Some countries interpret “information necessary for safe and proper use” quite broadly, including electronic formats (not just paper IFUs).
EU MDR/IVDR language requirements: What counts as “labelling” and who decides languages
In the MDR/IVDR world, “labelling” doesn’t just mean the sticker on the box. The regulations treat it as part of the broader “information supplied with the device” (i.e., what appears on the device, on the packaging, and in the IFU).
The MDR/IVDR Annex I chapters on “Label and instructions for use” make this explicit, and they even note that some required information may sit on packaging or in the IFU depending on space and practicality.
Who decides the required languages?
Usually, the country you’re selling into. Under MDR Article 10(11) and IVDR Article 10(10), manufacturers must ensure the device is accompanied by the Annex I information “in an official Union language(s) determined by the Member State” where the device is made available. Translation isn’t one EU-wide language rule but rather a market-by-market compliance requirement.
That’s why, practically-speaking, manufacturers typically build a country-language matrix aligned to their distribution plan. The European Commission publishes overview tables summarizing national language requirements under MDR and IVDR, and they show exactly what you already suspect: requirements vary (and in some cases, English may be accepted under defined conditions).
Quick note on electronic IFU (eIFU)
If you’re thinking “we’ll just ship eIFUs and dodge paper,” the EU has rules for that too. Implementing Regulation (EU) 2021/2226 sets conditions for providing IFUs electronically, including expectations around access and language availability. And Implementing Regulation (EU) 2025/1234 broadened the scope for professional-use devices (while still recognizing that paper may remain necessary for lay-person use cases).
The bottom line is that the eIFU changes the delivery format, not the language obligation.
European Economic Area (EEA) & Switzerland: Relevant but not identical
Even within the EEA, national implementation and expectations can differ, which is why those country tables matter in practice.
While Switzerland is not in the EU nor EEA, it remains a common “also relevant” market operationally. Swiss requirements are often discussed alongside MDR because Swiss rules reference MDR concepts.
For instance, Swissmedic training materials summarize that product information comprises labelling and IFU and indicates three official languages (German/French/Italian) or symbols, with fewer languages possible in some professional-only scenarios.
Medical device software & SaMD: GUI translation requirements and safety exceptions
In the EU, this is the first mental switch: software can be the medical device. The MDR definition explicitly includes “software” as a medical device when it has a medical purpose.
That means your app’s UI isn’t “just UX.” If it’s how the device communicates operating instructions, warnings, results, or adjustment parameters, it becomes part of the device’s safety-and-performance story. Regulators expect it to be understandable to the intended user.
Are there separate “GUI translation rules” under MDR/IVDR?
Not really. MDR/IVDR mostly apply the same core obligations to software-delivered information that they apply to labels/IFUs:
- Devices must be accompanied by the Annex I information in the official Union language(s) required by the Member State where the device is made available.
- The medium/format/content/legibility/location of the information must be appropriate to the device and intended users, and IFU text must be readily understood.
From a translation perspective, it means that if your GUI contains any information needed for safe use (warnings, steps, thresholds, results interpretation, contraindications, etc.), treat those strings as regulated “information supplied with the device,” not “optional localization.”
Safety exceptions and practical nuance (not loopholes)
A few carve-outs matter operationally:
- Language requirements can vary by country, and some countries may accept another language (often English) for professional users when safe use isn’t compromised. The European Commission’s MDR language table explicitly calls out this reality and frames it as something Member States may choose to allow.
- IFU isn’t always mandatory for all devices (e.g., some Class I / IIa devices) if they can be used safely without it. That’s not permission to have a confusing UI. If the UI is how the device instructs the user, it still needs to be understandable.
- Replacing paper with electronic IFU or in-app instructions is permitted only under defined conditions (mostly for professional use), but providing interactive help is common. However, update control matters (e.g., keeping versions available and managing updates). If your “IFU” lives inside the software, your localization workflow has to handle versioning like a regulated deliverable.
- Symbols can reduce text, but they must be internationally recognized and align with recognized standards. Where no harmonized standards exist, symbols and colors must be explained in the documentation.
The top 5 ways SaMD localization breaks (and why it’s not “just translation”)
1. UI truncation changes meaning
“Do not reuse” becomes “do not…” on smaller screens, or a warning title gets chopped so it reads like advice instead of a hazard. This is why in-context LQA (linguistic QA) on real devices and builds is a safety activity, not polish.
2. Decimal separators and units
1.5 vs 1,5; mg/dL vs mmol/L; “billion” vs “milliard.” If the UI renders numbers, dosage, thresholds, or results, you need locale-aware formatting and unit strategy (not a translator guessing).
3. String reuse changing context
A single key like “Close” appears as “close the window,” “close the case,” “close the wound,” and “close (nearby).” Reuse saves developers time and destroys meaning. Give translators context (screenshots or notes) or split keys.
4. Warnings and informational hierarchy destroyed by layout
In one language the warning fits a bold header and body. In another, it reflows so the warning label looks like body text and the body looks like a footnote. MDR cares that information is readable and appropriate for intended users. And layout is part of comprehension.
5. Hard-coded strings escaping translation management
One developer hard-codes a critical alert “temporarily,” it never enters your translation system, and now you ship a mixed-language UI where the riskiest message is the least controlled. This is how “regulated content” quietly becomes “random strings in code.”
A practical rule of thumb: If a string can influence use, interpretation, or action, handle it like labeling/IFU content (controlled source, reviewed, versioned, released per market-language matrix, and regression-tested in the UI).
The ISO 13485 translation procedure and how it differs from the ISO 17100
First, the ISO 13485 isn’t a “translation standard.” It’s a medical-device quality management system (QMS) standard. It cares less about how you phrase a sentence and more about whether your translated content is controlled, approved, traceable, and kept current like any other regulated document.
By contrast, the ISO 17100 is explicitly a translation-services standard. It defines requirements around translation processes, roles/resources, and quality steps inside a translation provider.
Note: It is worth noting that the ISO is already working on a new edition, the ISO/AWI 17100 (Edition 2), to replace the 2015 version).
What your ISO 13485-style “translation procedure” should cover
You can think of this as the set of controls that let you answer some of the favorite questions auditors like to ask. For instance, “how can you tell if the French IFU matches the approved source?” or “who approved it?”
With that in mind, feel free to use the following procedure checklist to navigate these requirements:
- Controlled inputs (approved source and version)
- Only translate from an approved, released source (ID, revision, date).
- Freeze the source (or clearly log what’s in scope) so you don’t translate a moving target.
- Treat bilingual deliverables as controlled documents/records inside document control.
- Qualified resources (SME, translator, and reviewer)
- Define competence criteria for each role (domain, language, and regulatory familiarity).
- Assign responsibilities clearly: Translator, independent reviewer (linguistic), and SME/RA/QA reviewer where safety and regulatory meaning is involved.
- If outsourced, treat the translation provider like a controlled supplier (qualification and performance monitoring).
- Review & approval records (traceability)
- Maintain evidence of review and approval for each language (who, when, and what version).
- Record the linkage (track the source doc review, relative to the target language review and release package).
- Keep issues and resolutions (terminology decisions, deviations, risk-related queries, etc.) as part of the record trail.
- Change control
- Define triggers (source revision, safety update, labeling change, UI string update).
- Require impact assessment:
- Which languages?
- Which assets (IFU, packaging, UI)?
- What needs a modified layout and DTP.
- Ensure old versions are withdrawn and blocked from use and the new version is distributed correctly.
- Retention
- Set a retention rule that meets ISO 13485’s expectations. As in, retain records at least for the device lifetime (as defined by the organization) or as required by regulation, but not less than a minimum period after release.
A practical tip: Translation evidence isn’t just final PDFs. Keep the approval trail, change logs, and any release notes that prove control.
What's the difference compared to the ISO 17100
In plain language, the core difference is:
- ISO 13485: “Show me control.” It’s QMS logic (document control, records, competence, supplier oversight, change management).
- ISO 17100: “Show me translation-service quality mechanics.” It’s translation-process logic (defined roles and process steps for delivering a quality translation service).
In practice, many teams combine them. They use an ISO 17100-like translation workflow (translation and an independent review) inside an ISO 13485-style control wrapper (versioning, approvals, retention, and change control).
Validation and QA: What “good” looks like beyond a bilingual review
Regulated content needs to clear a fairly high translation bar. You need to be concerned with how easily users understand content; in the real format they will be exposed to without any subtle meaning shift due to layout, UI constraints or locale conventions.
The MDR is fairly blunt here, the medium, format, content, legibility and location of the label and IFU must be appropriate and easy to understand by their intended user (enabling different vernacular depending on the target, i.e., doctors or patients).
In this context, “good” means a layered quality assurance process (QA) not a single step.
When do you need linguistic validation?
Most device labeling or IFUs don’t require “linguistic validation” as a formal method. But it becomes important when the translated text is directly used to measure outcomes or user understanding, such as:
- Patient-facing questionnaires / clinical outcome assessments (COAs) used in studies
- Usability/human factors validation contexts where comprehension is safety-critical
- Instructions that will be tested with end users in-country
In those cases, we typically borrow a well-established playbook from outcomes research. We use multiple forward translations, reconciliation, back translation, expert review, and cognitive debriefing with target users to confirm the text is understood as intended.
When should you use in-country reviews?
In-country reviews are not necessary for all devices and procedures. But they are particularly useful when:
- Confirming real-world phrasing for clinicians or patients in a specific country
- Catching issues where something “looks fine but feels wrong” (register, ambiguous instructions, local conventions).
- Spotting terminology that’s technically correct but not what users actually expect.
On the other hand, in-country reviews can be more trouble than they are worth if:
- Reviewers rewrite for style and accidentally change regulated meaning
- “Drive-by edits” with no rationale, no traceability, and no alignment to glossary or approved terms
- Feedback arrives as screenshots and opinions instead of actionable, auditable change requests
A pragmatic approach is to treat in-country review as structured evidence-gathering, not creative writing. It should require:
- A reason for change
- A risk category (safety / regulatory / preference),
- An approval routing back through RA/QA.
This aligns with the MDR’s emphasis on user comprehension and appropriate presentation of information. When in doubt, it is often better to use vendors with a track record in this field.
Format changes and when DTP becomes part of the process
Labels and IFUs are layout-sensitive. Warnings, contraindications, symbols, and references to figures can break without a single “translation error.”
The MDR explicitly ties compliance to legibility, format and location (not just the words). With that in mind, the following issues should be carefully vetted:
- Truncation and line-wrap (especially on small labels, tables, warning headers).
- Symbol integrity and explanations (where applicable).
- Numeric formats, decimal separators, units, and ranges (and that they display correctly).
- Cross-references (after a layout change, ensure that “section X / figure Y” still points to the right thing).
- Font encoding and special characters (μ, ≤, ≥) surviving export or the printing process.
"Beyond a bilingual review” QA stack (a workable minimum)
If you need a simple mental model, it’s this:
- Linguistic QA (terminology, meaning, numbers/units)
- In-context check (on-device UI build / final PDF proof, not a Word doc)
- DTP/format QA (legibility + warning hierarchy + reference integrity)
- Release sign-off with traceability (who approved what version for which market)
Keep in mind that for software/SaMD, this overlaps heavily with usability and human factors expectation. In fact, the FDA’s usability engineering guidance and IEC 62366 both treat usability as safety-relevant, which is exactly why “string fits” and “warning is obvious” aren’t cosmetic details.
How to select a translation provider for medical devices: A 2026 checklist
- Glossary and termbase governance
- They can build and enforce a termbase (not just “we’ll try to be consistent”).
- Clear process for term approval (i.e., who decides? RA/QA/clinical/brand?) and how changes propagate.
- They flag high-risk terms (contraindications, warnings, units, anatomical/clinical terms) for explicit confirmation.
- Traceability and version control
- Every deliverable is tied to a source document ID + revision (no “latest_final_v7_reallyfinal.docx” energy).
- They can provide a translation package (what changed, who reviewed, what’s approved, and which files are released).
- They support change control, i.e., when the source updates, you can reliably identify impacted languages/assets and turn updates around without chaos.
- Traceability and version control
- They support change control, i.e., when the source updates, you can reliably identify impacted languages/assets and turn updates around without chaos.
- They support change control, i.e., when the source updates, you can reliably identify impacted languages/assets and turn updates around without chaos.
- They support change control, i.e., when the source updates, you can reliably identify impacted languages/assets and turn updates around without chaos.
- Regulated workflow familiarity
- They understand that QA/RA sign-off is part of the workflow (and don’t treat it as “client being difficult”).
- They run independent review as a standard step for regulated content (separation of translator vs reviewer).
- They can handle CAPA. If an error happens, they can explain root cause and prevention, not just apologize and move on.
- DTP and format capability (labels and IFU reality)
- In-house DTP (or tightly managed) for InDesign/Illustrator and label formats—not “we can convert to PDF.”
- They do layout-sensitive QA (truncation, warning hierarchy, symbol integrity, cross-references, print legibility).
- They can deliver in your required formats (IDML, AI, PDF/X, XML, string files) and manage font/encoding correctly.
- Security and confidentiality (especially for SaMD strings)
- Secure file transfer options, access controls, and clear rules for who can access what.
- Policy on LLM/MT use (allowed? restricted? opt-out? how is data handled?) and it’s contractually explicit.
- They can work with string repositories safely (e.g., controlled access to JSON/RESX/PO files) and avoid leaking hard-coded strings into random email threads.
- Quick “evidence to ask for” (fast credibility check)
- Sample traceability pack (sanitized). Source review, target review and review/approval trail
- Example terminology workflow (how a term gets approved and enforced)
- Example label/IFU DTP QA checklist
- Summary of their information security controls and MT/LLM policy
While we hope that this article was a valuable guide in your processes, it can be daunting to tackle alone. In doubt, it is often better to reach out to vetted professionals to get a second opinion. Why wait?