You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm running a Czech site and adding an English version. Instatic handles this fine
structurally — pages are just routes, so the EN version lives as a parallel tree
under /en/… with its own layout variant and a CS/EN switcher link.
What can't be expressed today is the language metadata:
The language site setting is a single site-wide value
(src/core/page-tree/siteSettings.ts), rendered into <html lang="…"> for every
published page (src/core/publisher/render.ts). My /en/* pages are served with lang="cs", which is wrong for accessibility (screen reader pronunciation) and
a negative signal for SEO.
There is no way to declare that two pages are translations of each other, so the
publisher never emits <link rel="alternate" hreflang="…"> pairs. Search engines
see the CS and EN pages as unrelated (and potentially duplicate) content.
Proposal
Two additive pieces, no i18n framework needed:
Per-page language override. An optional language field in page settings that
wins over the site-wide setting for that page's <html lang>. Empty = inherit,
exactly like today.
Translation linking. A way to mark page B as the <lang> counterpart of
page A (a per-page "translations" mapping, or a shared translation-group key).
At publish time, each page in a group emits <link rel="alternate" hreflang="…">
for every member plus itself, and optionally x-default for the site's default
language.
Both are metadata-only and fit the existing static bake — nothing becomes
request-dependent, and sites that never touch the fields publish byte-identical
output.
Out of scope (deliberately)
Content synchronization, translation workflows, or locale-prefixed routing helpers.
Maintaining parallel page trees manually is acceptable; it's only the emitted
metadata that can't be worked around from inside the editor today.
Current workaround
Parallel /en/* pages with a duplicated EN layout — works, but ships an incorrect lang attribute on every EN page and no hreflang pairs.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Problem
I'm running a Czech site and adding an English version. Instatic handles this fine
structurally — pages are just routes, so the EN version lives as a parallel tree
under
/en/…with its own layout variant and a CS/EN switcher link.What can't be expressed today is the language metadata:
languagesite setting is a single site-wide value(
src/core/page-tree/siteSettings.ts), rendered into<html lang="…">for everypublished page (
src/core/publisher/render.ts). My/en/*pages are served withlang="cs", which is wrong for accessibility (screen reader pronunciation) anda negative signal for SEO.
publisher never emits
<link rel="alternate" hreflang="…">pairs. Search enginessee the CS and EN pages as unrelated (and potentially duplicate) content.
Proposal
Two additive pieces, no i18n framework needed:
Per-page language override. An optional
languagefield in page settings thatwins over the site-wide setting for that page's
<html lang>. Empty = inherit,exactly like today.
Translation linking. A way to mark page B as the
<lang>counterpart ofpage A (a per-page "translations" mapping, or a shared translation-group key).
At publish time, each page in a group emits
<link rel="alternate" hreflang="…">for every member plus itself, and optionally
x-defaultfor the site's defaultlanguage.
Both are metadata-only and fit the existing static bake — nothing becomes
request-dependent, and sites that never touch the fields publish byte-identical
output.
Out of scope (deliberately)
Content synchronization, translation workflows, or locale-prefixed routing helpers.
Maintaining parallel page trees manually is acceptable; it's only the emitted
metadata that can't be worked around from inside the editor today.
Current workaround
Parallel
/en/*pages with a duplicated EN layout — works, but ships an incorrectlangattribute on every EN page and no hreflang pairs.All reactions