Skip to content

Fix translations for sites with an explicit lang#221

Open
mynetx wants to merge 1 commit into
statamic:4.xfrom
mynetx:fix/multisite-lang-translations
Open

Fix translations for sites with an explicit lang#221
mynetx wants to merge 1 commit into
statamic:4.xfrom
mynetx:fix/multisite-lang-translations

Conversation

@mynetx

@mynetx mynetx commented Jul 4, 2026

Copy link
Copy Markdown

When generating a multisite install, the generator sets the app locale to the site's short locale. Statamic's own Localize middleware uses the site's lang instead, which falls back to the short locale when not explicitly set.

So a site configured with an explicit lang — e.g. locale de_CH, lang de_CH, with translations in lang/de_CH.json — renders fine when served normally, but during a static build Laravel looks for de.json and the raw translation keys end up in the generated HTML.

This makes the generator match the middleware and use $site->lang(). Sites without an explicit lang behave exactly as before.

This also explains #166: when the short-locale lookup misses the site's translation files, Laravel serves the fallback locale's strings instead — so pages come out in the wrong language (or a mix, when only some keys fall back) rather than as raw keys. Reproduced on 4.x with a fr_FR site and PHP lang groups: the live site renders the French strings, the static build renders the English fallback. With this fix the static build matches the live site.

Fixes #202
Fixes #166

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@mynetx
mynetx force-pushed the fix/multisite-lang-translations branch from 7e82c59 to a18da66 Compare July 6, 2026 08:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Translation Keys Not Replaced in Static Output Translate tag picks the wrong language when using multisite

1 participant