Topic starter
07/06/2026 9:14 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “LLMs are très bien at localization”.
Key questions
Q: How should teams localise sign-in and sign-up flows without breaking the user experience
A: Treat locale selection, translated strings, text direction, and font support as one identity experience.
Q: Why do localisation projects often fail in identity screens even when translation quality is high
A: Identity screens depend on more than language.
Q: What are the best practices for extracting text from web app identity components
A: Search for hard-coded strings in JSX, default props, metadata, and helper functions, then move them into translatable resources with stable IDs and descriptions.
Practitioner guidance
- Define a single locale resolution path Use one locale-selection mechanism for sign-in pages, app chrome, transactional emails, and API-facing messages so every identity touchpoint resolves the same preferred language and fallback order.
- Extract every user-facing string Move labels, placeholders, error text, tooltips, and email content into translatable resources so developers stop shipping hard-coded identity messages in component code and default parameters.
- Test right-to-left identity flows Validate chevron direction, layout spacing, and font coverage in RTL locales before release, because sign-in and recovery screens fail visibly when directional assumptions are wrong.
Bottom line: Localization changes identity UX from a single-language assumption into a governed multi-locale operating model.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
08/06/2026 9:06 am
Identity UX is now a governance surface, not just a design surface: Once sign-in and sign-up flows are localised, the organisation is governing how identity itself is experienced across languages, not merely translating copy. That shifts localisation into the same control plane as authentication consistency, error handling, and trust signalling. The practical conclusion is that identity teams need to treat language coverage as part of user access design.
A few things that frame the scale:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What should product teams do when translated labels overflow identity UI controls
A: Identify the controls most likely to break under longer translations, such as buttons, input labels, and recovery prompts, then redesign those components for variable text length. Teams should measure the longest expected strings, review them in target locales, and reserve room for scripts that expand more than English.
👉 Read our full editorial: LLM-assisted localization widens identity UX complexity in web apps
This post was modified 4 days ago by NHI Mgmt Group