fix(seo): let the site language decide og:locale and inLanguage - #647
Merged
Conversation
Sites scaffolded from this template inherit a hardcoded `en_US` / `en-US`, which Hinode reads as a single site-wide value. Add a second language and every page of it reports the locale of the first one — valid markup that quietly contradicts the `lang` attribute beside it, so nothing in the build says anything is wrong. It is the path by which the bug fixed in gethinode/hinode#2143 reaches real sites. Comment both out so the theme decides. Output here is unchanged: this site is English with `languageCode = "en-us"`, which the theme resolves back to `en_US` either way. It starts to matter the moment a second language is added, which is exactly when the old default used to fail silently. Inert until a Hinode release carrying #2143 is picked up; until then the theme's own default supplies the same value, so this can land in any order. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
✅ Deploy Preview for gethinode-template ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Companion to gethinode/hinode#2143, which fixes
og:localeand the JSON-LDinLanguagereporting one site-wide value for every language. This is the repo through which that bug reaches real sites.Why this matters here
config/_default/params.tomlships hardcoded values:Every site scaffolded from this template inherits them. Add a second language and each of its pages reports the locale of the first — a Dutch page serving
<html lang="nl">next to<meta property="og:locale" content="en_US">. The markup is valid and the build is silent; only the two tags disagree, which is why it survives unnoticed. Found on a bilingual production site that had carrieden_USon its Dutch tree since launch.Project configuration wins over the theme by design, so hinode#2143 alone does not reach any site scaffolded from here — these two lines would keep shadowing the derivation. That is what this PR removes.
Change
Both are commented out rather than deleted, so they stay discoverable as the escape hatch when a guess is wrong.
Verification
Built with the currently pinned hinode v3.20.0, i.e. before the fix is released:
og:localeen_USen_USinLanguageen-USen-USUnchanged, because the theme's own default supplies the same value today, and once #2143 releases this site is English with
languageCode = "en-us", which the new derivation resolves back toen_US. So there is no ordering constraint — this can merge before or after that release, and the scaffold's own output never moves. The change only starts to matter when a user adds a second language, which is precisely the case that used to fail silently.npm testpasses.🤖 Generated with Claude Code