Localisation

Multisite and localisation are related, but they are not the same control.

• Multisite creates separate Statamic sites such as de, fr, it, be_de, and be_fr.
• Localisation is the field-level blueprint setting that decides whether a field can be overridden per site.

The most important rule is that localizable: true means a field may be overridden per site. It does not mean every localized variant already has a complete translation.

Collection Entries

Collections such as posts, publications, pages, members, media kits, votes, and member groups are configured around propagated entries.

For collection entries:

Setting	Behaviour
localizable: false	The field is locked to the origin value. A localized row should not carry an independent value for that field.
localizable: true	A localized variant can carry its own value. If it does not, Statamic can fall back to the origin value.

Use non-localizable fields for shared facts, relations, canonical identity, layout decisions, and provider configuration. Use localizable fields for translated copy, localized slugs, language-specific URLs, language-specific files, and visitor-facing fields that genuinely differ by site.

Globals

Globals behave differently from collection entries. Each site has its own global record, and the localizable flag mostly controls whether the Control Panel exposes the field for editing on non-default sites.

For globals:

Setting	Practical effect
localizable: false	The field is hidden or disabled for non-default sites, which can lock editors out of maintaining site-specific values.
localizable: true	Editors can maintain the value independently for every site.

Global fields that can legitimately differ between sites should be localizable. Examples include logos, legal URLs, language-specific document assets, email addresses, and social profile URLs.

Grids and Replicators

Grids and replicators need extra care. If the parent field is localizable, a localized variant can override the whole array, not only the nested text fields.

Structure	Non-localizable parent	Localizable parent
Simple field	Shared from origin	Can be overridden per site
Grid or replicator	Whole array is shared	Whole array can diverge per site
Nested field	Controls values inside the shared array	Controls values inside a site-specific array

This is intentional for cases such as translated attachment files, but it also means page structure can diverge. Editors should keep translated page section order and section types aligned with the origin unless there is a real language-specific reason to differ.

Field Decision Guide

Category	Usually localizable?	Examples
Translated copy	Yes	Titles, leads, body text, button labels, SEO text
Language-specific URL	Yes	Localized internal page paths
Language-specific document	Yes	DE, FR, and IT statutes PDFs
Shared factual data	No	Dates, vote result, sort order
Shared relations	Usually no	Authors, member groups, taxonomy relations
Shared visual or layout config	Usually no	Colours, icons, section type, images, toggles
Technical provider config	Usually no	Calendar IDs, Payrexx URLs, SmartVote IDs
Person or object identity	Usually no	Member name, working name, canonical media kit name

Collection Notes

Collection	Localisation model
Posts	Translate title, lead, body, SEO, slug, and attachment labels. Keep release date, categories, authors, and social image shared. Attachment grids may be localized when a translated file exists.
Publications	Translate copy, slug, SEO, icon-box text, and attachment labels. Keep thumbnail, categories, authors, icon choices, and sort order shared.
Pages	The sections replicator is localizable, so translated pages can override the whole page structure. Keep structure aligned unless the translated page needs a different layout.
Votes	Translate title, reason, and slug. Keep date, result, and related post shared.
Members	Translate function, sub-lines, bio, and slug. Keep portrait, groups, email, phone, and social URLs shared.
Member groups	Translate title and slug.
Media kits	Translate visitor-facing module text and button labels. Keep downloadable files and visual choices shared unless a language-specific asset is needed.

Validation Rules

Blueprint settings make the right editorial action possible, but they do not prove data quality. Migration and publishing checks should flag:

• published localized entries with missing required visitor-facing fields;
• localized page sections whose count, order, or type differs unexpectedly from the origin;
• attachment grids that fall back to origin-language files where a translated file is required;
• internal URLs that point to a page in the wrong site or language;
• globals missing explicit per-site values for logos, legal URLs, legal assets, and social accounts;
• non-localizable facts or relations that were written with conflicting localized values.

Origin entries can be published first. Localized variants should stay unpublished until translated copy, localized URLs, localized assets, and intentional fallbacks have been reviewed.