Designing a signing flow for two scripts at once
Most software sold into Ethiopia is English software with an Amharic setting. The difference shows up in the places nobody demos.
The commitment sounds ordinary — the product works in English and Amharic — and it changes a surprising number of decisions once you take it seriously. Here are the ones that were not obvious when we started.
The document is bilingual before the interface is
The interface is the easy half. The hard half is that the document frequently has to carry both languages: a consent form whose operative text is Amharic and whose schedule is English, a bank form where the terms are in one script and the field labels in the other.
That means template fields cannot assume a language per document. They carry their own, so a single template can render an Amharic instruction above an English field on the same page without either becoming an image.
Type is a functional requirement, not a taste
Ethiopic has taller ascenders and a different vertical rhythm from Latin. Set at the same size and line height, Amharic looks cramped and, more importantly, gets clipped in fixed-height fields — which on a signing page means a signer cannot read what they are agreeing to.
- Ethiopic text is set from its own font stack, sized against Latin so a bilingual line does not step.
- Field boxes are measured against the taller of the two scripts, so nothing that fits in English overflows in Amharic.
- Any string a signer must act on is tested in both scripts before it ships — the sign-off is on the longer one, which is usually the Amharic.
Notifications carry the signer's language, not the sender's
This one took an argument. An organisation working in English sends a document to a signer who works in Amharic. Whose language wins?
The signer's — every time. They are the person being asked to understand an obligation, and the sender is the party with the lawyer. So the recipient's language is set per recipient, and the invitation, the passcode message and the completion receipt all follow it, whatever language the workspace runs in.
The audit trail stays in one language
The exception that proves the rule. The audit trail is evidence, and evidence that reads differently depending on who exported it is a problem in the room where it matters. So event names are recorded canonically, timestamps carry both Ethiopian time and UTC, and the display can be translated while the record itself does not move.
The rule we ended up with, and now apply everywhere: translate what people read, never what they will have to prove.
Written by The eFirma product team, Product at eFirma. Corrections and arguments are welcome at [email protected].
