A prescription that renders perfectly in English breaks the moment you translate it.
"Take one tablet twice daily after food" is 38 characters in English. The same instruction is 58 characters in German ("Nehmen Sie zweimal taglich eine Tablette nach dem Essen"), 45 characters in French ("Prenez un comprime deux fois par jour apres les repas"), and 27 characters in Japanese but rendered in wider glyphs that overflow the same container. In Arabic and Hebrew, the entire layout flips right-to-left, and the dosage numbers that should read "500mg" might render as "gm005" if the bidirectional text engine handles the transition between RTL text and LTR numerals incorrectly.
A truncated dosage instruction isn't a design flaw. It's a patient who doesn't know how much medicine to take. A garbled prescription in a patient's native language is worse than no translation at all, because the patient trusts it.
Health apps serving multilingual populations (India with 22 official languages, the EU with 24, Southeast Asia, the Middle East, Latin America) face a testing challenge that multiplies every clinical screen by every supported language. This guide covers what specifically breaks, why traditional testing tools can't catch it, and how Drizz validates that prescriptions render safely in every language on every device.
For prescription field validation, see How Drizz Validates Prescription Screens with 10+ Required Fields. For the foundational healthcare context, see What Makes Healthcare App Testing Different.
Key Takeaways
- The same prescription content varies dramatically in character count, glyph width, and layout direction across languages, causing truncation, overflow, and garbled rendering that English-only testing never catches.
- Seven specific localization bugs affect clinical safety: text truncation, font fallback failures, RTL layout breaks, numeral system confusion, line-break errors splitting dosage from units, character encoding garbling, and PDF generation stripping non-Latin scripts.
- Multilingual prescription testing multiplies exponentially: 14 required fields x 15 supported languages x 5 device types = 1,050 validation points. Manual testing is impossible at this scale.
- Appium can verify a text element exists in any language. It cannot verify the text renders completely, without truncation, in the correct direction, with correct numerals, and is readable on the actual screen.
- Drizz reads prescriptions visually in any language. If the text is truncated, garbled, or unreadable on screen, the test fails, because the patient can't read it either.
Why Translated Prescriptions Break
The Character Width Problem
English is one of the most compact major languages. When prescription content is translated, text expands:
A text container designed for 30 English characters overflows at 52 German characters. The UI that passed QA in English truncates the critical part of the instruction in German: "Nehmen Sie zweimal taglich eine Tab..." The patient sees "take twice daily one Tab..." and doesn't know if it's one tablet or two, morning or evening.
The Script Rendering Problem
Latin scripts (English, French, German, Spanish) share a common rendering engine. But health apps serving global populations must render:
- Devanagari (Hindi, Marathi, Sanskrit) with conjunct consonants that combine characters into ligatures
- Arabic/Urdu with right-to-left direction, contextual letter forms (same letter renders differently at start, middle, and end of word), and bidirectional text mixing (Arabic text with "500mg" in Latin numerals)
- CJK (Chinese, Japanese, Korean) with ideographs that require different line-break rules and larger font sizes for readability
- Tamil, Telugu, Kannada, Bengali with complex glyph shaping that many system fonts handle differently across Android manufacturers
- Thai with no spaces between words and tone marks that stack above characters
Each script has its own rendering requirements. A font that supports Devanagari perfectly may garble Tamil. A layout that handles RTL Arabic may break when the same container shows LTR English medicine names within RTL instruction text.
The Regulatory Problem
Many countries require prescriptions in the patient's local language:
- India: State medical councils recommend prescriptions in the patient's preferred language alongside English
- EU: Patient information must be available in the official language(s) of the member state where the medicine is dispensed
- Middle East: Arabic prescriptions are standard in GCC countries
- Latin America: Spanish/Portuguese prescriptions are legally required
A prescription that renders correctly in English but truncates critical fields in the legally required local language is both a patient safety issue and a compliance failure.
The 7 Localization Bugs That Affect Clinical Safety
1. Text Truncation on Dosage Instructions
The most common and most dangerous. Dosage instructions expand in translation and get cut off by fixed-width containers.
What the patient sees: "Nehmen Sie zweimal taglich eine Tab..."
What they miss: "...Tablette nach dem Essen" (the "after food" instruction that changes absorption and efficacy).
Why it happens: UI containers have fixed widths set for English content. Responsive text that wraps in web views may not wrap correctly in native mobile components. QA tested in English only.
2. Font Fallback Failures
The app uses a custom font for English (clean, branded, tested). When the prescription switches to Hindi, the custom font doesn't support Devanagari. The OS falls back to a system font with different metrics: different character width, different line height, different spacing. Text that fit in one line now wraps to three.
What the patient sees: Prescription text in a mismatched font with inconsistent spacing, some characters replaced with square boxes (missing glyphs), and layout elements overlapping.
Why it happens: Custom font files don't include all Unicode blocks. The fallback font is device-specific (Samsung uses one font, Xiaomi another, Pixel another). Nobody tested the prescription screen with the fallback font on each device.
3. RTL Layout Breaks
Arabic, Hebrew, and Urdu prescriptions must render right-to-left. But medicine names (Amoxicillin), dosages (500mg), and lab values (180 mg/dL) are in Latin script and must remain left-to-right within the RTL flow.
What the patient sees: "gm005 nillicixomA" instead of "Amoxicillin 500mg" because the bidirectional text algorithm incorrectly reversed the Latin characters.
Why it happens: The BiDi (bidirectional) algorithm handles most cases correctly, but edge cases with mixed scripts inside containers with explicit direction settings can produce reversals. Prescription fields that set android:textDirection="locale" may override the correct BiDi behavior for embedded Latin text.
4. Numeral System Confusion
Some locales use non-Latin numerals: Arabic-Indic numerals (used in Arabic-speaking countries), Devanagari numerals (used in some Hindi contexts), and other local numeral systems.
What the patient sees: A dosage of "500mg" rendered as "٥٠٠mg" (Arabic-Indic) which is correct for Arabic but confusing if the patient expects Latin numerals, or "500mg" in a locale where patients expect Arabic-Indic numerals and instead see unfamiliar Latin digits.
Why it happens: The app's number formatting uses device locale settings. A device set to Arabic locale may auto-convert "500" to "٥٠٠" in some text components but not others, creating inconsistency on the same prescription.
5. Line-Break Splitting Dosage from Units
Languages without spaces between words (Thai, Japanese, Chinese) or with different word-break rules create situations where a line break falls between the number and the unit: "500" on one line, "mg" on the next. Or between the frequency number and the word: "2" on one line, "times" on the next.
What the patient sees: "500" on line 1 and "mg twice daily" on line 2. They might read "500" as the quantity (take 500 tablets?) before seeing "mg" below.
Why it happens: Line-break algorithms optimized for Latin scripts don't understand that "500mg" is a single unit that shouldn't be split. CJK line-break rules differ from Latin rules. Custom line-break logic may not handle medical abbreviations.
6. Character Encoding Garbling
Text stored as UTF-8 in the database renders correctly on most devices. But PDF generation, push notification systems, or older API endpoints may use different encoding. A prescription that shows "Comprime" (French for tablet) in the app displays as "Comprim\u00e9" or "Comprim?" in the PDF or notification.
What the patient sees: Garbled characters in their downloaded prescription PDF, making it unreadable at the pharmacy.
Why it happens: The PDF generation library doesn't handle the full UTF-8 range. The push notification service strips or escapes non-ASCII characters. The API response encoding header mismatches the actual content encoding.
7. PDF Generation Stripping Non-Latin Scripts
The in-app prescription displays correctly in Hindi, Arabic, or Tamil. The patient downloads the PDF to show their pharmacist. The PDF shows blank spaces where the non-Latin text should be, or replaces it with square boxes, or shows only the English fields.
What the patient sees: A half-empty prescription PDF that's useless at the pharmacy.
Why it happens: The PDF generation library (often a different stack from the app's rendering engine) doesn't embed the fonts needed for non-Latin scripts. The library supports Latin and maybe CJK but not Devanagari or Arabic. Nobody tested PDF download in non-English languages.
Why Appium Can't Catch Localization Bugs
Appium verifies elements, not rendering. For localization testing, this gap is fatal:
Truncation is invisible to Appium: A text element containing the full German instruction exists in the element tree. Its .text property returns the complete string. But on a 5.5-inch screen, only the first 40 characters are visible. Appium's .is_displayed() returns True. The patient sees a cut-off instruction.
Font fallback is invisible to Appium: The element tree doesn't track which font rendered the text. Whether the text displays in the branded font or a mismatched system fallback with wrong metrics is a visual rendering detail that Appium cannot detect.
BiDi reversal is invisible to Appium: The text property of an element returns the logical string ("Amoxicillin 500mg") regardless of how the bidirectional algorithm rendered it visually. Appium says the text is correct. On screen, it reads backwards.
PDF rendering requires visual comparison: Appium can verify a PDF file was downloaded. It cannot open the PDF and verify that Hindi text rendered correctly inside it.
How Drizz Validates Multilingual Prescriptions
Drizz reads the prescription screen in whatever language it's rendered in, the same way the patient reads it. If the text is truncated, garbled, overlapping, or unreadable, the test fails.
Truncation Detection
Set app language to German
Open a prescription
Verify dosage instruction text is fully visible (not ending with "...")
Verify no text is clipped at container edges
Verify all 10+ required fields are readable in German
Drizz reads the rendered text on screen. If the German instruction is truncated, Drizz sees "...Tablette nach dem..." with content missing and fails the test. Appium would report the full text from the element tree and pass.
Script Rendering Validation
Set app language to Hindi
Open a prescription
Verify medicine name renders in Devanagari without square boxes or garbled characters
Verify dosage instructions are readable
Verify no characters are replaced with placeholder glyphs
Drizz sees what the patient sees. Missing glyphs (square boxes), garbled conjuncts, or font fallback mismatches are visual failures that Drizz catches because the rendered screen doesn't match what readable text should look like.
RTL Layout Validation
Set app language to Arabic
Open a prescription
Verify layout is right-to-left
Verify medicine name "Amoxicillin" renders left-to-right within the RTL layout
Verify "500mg" displays correctly (not reversed to "gm005")
Verify dosage numbers are in the expected numeral system
Drizz observes the visual layout direction and reads the medicine name as rendered. If BiDi processing reverses the Latin characters, Drizz sees the reversal on screen.
Cross-Language Automated Sweep
For each supported language [English, Hindi, Arabic, Spanish, French, German, Portuguese, Tamil, Japanese]:
Set app language
Open a test prescription
Verify all required fields are visible
Verify no text truncation
Verify no garbled characters
Verify PDF download renders the same fields
One test template. Nine language executions. Each one validates the complete prescription visually. This runs in CI on every build, catching the localization regression that only appears when a developer changes the prescription component's layout constraints.
PDF Cross-Language Validation
Set app language to Hindi
View prescription in-app (confirm all fields render)
Download prescription PDF
Open PDF on device
Verify Hindi text is present in the PDF (not blank or garbled)
Verify all fields visible in-app are also present in PDF
Drizz catches the PDF generation bug where Hindi text shows in-app but disappears in the downloaded PDF, a bug that manual QA in English never finds.
The Scale Problem (And Why Automation Is the Only Answer)
A health app supporting 15 languages with 14 required prescription fields tested on 5 device types:
15 languages x 14 fields x 5 devices = 1,050 validation points per prescription template.
With 3-5 prescription templates, that's 3,150-5,250 individual checks. Manually testing this before every release is impossible. Most teams test 1-2 languages on 1-2 devices and hope the others work.
Drizz automates the full matrix: one test template parameterized across languages and devices, running in CI on every build. The 1,050 validation points execute in under 15 minutes across 5 devices. A localization regression introduced on Monday's build is caught Monday, not discovered by a patient in Saudi Arabia three weeks later.
Conclusion
A prescription is a legal document and a clinical instruction. When it's translated, every rendering detail matters: truncated dosage instructions leave patients guessing, garbled text makes prescriptions unusable, reversed numerals change the medication amount, and PDF generation that strips non-Latin scripts creates documents that are blank where they matter most.
Testing prescriptions in English and assuming other languages work is how localization bugs reach millions of patients. The text exists in the database. The element tree shows the full string. But on the patient's screen, in their language, on their device, the critical instruction is cut off at the 40th character.
Drizz reads the screen the way the patient reads it. In every language. On every device. If the text is truncated, garbled, reversed, or missing, the test fails, because the patient can't read their prescription. That's the only test that matters.
Frequently Asked Questions
How many languages should a health app test prescriptions in?
Test every language your app officially supports. If the app offers Hindi as a language option, prescriptions must render correctly in Hindi. Prioritize by user base: test the top 5 languages on every build, remaining languages weekly. At minimum, test one RTL language (Arabic), one Devanagari language (Hindi), one CJK language (Japanese/Chinese), and one Latin-expansion language (German/French).
Can Drizz read text in non-Latin scripts?
Yes. Drizz's Vision AI reads text as rendered on screen regardless of the script: Latin, Devanagari, Arabic, CJK, Tamil, Telugu, Cyrillic, Thai, and others. It validates that text is present and visually readable, not that it matches a specific Unicode string.
What's the most common multilingual prescription bug?
Text truncation in German and French. These languages expand 40-73% from English, and fixed-width containers designed for English cut off the translated text. The truncated part is often the dosage frequency or the "with food/without food" instruction, both clinically important.
How do you test RTL prescriptions without speaking Arabic?
Drizz doesn't need a human to read Arabic. It validates structural patterns: layout direction is right-to-left, medicine names in Latin script render correctly within the RTL flow, numerals display in the expected system, and all required fields are present and visually distinct. A QA engineer who doesn't speak Arabic can write and maintain Arabic prescription tests.
Does multilingual testing increase CI/CD pipeline time significantly?
A 9-language prescription sweep on 5 devices takes approximately 12-15 minutes in Drizz Cloud (parallel device execution). For comparison, manual multilingual testing takes 2-3 days per release. Most teams run the full language sweep nightly and the top 3 languages on every build.
