Web app localization at scale: what it means for identity UX

TL;DR: Web app identity surfaces can be internationalised quickly without treating translation as a separate project, according to WorkOS. WorkOS describes how it localized AuthKit into 90 languages in five weeks by combining extracted strings, FormatJS, accept-language negotiation, and LLM translation workflows, showing how quickly web app identity surfaces can be internationalised without treating translation as a separate project. The deeper lesson is that identity UX now extends into localisation, where governance failures show up as broken trust, inconsistent sign-in flows, and unmanaged text drift.

NHIMG editorial — based on content published by WorkOS: LLMs are très bien at localization

By the numbers:

• We translated AuthKit into 90 languages in 5 weeks.
• The article notes that there are 183 assigned two-letter general language codes alone.
• WorkOS says it used real traffic data to narrow support to 90 language tags.

Questions worth separating out

Q: How should teams implement localization for identity flows without creating security drift?

A: Start by extracting every user-facing string in sign-in, sign-up, recovery, and transactional email flows into a governed translation workflow.

Q: Why do localized identity experiences matter for IAM programmes?

A: Because identity screens are where users decide whether a flow feels trustworthy and usable.

Q: What breaks when identity strings are not managed centrally?

A: Unmanaged strings are easy to miss during development, which leaves English-only labels, inconsistent error messages, and untranslated fallback text in production.

Practitioner guidance

• Inventory every user-facing identity string Extract labels, placeholders, error messages, emails, and helper text from sign-in, sign-up, recovery, and account-management flows before translating anything.
• Negotiate locale from request signals Use accept-language and explicit user settings to resolve the best supported locale, then define deterministic fallbacks for unsupported variants.
• Build locale-specific UI QA into release gates Check right-to-left rendering, chevron direction, font coverage, and button overflow in every supported language before shipping.

What's in the full article

WorkOS's full how-to covers the implementation detail this post intentionally leaves for the source:

• The exact FormatJS setup used to extract and manage identity strings across a React codebase.
• The prompt pattern the team used to help an AI agent replace raw JSX strings with translation components.
• The handling of browser locale signals, fallback language behaviour, and translation IDs in production.
• The specific checks used for right-to-left layouts, font support, and button overflow across supported locales.

👉 Read WorkOS's guide to localizing AuthKit across 90 languages →

Web app localization at scale: what it means for identity UX?

Explore further

View Full Forum →  |  NHI Foundation Course →