Skip to content

Platform / Multilingual

Multilingual from the ground up,
not a plugin.

Per-site locales, translated content and products across ~40 locales, language-aware Elasticsearch, and localized pricing and checkout. Built into the platform, not bolted on.

nimbu ~ locales
# add locales to a site
$ nimbu locales add fr nl de
3 locales added. Content fields are now translatable.
# pull translations for review
$ nimbu translations:pull --locale fr
48 entries pulled to translations/fr.yml

Native locales, not a translation layer on top

Each site declares the languages it serves. Channels and Custom Fields carry translations field by field. A localized field holds one value per locale, so a title, a body and a slug each have their own French and Dutch. There is no parallel content tree to keep in sync.

  • Per-site locale configuration Declare the languages your site serves. One config, not one instance per language.
  • Localized fields per content type Each field is translatable independently. Shared fields stay shared; translatable fields hold one value per locale.
  • URL localization built in Each locale gets its own URLs so search engines and visitors land on the right language.
  • Per-language publication states Publish Dutch when it is ready without holding up French that is still in draft.
theme/product.liquid
# product name resolves to the active locale
$ {{ product.name }}
# iterate all locale alternate links
$ {% for locale in site.locales %}
$ <link rel="alternate" hreflang="{{ locale.code }}"
$ href="{{ page.url | localized: locale }}">
$ {% endfor %}

Translated products and checkout, not just translated pages

Product names, descriptions and option values are localized per locale. Pricing schemes and currencies resolve per market. A French visitor sees French copy and the right price. Checkout follows the customer's locale through to confirmation, with gateway, emails and order detail in the language they shopped in.

  • Localized product names and descriptions Names, descriptions and option values each hold a value per locale.
  • Pricing and currencies per market Each locale resolves the right pricing scheme and currency without a separate shop.
  • Checkout in the customer's language Gateway, confirmation email and order detail all follow the locale through to the end.
nimbu ~ translations
# pull product translations for a locale
$ nimbu products translations:pull --locale fr
124 product entries pulled to translations/products/fr.yml
# review, edit, then push
$ nimbu products translations:push --locale fr
124 entries pushed. Shop now speaks French.

Search

Search that knows which language it is searching

Nimbu runs language-aware Elasticsearch with an analyzer per locale. Each language is indexed and queried on its own terms. Stemming, stop words and relevance all change by language. The shopper finds the product in the language they are using, and you do not ship a search box that only performs in one market.

  • Analyzer per locale Dutch stemming for Dutch queries, French stemming for French. One index, many analyzers.
  • Translated products are searchable Localized product content is indexed in the language the visitor is using.
  • Relevance reflects how each language works Stop words, stemming and scoring rules match the locale.
search query
# locale-aware query: each language analyzed separately
$ GET /search?q=schoenen&locale=nl
{ hits: 34, locale: 'nl', analyzer: 'dutch' }
$ GET /search?q=chaussures&locale=fr
{ hits: 31, locale: 'fr', analyzer: 'french' }

How a translator works without waiting on a developer

Translation is a content job. On Nimbu it stays that way.

The developer sets the model once. After that, the people who own the words add languages and keep them current.

  • Edit in context A translator opens the site in the target locale and edits translated values directly, with page copy, product fields and menu labels alongside the source language for reference.
  • Shared and localized fields side by side Fields that should never differ by language stay shared. Fields that should differ are editable per locale. No guessing which is which.
  • Publish per language Publication is per language. A translator can finish and publish French without touching the live Dutch site or filing a deploy request.

The full multilingual stack, in one platform

No translation app, no second instance, no content-only workaround that stops at the product page.

  • Per-site locale configuration

    Each site declares the languages it serves. No separate instance per language.

  • Localized content fields

    Channels and Custom Fields carry translations field by field. ~40 locales supported.

  • URL localization

    Each locale gets its own URLs. Search engines and visitors land on the right language.

  • Per-language publication states

    Publish Dutch when it is ready. French can stay in draft until the translation is done.

  • Translated products and option values

    Product names, descriptions and option values localized per locale.

  • Localized pricing and checkout

    Pricing schemes and currencies resolve per market. Checkout stays in locale through confirmation.

  • Language-aware Elasticsearch

    An analyzer per locale. Stemming and relevance reflect how each language works.

  • CLI-driven translation workflow

    Pull, edit and push translations from the command line. Works with any agent.

In practice

We run one NL/FR/DE shop instead of three. Translated pricing was the part every other platform got wrong. Here it is just how the model works.

E-commerce lead, Zenjoy

Build one multilingual site, the honest way

Per-site locales, translated commerce across ~40 locales, and language-aware search. All in the platform, not a plugin you re-audit each cycle.