My teams work in Hindi, Japanese, German and Arabic. Is your multi-language story real engineering or a Google-Translate checkbox?

The full executive answer

Real engineering at the foundation layer, honestly incomplete at the content layer — let me draw that line precisely. Shipped in code: a locale registry supporting seven languages — English, Spanish, French, German, Arabic, Hindi and Japanese — with full right-to-left support for Arabic driving the document direction and layout, BCP-47-correct formatting of dates, numbers and currencies per locale, and standards-based language negotiation that honours the user’s browser preferences with proper quality-weighting. RTL is the detail I would highlight: most SaaS bolts it on years late and it shows; ours is in the foundation, which also positions us for Gulf-region expansion where GCC-adjacent delivery work increasingly lives.

Honestly incomplete: message-catalogue translation — the actual translated strings across every surface — is a rolling content effort, documented as such in our engineering runbooks, and the AI analysis output is English-first today. So the truthful formulation is: the platform is internationalisation-complete and localisation-in-progress. For your scenario, that means a Hindi- or Japanese-speaking analyst gets correctly formatted, correctly negotiated, correctly directed interfaces now, with translated content expanding by demand — and Enterprise design partners get to vote on which locale’s catalogue completes first.

The sequencing logic is deliberate: boardroom English is the lingua franca of our first buyer — GCC leadership and MNC boards — so full localisation is an expansion accelerant rather than a launch blocker. Building the i18n substrate first means adding a language is content work, not engineering work; that is the difference between a checkbox and an architecture.