Localization

The fulfillmenttools platform supports localization, enabling you to manage data in multiple languages. This document outlines how to change user and platform locales, request specific languages for your requests, and handle localized information in entities.

Supported Localization Features

  • User-specific locales: Determined by user settings in the authentication token.

  • Request-specific languages: Can be specified using a locale query parameter.

  • Localized entity fields: Store and retrieve localized field values.

Supported Languages

A list of currently supported languages can be found via the API. All supported languages are also available in the Backoffice and other fulfillmenttools applications.

Requesting Specific Languages

To request data in a specific language, add the locale query parameter followed by the language code, conforming to the ISO 639-1 standard.

Example request for a specific language

GET /api/endpoint?locale=de_DE

Fallback Language Mechanism

If a requested language is unavailable, the platform uses the following fallback order:

  1. Language specified in user settings.

  2. Default platform language.

  3. English (en_US).

  4. First available language for the entity.

  5. Non-localized field value of the entity.

Handling Localized Information in Entities

Each localizable entity schema contains fields and their corresponding localized versions, which are stored as objects with locale codes as keys.

Example of localized entity fields

{
  "title": "My Product",
  "titleLocalized": {
    "de_DE": "Mein Produkt",
    "fr_FR": "Mon produit",
    "nl_NL": "Mijn product"
  }
}
  • GET requests return localized values based on the user's locale.

  • POST, PUT, and PATCH requests must provide all localized values for the desired locales. Partial updates of localized values are not supported.

Using Entities Without Localization

The platform will prioritize returning localized values based on the user's locale. If a non-localized field is patched when a localizedObject is already present, the original field will always be overridden with the localized values in responses.

If localization is not required, omit the <fieldName>Localized object and provide the non-localized field directly.

Example of non-localized usage

{
  "title": "My Product"
}

Changing the User Locale

To change the user locale, send a PATCH request to the user endpoint, including the new locale in the request body. After the change, you must request a new authentication token to reflect the locale update.

Changing the Default Platform Locale

The default platform locale sets the standard language for the frontend applications. Change it by sending a PUT request to the relevant configuration endpoint.

Last updated