Skip to content
Personalization

Localization

Deliver flow content in your users' native language with multi-language support.

Localization

Setgreet supports multi-language flows so your in-app experiences reach users in their native language. You create a flow once in your default language, then add translations for any additional languages you need -- without duplicating the flow.

How localization works

The base language of every flow is English (en-US) -- this is the content you write in the flow editor when you first build the flow. Localizations are stored as translation layers on top of the base content: for each additional language, you provide translated values for the text properties across the flow.

When the SDK renders a flow, it checks the device locale and selects the matching translation. If no translation exists for the device locale, the English base content is shown.

Adding a localization

  1. Open a flow in the flow builder.
  2. Open the flow menu in the top bar and click Localization.
  3. In the Localization modal, click Add Language and choose a target language.
  4. Enter translated content for each text field across all screens in the flow (titles, body text, button labels, input placeholders, option labels).
  5. Save to apply the translations.

Each additional language appears as its own column alongside the base language, so you can translate every screen's content in one place.

Setgreet supports 100+ languages. The language list uses standard locale codes (e.g., en, es, fr, ja, de, pt-BR).

What gets localized

Localization applies to all text-based component properties:

ComponentLocalizable properties
Text, Title, SubtitleText content
ButtonLabel text
TextInputPlaceholder text
DropdownPlaceholder and option labels
RadioGroupOption labels
CheckboxOption labels
MultiSelectOption labels
NPSLabels and prompts
RatingLabels

Non-text properties like colors, sizes, layout settings, and images are not localized -- they stay the same across all languages.

Language detection

The SDK automatically detects the user's device language and matches it to available localizations:

  1. The SDK reads the device locale (e.g., es-MX).
  2. It looks for an exact match in the flow's localizations.
  3. If no exact match is found, the flow renders in the base language (English, en-US).

You do not need to write any code for language detection. The SDK handles it automatically.

The SDK currently does exact-match matching only. If a user's locale is es-MX and only es is available (or vice versa), the flow falls back to the base language. Add the specific locale codes your users have to guarantee a match.

Base language and fallback

English (en-US) is the base language of every flow. It is the content you build in the flow editor before adding any translations. The base language is always used when no translation matches the user's device locale.

Fallback happens in two places:

  • Locale not translated -- if there is no translation for the user's locale on a screen, the entire screen renders in the base language.
  • Missing translation within a locale -- if a specific text property was not translated for a locale (for example, a button label was skipped), that individual property renders in the base language while the rest of the translated content is shown.

This means partially translated screens still render correctly -- untranslated properties show the original English text rather than blank content.

When you edit the base (English) content of a screen after adding translations, the stored translations do not update automatically. Because translations are keyed by component and property, the old translated value will still override the new base text until you edit it in each language. Review all translations whenever you change original content.

Variable bindings in localized text

Localization and variable bindings work together. When you translate a screen, include the same binding expressions in your translated text:

English (base):

Welcome back, {{user.firstName}}!

Spanish translation:

Bienvenido de nuevo, {{user.firstName}}!

Japanese translation:

おかえりなさい、{{user.firstName}}さん!

The SDK resolves the binding expressions after selecting the appropriate language, so the user sees their name in the correctly localized sentence.

Best practices

  • Start with your primary language. Build and test the entire flow in your default language first. Add translations once the content is stable.
  • Use a consistent base language. Pick one base language across all flows (typically English) to keep your workflow predictable.
  • Translate all screens in a flow. A flow where some screens are translated and others are not creates a jarring experience.
  • Account for text length. Translations often differ in length. German text is typically longer than English; Japanese may be shorter. Preview your screens in each language to check for overflow or awkward spacing.
  • Keep binding expressions identical. When translating, copy the {{source.path}} expressions exactly. A typo in a binding expression means the value will not resolve.
  • Update translations when base content changes. There is no automatic sync between base content and translations. When you edit the original text, review all language versions.

On this page