#2855 Docs: all five locales are stranded on the pre-restructure tree, so 76-96% of translated navigation serves English

Summary

The English docs were restructured from a Diátaxis tree (tutorials/ how-to/ reference/ explanation/) into a task-based one (start/ plan/ build/ customize/ existing-codebases/ reference/). None of the five translated locales moved with it.

The sidebar is one shared slug list with per-locale label translations, so it points every locale at the English paths. Where a locale has no file at that path, Starlight falls back to the English page — and serves it under the locale's own lang attribute.

The result is the opposite of what you would expect: most of the translated content is finished and sitting on disk, while readers in those locales are served English.

What a French reader gets today

/fr/start/install-bmad/ is what the French sidebar links to. There is no docs/fr/start/install-bmad.md, so it renders:

<html lang="fr-FR">
<title>How to Install BMad | BMad Method</title>

English prose, declared as French. Meanwhile the real translation exists at /fr/how-to/install-bmad/ — complete, titled Comment installer BMad — and is not in the sidebar.

Scale

Of the 26 slugs in the sidebar, how many resolve to a real translated file:

Locale	Translated	Falls back to English
`fr`	2	24 (92%)
`cs`	1	25 (96%)
`ko-kr`	6	20 (76%)
`vi-vn`	2	24 (92%)
`zh-cn`	2	24 (92%)

And the translated pages that are not in the sidebar at all — reachable only by following in-body links from other pages in the same island:

Locale	Pages	Not in the sidebar
`fr`	29	28
`cs`	23	23
`ko-kr`	37	32
`vi-vn`	28	27
`zh-cn`	32	31

ko-kr is the only locale partway across: it has both start/ and build/ alongside the old tree.

Why this matters beyond tidiness

lang lies. Every fallback page declares a locale it is not written in. That misleads screen readers, browser translation, and search engines.
Finished work is invisible. These are complete translations that contributors wrote. Nobody can find them.
It silently gets worse. Nothing fails when a locale lacks a page — the fallback absorbs it — so the gap never shows up in CI or review.

Not a pure rename

Matching by filename, 19–27 pages per locale have no English page of that name any more. Some are genuine deletions; others were merged or renamed in the restructure (getting-started → start/build-your-first-change, quick-fixes folded into build/build-a-change). Each needs a decision, so this cannot be done with git mv alone.

Suggested sequence

Write down the mapping. One table, old path → new path or dropped, agreed once and applied to all five locales.
Move what maps cleanly, keeping the translated prose as-is. This alone reconnects most of the sidebar.
Decide the unmapped pages — retranslate against the new English page, or delete.
Add a guard so it cannot drift silently again: fail the build, or at minimum warn, when a sidebar slug has no file in a locale. Right now that case is indistinguishable from success.

Step 4 is worth doing first even if the migration waits — it turns an invisible problem into a visible one.

Reproducing the numbers

grep -o "slug: '[^']*'" docs-site/astro.config.mjs | sed "s/slug: '//;s/'//" | sort -u > /tmp/slugs.txt
for l in fr cs ko-kr vi-vn zh-cn; do
  have=$(while read s; do [ -f "docs/$l/$s.md" ] && echo x; done < /tmp/slugs.txt | wc -l)
  echo "$l: $have of $(wc -l < /tmp/slugs.txt) sidebar slugs translated"
done

Noticed while adding a diagram to the docs index: the delivery-loop diagram appeared on exactly one page of the whole site, ko-kr/how-to/choose-a-development-path, a page whose English original no longer exists.