Translation variants

Main holds the default content. A named variant supplies different text for the keys and languages that need an override. Missing variant content falls back to Main for the same message, so you do not need to duplicate an entire catalog.

Use languages for language differences, plurals for quantity-dependent grammar, and variants for audience-specific wording. A variant can still contain different values in each project language.

1. Create a variant option in the project settings with a name that identifies its audience or use case.
2. Edit the variant values for the keys and languages that should differ from Main.
3. Review overridden messages together with the Main values that provide fallback.
4. Publish the reviewed keys and verify the selected variant in an application.

Use the variant identifier expected by your installed SDK. Keep the app configuration aligned with the project option rather than assuming a display label is interchangeable with an identifier.

Supported SDKs accept variant selection during setup and expose runtime variant controls. Follow the version-specific package reference for the selection API and persistence behavior. Switch at the point where the app knows the user brand, plan, or experiment assignment.

1. Check the default Main experience without a selected override.
2. Check a key with variant content and another key that intentionally falls back to Main.
3. Repeat in the languages your app exposes, including a locale with missing variant text.
4. Switch variants while the app is open and confirm that existing UI refreshes correctly.

• Variant examples and workflow