A Localized String is a text property that holds a separate value for each language your tenant supports. Use it for anything an end user reads and that should change with the interface language — a product name, an article title, a category label.

It's a distinct property type, chosen when you design the model. A plain String stores one value, full stop. A Localized String stores one value per language — for example Title = "Benvinguda" in Catalan and "Welcome" in English, on the same instance.

How the value works

A Localized String carries every language at once:

  • The tenant's default language is the canonical rendition. It's the one shown when no other language applies, and it's required — an instance can't have a Localized String with only a non-default translation.
  • Each supported language can have its own text. Languages you leave empty simply have no entry; the reader falls back to the default.
  • When someone switches the view language, the matching rendition appears immediately. Nothing is fetched again — all languages travel together with the instance.

So a Title set to "Welcome" (en) / "Benvinguda" (ca) / "Bienvenida" (es) shows the right word the instant the reader flips their language, with no reload.

Editing a Localized String

The editor shows a single field for the active view language, labelled with its code (for example Title (EN)). Type there to set the value for that language.

Next to the field is a 🌐 button. It opens a dialog with one field per supported language, so you can fill or revise every translation in one place. Leave a language blank to remove its rendition; the default language must keep a value.

Filtering

When you filter a list on a Localized String, the match runs across all languages — it's an OR. Searching Title for "welcome" finds the instance whether "welcome" is in the English text, the Catalan text, or any other language. You don't have to know which language a value was entered in to find it.

Localized String vs String

Pick the type by what the field is, not by whether you happen to be multilingual today.

Use String when… Use Localized String when…
The value is the same in every language. The value is human-facing prose that should be translated.
It's a code, slug, identifier, URL, or email. It's a name, title, label, or description users read.
It's internal and never shown translated. The interface language should change what the reader sees.

A String is lighter and simpler — keep using it for codes and machine-facing text. Reach for a Localized String only where translation genuinely matters; you can't filter or validate a String "per language" because it has only one value, and you don't want that overhead where it buys nothing.

Where to find it

When you add or edit a property on a model, pick Localized String as its type. From then on, every instance form renders the localized editor described above, and the supported languages come from your tenant's language settings (see Tenants).