> ## Documentation Index
> Fetch the complete documentation index at: https://docs.frontic.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Locales

A **locale** is a language the project supports. The locale catalog lives at the project level — it's the list every [region](/project-settings/regions) can pick from when declaring which languages to serve. A locale is identified by a short key (`en`, `de`, `fr-CA`) used in API responses and translation lookups.

Translatable fields on [Data Storages](/data-integration/data-storages) and [Blocks](/api-builder/blocks) store one value per locale. When a request resolves to a specific locale, the matching translation comes back; if the translation is missing, the region's default locale applies as a fallback.

## Configuring locales

Open **Settings → Locales** and add the languages your project supports. Each locale has:

* **Name** — human-readable label like "English" or "German".
* **Key** — the stable identifier (ISO 639-1 codes like `en`, `de`, or BCP-47 tags like `fr-CA` when you need to distinguish regional variants). Set on creation and locked afterwards — translations are stored against the locale's identity, so renaming would orphan them. To change a locale's key, delete and re-add the locale.

<Screenshot name="project-settings/locales-list" caption="Locales list — the project's language catalog" alt="Project Settings Locales page listing English, German, and Spanish with their keys" />

## Catalog vs. region support

The project locale catalog is the **master list**; regions pick a subset:

1. Add every language the project might ever serve to the catalog (e.g. `en`, `de`, `fr`, `es`).
2. On each [region](/project-settings/regions), enable the locales that region supports and mark one as the default.
3. A request bound to a region can only return translations for the locales that region allows.

Don't leave unused locales lying around. Every locale in the catalog has to be mapped in each [Data Sync](/data-integration/value-composer) and is rendered into every translatable response, so an unused locale adds work to the data pipeline without serving any traffic. If a region has stopped supporting a locale, drop it from the project catalog too.

## When to add a new locale

Add a locale when you're about to ship content in that language. Common triggers:

* A new market opens that needs its own language (expanding into France → add `fr`).
* A regional variant diverges enough to need its own strings (`fr-CA` for Canadian French where the copy reads differently from mainland French).
* Your translation team finishes a pass and you're ready to activate that language on a region.

Keep the catalog tight. Each extra locale multiplies the translation work across every translatable field; remove unused ones before they gather dust.

## Related

<CardGroup cols={2}>
  <Card title="Regions" icon="earth-americas" href="/project-settings/regions">
    Pick which of the catalog locales apply in each market, with a default per region.
  </Card>

  <Card title="Domains" icon="globe" href="/project-settings/domains">
    Bind URL paths like `demo-shop.com/de` to a specific locale at routing time.
  </Card>

  <Card title="Multi-channel & region" icon="sitemap" href="/commerce-concepts/multi-channel-region">
    The full commerce-native composition of scopes, regions, locales, and domains.
  </Card>
</CardGroup>