Skip to content

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.

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

For collection entries:

SettingBehaviour
localizable: falseThe field is locked to the origin value. A localized row should not carry an independent value for that field.
localizable: trueA 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 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:

SettingPractical effect
localizable: falseThe field is hidden or disabled for non-default sites, which can lock editors out of maintaining site-specific values.
localizable: trueEditors 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 need extra care. If the parent field is localizable, a localized variant can override the whole array, not only the nested text fields.

StructureNon-localizable parentLocalizable parent
Simple fieldShared from originCan be overridden per site
Grid or replicatorWhole array is sharedWhole array can diverge per site
Nested fieldControls values inside the shared arrayControls 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.

CategoryUsually localizable?Examples
Translated copyYesTitles, leads, body text, button labels, SEO text
Language-specific URLYesLocalized internal page paths
Language-specific documentYesDE, FR, and IT statutes PDFs
Shared factual dataNoDates, vote result, sort order
Shared relationsUsually noAuthors, member groups, taxonomy relations
Shared visual or layout configUsually noColours, icons, section type, images, toggles
Technical provider configUsually noCalendar IDs, Payrexx URLs, SmartVote IDs
Person or object identityUsually noMember name, working name, canonical media kit name
CollectionLocalisation model
PostsTranslate 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.
PublicationsTranslate copy, slug, SEO, icon-box text, and attachment labels. Keep thumbnail, categories, authors, icon choices, and sort order shared.
PagesThe sections replicator is localizable, so translated pages can override the whole page structure. Keep structure aligned unless the translated page needs a different layout.
VotesTranslate title, reason, and slug. Keep date, result, and related post shared.
MembersTranslate function, sub-lines, bio, and slug. Keep portrait, groups, email, phone, and social URLs shared.
Member groupsTranslate title and slug.
Media kitsTranslate visitor-facing module text and button labels. Keep downloadable files and visual choices shared unless a language-specific asset is needed.

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.