Product · · 2 min read
Amharic-first, not translated after the fact
Internal software that gets translated at the end usually still feels foreign to the people using it. The interface has to be designed around the language, not retrofitted for it.
A common pattern in internal software built for Ethiopian teams: design the interface in English, ship it, then translate the labels into Amharic once someone complains. The result technically works. It also usually feels foreign to the people using it every day — because the interface was never actually designed for them.
Language isn't just vocabulary. It changes how information should be structured on the page.
Where "translate at the end" breaks down
A few concrete places where a bolted-on translation shows its seams:
- Text length. Amharic labels and phrases are frequently longer than their English equivalents. A button or table column sized for "Save" doesn't gracefully fit its Amharic counterpart — it wraps, truncates, or forces an awkward layout compromise.
- Reading flow and hierarchy. Interfaces designed English-first often lean on English-specific conventions for scanning — left-aligned labels, certain abbreviation patterns — that don't map cleanly onto Amharic text.
- The people who never see the English version. If frontline staff work entirely in Amharic, every English-first design decision is a decision made without their actual daily experience in mind, then patched over.
None of this is really about the Amharic script itself. It's about who the interface was designed for versus who ends up using it.
Designing from the language backward
The fix isn't a bigger localization budget — it's a different starting point. When language is a first-class input to the design process rather than a post-processing step:
- Component sizing accounts for realistic Amharic text length from the first wireframe, not after a translation pass reveals the problem.
- Workflows get validated with the actual staff who'll use them daily, in the language they'll actually use, before the layout is finalized.
- There's one canonical interface, not an English "real" version and an Amharic "translated" version that quietly drifts out of sync every time a feature ships.
The unglamorous part: it takes longer up front
Designing this way is slower at the start. You can't reuse as many off-the-shelf component patterns, and you need real conversations with real users earlier than a typical build timeline allows for.
What you get back is software that doesn't feel like a compromise to the people who spend their whole day inside it — which, for internal tools, is usually the entire point of building custom software instead of buying something off the shelf in the first place.