Respondo was built in Dubai, and that fact shaped the product more than any roadmap decision we made. A single support queue here might carry a customer writing in Arabic, another in English, a third in Hindi, and a fourth in Urdu — often within the same hour. There was never a version of this product that treated one language as the default and the rest as translations. Thirty-plus languages, including right-to-left ones, had to be the foundation, not a layer we added later.

That constraint turned out to be clarifying. When multilingual isn't optional, a lot of shortcuts that seem reasonable in an English-first product reveal themselves as dead ends. This is what we learned building for that reality across both the AI and the interface.

Translation is not understanding

The tempting architecture is a pipeline: take the incoming message, run it through a translation API into English, process it with your English models, generate an English reply, translate it back. It's cheap, it's fast to build, and it fails in exactly the situations customer service is made of.

Customer conversations are dense with context that generic translation flattens. Slang, idioms, politeness registers, and domain-specific terminology all get sanded down in the round trip. The classic example is a single word with a branch in meaning: a customer asking about a "return" in a retail context wants to know about sending a product back; the same word in a financial context is about investment yield. Translate-process-translate loses the thread, because by the time the English model sees it, the disambiguating context has already been mangled.

Respondo uses language-specific models instead. A message in Arabic is understood and answered in Arabic, natively, without ever passing through English as an intermediate representation. The distinctions that matter — tone, register, the right sense of an ambiguous word — are captured in the language they actually live in. That's the difference between a reply that's technically correct and one a native speaker recognizes as fluent.

When the interface flips

Handling the languages in the model is half the problem. The other half is the interface, and right-to-left languages are where most design systems quietly fall apart.

Supporting Arabic and Hebrew isn't a matter of translating strings. The entire layout inverts. Text aligns right. Reading order runs right to left, which means the visual flow of a conversation, the position of a back button, the direction an arrow should point — all of it mirrors. A design built with left-to-right assumptions baked into fixed positions doesn't translate to RTL; it breaks.

The subtle part is that not everything flips. This is the trap teams fall into when they discover the CSS direction property and think the job is done.

  • Layout, text alignment, and reading order mirror. A sidebar on the left in English belongs on the right in Arabic.
  • Icons with direction inherit the flip. A "reply" arrow or a "next" chevron has to point the other way, because its meaning is directional.
  • Content that is inherently LTR does not flip. Phone numbers, Latin-script brand names, code snippets, and URLs read left to right regardless of the surrounding language. Mirror them and you've created nonsense.

Getting this right by hand, component by component, across a whole product is exactly the kind of task that's impossible to keep consistent as the product grows. So we didn't do it by hand.

Constraint-based, not position-based

The decision that made RTL sustainable was to stop describing our components in terms of absolute positions and start describing them in terms of relationships.

A position-based component says "this label sits 16 pixels from the left edge." That instruction is wrong the moment the layout flips. A constraint-based component says "this label sits at the start of the row, 16 pixels of space before the content begins." Now "start" resolves to the left in English and the right in Arabic automatically, and the same component definition renders correctly in both directions without a single conditional.

We leaned on the browser's own logical properties to express this — the modern CSS that thinks in *start* and *end* rather than *left* and *right*, and in *inline* and *block* rather than horizontal and vertical. A component authored this way doesn't know or care which direction it's rendering in. The direction is set once, at the root, and every component underneath adapts.

The payoff compounds. Adding the next RTL language costs almost nothing, because the layout logic was never tied to a specific direction in the first place. A new component built on the shared primitives is correct in both directions by default — an engineer would have to go out of their way to break it.

Room for the text to breathe

The last lesson is the least glamorous and the most frequently ignored: text length varies enormously across languages, and a layout that only ever saw English will crack under the ones that don't fit.

The same phrase can run 30% longer in German, arrive in a completely different character set in Chinese where a few glyphs carry what English needs a sentence for, or need more vertical space for the diacritics that sit above and below Arabic script. A button sized to the English word "Send" clips or overflows the instant a longer translation lands in it.

Our components assume from the start that they don't know how long their text will be. They grow with their content, wrap gracefully, and never depend on a string being a particular length. It's a small discipline that saves a thousand one-off layout fixes later — and, like the direction handling, it's the kind of thing that's nearly free if you build it in from day one and enormously expensive to retrofit.

The through-line

Every one of these decisions rhymes with the same idea: multilingual can't be a feature you add, because the assumptions of a single-language product reach into the model, the layout, and the individual component. Build English-first and you spend the rest of the product's life patching the places those assumptions leak. Build for thirty languages from the start and the thirty-first is almost free. Being based where our customers speak a dozen languages a day didn't make this harder — it made it impossible to get wrong quietly, which is the best kind of constraint to design under.