Localize your Logto sign-in experience with OIDC ui_locales
Make your sign-in experience feel native to every user. In this tutorial, you’ll learn how to use the standard OIDC parameter ui_locales to set the runtime language of Logto’s sign-in UI and related emails.
CharlesDeveloper
Stop wasting weeks on user auth
Launch secure apps faster with Logto. Integrate user auth in minutes, and focus on your core product.
Logto already supports multi-language content and auto-detection, but there are times you want to explicitly pick the language for a specific interaction:
Multi-organization products with different language preferences per org
Deep links from campaigns in a specific language
Product pages with localized CTAs that start sign-in in the same language
A/B tests for localized onboarding
Besides, ui_locales is a standard parameter supported by many identity providers and SDKs.
Logto SDKs let you pass extra OIDC parameters during sign-in. Add ui_locales in extraParams:
Notes:
Provide a space-separated list of BCP 47 tags. Logto will pick the first tag that exists in your tenant’s language library (e.g., fr-CA, otherwise fr, otherwise en).
Works per interaction—your tenant’s default language is not changed.
You can combine ui_locales with other standard/custom parameters (e.g., login_hint, organization_id, or first screen directives).
When an interaction triggers an email (e.g., verification code), Logto resolves language in this order:
ui_locales (first supported tag)
Otherwise auto detects via HTTP Accept-Language header
Otherwise tenant default language
Then Logto tries to find a custom email template that matches the resolved language and template type; if none is found, it falls back to the connector default.
Provider-managed templates (e.g., Postmark, HTTP Email): Logto passes both uiLocales and locale to your provider. If ui_locales is present, locale uses the first supported tag from ui_locales.