•
Drizz raises $2.7M in seed funding •
•
Featured on Forbes
•
Drizz raises $2.7M in seed funding •
•
Featured on Forbes
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.
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.
Latin scripts (English, French, German, Spanish) share a common rendering engine. But health apps serving global populations must render:
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.
Many countries require prescriptions in the patient's local language:
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
©Drizz 2026 • All Rights Reserved
