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
{{ message }}
Repository navigation
i18n lint fails on main, so every content PR shows a red check it did not cause #652
hack/check-i18n.sh exits 1 on a clean checkout of main, so the i18n lint workflow fails on every pull request that touches content/** — including pull requests that change nothing about translations.
Reproducing it
git worktree add --detach /tmp/wsmain origin/main
cd /tmp/wsmain && ./hack/check-i18n.sh;echo"exit=$?"
Exit code is 1 and the output carries four ::error::stale translation lines, all for the same English source:
The recorded digest is sha256:6f37e3e1… and the current one is sha256:2d13272f…, for the de, ru, zh-cn and one further translation of that post.
Mechanism
The English source was edited by 4b5d1ad ("chore(blog): repair front matter, links and bundle names"), which is an ancestor of main. Editing an English page changes its digest, so every recorded translation digest for that page goes stale until either the translations are refreshed or the digests are updated.
.github/workflows/i18n-lint.yml runs on pull_request with paths: content/**, so any content change picks up a red check for a break it did not introduce. The same workflow also runs on push to main, which is where this first became visible.
Impact
Every content pull request currently shows a failing required-looking check, and the failure names files the author never touched. The cost is not the red mark itself — it is that a genuinely stale translation introduced by a later pull request is indistinguishable from this pre-existing noise, so the check stops carrying information exactly where it was supposed to.
Fix shape
Two halves, and they are not interchangeable.
The honest fix is to refresh the four translations against the current English source and then run hack/check-i18n.sh update-digests, which is what the script's own hint tells the author to do.
Running update-digests alone would turn the check green while leaving the translations stale — it records that the current state is approved. That is available as a deliberate decision if the edits in 4b5d1ad were cosmetic enough not to affect the translated text, but it should be taken knowingly and said out loud in the commit, not reached for because it is the one-line option.
Still reproducing, and here is one measurement the issue does not carry: whether this actually blocks anything.
Run today on a throwaway worktree checked out at origin/main257bbbbe, with nothing else in it, hack/check-i18n.sh exits 1 with four ::error::stale translation lines, for content/de/_index.md, content/hi/_index.md, content/ru/_index.md and content/zh-cn/_index.md, all against content/en/_index.md.
The part worth adding: i18n-lint is not a required check. Branch protection on main requires exactly DCO plus one approving review, so a content PR showing this red is merge-blocked by its review, never by this. Good to know before someone treats a red check as a gate and starts refreshing digests inside an unrelated PR.
That does not make it harmless. A check that is red on every content PR for a reason none of them caused is a check people stop reading, and the next real i18n regression arrives into an audience already trained to scroll past it.
The cause is narrower than "four stale translations", which makes the fix one command rather than a translation pass.
content/en/_index.md was changed in 480d6daa without a following hack/check-i18n.sh update-digests, so the recorded digest for that file no longer matches its content and all four locales that reference it report stale. The digest is sha256:24e38da4… on record against sha256:e8f982c2… for the file as it stands.
So the four errors are one omission seen four times, not four translations that drifted. Running hack/check-i18n.sh update-digests on main clears it, assuming the translations themselves are still adequate for the English text as changed. If that change altered meaning rather than wording, the translations need a pass first and the digest refresh comes after; if it did not, the refresh alone is the whole fix.
Activity
lexfrei commentedon Sep 7, 2026
Still reproducing, and here is one measurement the issue does not carry: whether this actually blocks anything.
Run today on a throwaway worktree checked out at
origin/main257bbbbe, with nothing else in it,hack/check-i18n.shexits 1 with four::error::stale translationlines, forcontent/de/_index.md,content/hi/_index.md,content/ru/_index.mdandcontent/zh-cn/_index.md, all againstcontent/en/_index.md.The part worth adding:
i18n-lintis not a required check. Branch protection onmainrequires exactlyDCOplus one approving review, so a content PR showing this red is merge-blocked by its review, never by this. Good to know before someone treats a red check as a gate and starts refreshing digests inside an unrelated PR.That does not make it harmless. A check that is red on every content PR for a reason none of them caused is a check people stop reading, and the next real i18n regression arrives into an audience already trained to scroll past it.
lexfrei commentedon Sep 7, 2026
The cause is narrower than "four stale translations", which makes the fix one command rather than a translation pass.
content/en/_index.mdwas changed in480d6daawithout a followinghack/check-i18n.sh update-digests, so the recorded digest for that file no longer matches its content and all four locales that reference it report stale. The digest issha256:24e38da4…on record againstsha256:e8f982c2…for the file as it stands.So the four errors are one omission seen four times, not four translations that drifted. Running
hack/check-i18n.sh update-digestsonmainclears it, assuming the translations themselves are still adequate for the English text as changed. If that change altered meaning rather than wording, the translations need a pass first and the digest refresh comes after; if it did not, the refresh alone is the whole fix.docs(networking): GatewayClass selection, edge TLS mode, and the Clou…