Localized

Occasionally, we want to have the option to add multiple languages in one input text field. This means that you can store Dutch, French or English text in one field and the right language will appear based upon the language you chose in the environment (called user language).

Make the field localized

Add the localized:true attribute to a text input, adding the localized attribute to any other input types will throw a liquid error.

For example:

{% input custom.some.thing localized:true %}
{% input custom.some.thing as:text localized:true %}

To print the localized variable:, you can use the filter | localized:

{{ custom.some.thing | localized }}

Specifications

Adding localized:true to an input field ensures that a suffix is added to the variable name. This suffix follows the locale , which is toggled by selecting different user languages.
For instance, when selecting Dutch as user language _nl is added after the variable. In our example, custom.some.thing becomes custom.some.thing_nl.

Due to adding the suffix in the background you should always assign the localized field to a local variable when using the localized field in further logic. If not, you will still look for the local variable without the suffix.

{% assign localized_field = custom.some.thing | localized %}

Access a localized value

When a value is entered into a localized field, it is automatically stored as the default value in the unlocalized variable (e.g., custom.some.thing). This process is known as the fallback procedure. If other localized fields (e.g., custom.some.thing_nl, custom.some.thing_fr, custom.some.thing_en) do not have their own specific values, they will use this default value as a fallback.

The first localized field where you enter a value determines this default. For example, if you enter a value in custom.some.thing_fr first, that value is saved as the default and will be used as the fallback for all other localized fields unless those fields are explicitly given their own values.

If you delete the value in the first field where the value was entered, the default value will also be removed. As a result, any other localized fields relying on the fallback will lose their values. However, if you delete the value in another localized field (not the default), it will only affect that specific field, and the default value will still be applied to the others.

Because of this fallback mechanism, it’s important to always ensure a fallback exists, either through the unlocalized variable (custom.some.thing) or a defined localized value. This is especially crucial if the field was filled in before introducing localized logic, as the fallback ensures consistent behavior across all languages.

When you assign the localized variable, you have to make sure that the localized filter is directly after the custom and not after the default. Otherwise, liquid will try to localize the default and this will throw a liquid error.

{% assign localized_field = custom.some.thing | *localized* %}
{% result 'result_localized_field' localized_field %}

{% assign note_title = period.reconciliations.vkt_6_5.results.result_localized_field %}