Product
One record, twenty specialties: how the modules fit together
A look under the hood of the Specialty Capability System, and why a shared record beats tailored silos.
6 min read
"Just add translation" is a sentence engineers learn to fear. For a medical product, where a mistranslated dose or a flipped negation can cause real harm, it's not a feature you bolt on. We built Doctopass to work in Arabic, French, and English from the data model up, and the hard parts were rarely the ones we expected.
Right-to-left is not a CSS setting
The first myth to drop is that supporting Arabic means flipping the layout. It does mean that, navigation, icons, progress, and reading order all mirror, but a clinical interface mixes scripts constantly. An Arabic consultation note contains Latin drug names, numeric doses, and dates. Getting bidirectional text to render correctly, so a dosage reads the right way round inside a right-to-left sentence, took far more care than mirroring the menus.
The layout mirrors. The medicine doesn't. A dose has to read correctly regardless of the language wrapped around it.
Translation that knows it might be wrong
When a patient writes to their doctor in Arabic and the doctor reads in French, auto-translation is genuinely useful. It's also a place where confident, fluent errors are most dangerous, a translation engine will happily render a wrong meaning in perfect grammar.
So translated messages in Doctopass are never presented as if they were the original. The reader can always see that a message was translated, and reach the source text in one step. For anything clinical, the original is one tap away, because the safe assumption is that translation is an aid, not an authority.
The rule we settled on
Translated text is always marked as translated, and the original is always reachable. The system helps the reader understand, it never quietly speaks for the other person.
Plain language survives translation; clever language doesn't
This one reshaped how we write the entire product. Idioms, humour, and clever phrasing don't survive translation, they turn into nonsense or, worse, into something that means the opposite. "Your results are ready" translates cleanly into any language. A breezy, idiomatic version of the same sentence does not.
So our content rules aren't only about tone. Writing short, literal, second-person sentences is what makes the same interface trustworthy in three languages. The plain voice you read in English is the voice that survives the trip into Arabic intact.
Built in, not translated later
The deepest lesson was about sequence. Teams that ship in one language and "internationalise later" usually discover their assumptions are baked in too deep to remove, text concatenated in English word order, layouts that assume left-to-right, dates and numbers formatted one way.
- We never glue sentences together from fragments; full strings are translated as units.
- Layout direction is a property of the whole interface, set once and respected everywhere.
- Numbers, dates, and currency format to the reader's locale, not the developer's.
Doing this from the start cost us time early and saved us a rebuild later. For a product meant to be rooted locally and then scale across borders, multilingual wasn't a phase. It was the foundation.