The documentation pages are a sequence, and the sequence is written down twice: once as the order of MediaWiki:Sidebar, and once as the arguments of the {{prevnext}} call at the bottom of each page. Nothing checks that the two agree, and they already do not.
They already disagree
The sidebar's two groups list 17 pages. The prevnext chain covers 16 and then stops:
index → Why wikitext → Installation → Getting Started → Pages → Editing sidebar → Images
→ Skins → JavaScript → Searching → Translating → Deploying → Troubleshooting
→ Configuration → Standalone binary → Development ✗
| page |
in the sidebar |
has a prevnext |
| Development |
yes (references) |
no |
| Writing an extension |
yes (references, added in #446) |
no |
| Licenses |
yes (references) |
no |
So Standalone binary's next step points at Development, and a reader who takes it arrives at a page with no navigation at all — no way onward to Writing an extension or Licenses, and no way back. Writing an extension was added to the sidebar and never wired into the chain, which is the failure mode this shape produces: adding a page means editing the sidebar, editing the new page, and editing the page before it, and forgetting the third is invisible.
index is the other edge: it starts the chain but is not a sidebar entry (the sidebar names it through mainpage).
The proposal
Make MediaWiki:Sidebar the one place the order lives, and have the bottom navigation read it, so {{prevnext}} takes no arguments at all.
The direction is forced, and it is worth stating why, because the obvious instinct is the opposite one. MediaWiki:Sidebar is parsed line by line by the skin, not as ordinary wikitext: Manual:Interface/Sidebar allows a parser function only when the ** stays outside it and it does not span lines, and a template that expands into several entries is not something it can hold. The sidebar cannot read anything. But it is an ordinary page in the MediaWiki: namespace, so anything else can read it. Sidebar-as-source is the only arrangement that needs no extension code.
What it would take
A Lua module. Reading the sidebar means splitting lines and stripping the Special:MyLanguage/ prefix and the |message-key label off each entry, which core parser functions cannot do. Scribunto is bundled, so enabling it is one line in docs/.wikven.yml with nothing to fetch — but check first that it runs in the image: Scribunto needs either the LuaSandbox PHP extension or a standalone lua binary, and neither is obviously present in the Alpine-based image. If it is missing, this proposal costs a Dockerfile change, and that changes the trade.
A base-name lookup for the current page. On a translation page {{PAGENAME}} is Searching/ko, so the module has to match on {{ROOTPAGENAME}} to find its place in a list of source-page names.
A decision about the group boundary. The chain crosses from the docs group into the references group today (Troubleshooting → Configuration). Either it keeps spanning groups, or each group becomes its own chain and the crossing goes away — worth deciding deliberately rather than inheriting.
A place for index. It heads the chain without being a sidebar entry, so the module needs it prepended, or index keeps a hand-written call.
What it does not change
Link labels. Since #449 the label is the target page's own title, read from that page's title unit, so the labels stay translated and stay out of this. What the sidebar contributes is order alone.
The sidebar's own labels stay message keys (MediaWiki:Sidebar-searching and its /ko), which is a second copy of every page title that this proposal does not reach. Reaching it means building the sidebar in PHP through SidebarBeforeOutput, which is a wikven feature and not a docs change.
The alternative
Leave the order in the pages and fix the drift by hand: give Development, Writing an extension and Licenses their prevnext calls. That costs one commit today and pays the same cost again for every page added or reordered, with nothing to notice when someone forgets — which is how the three above came to be missing.
A middle option is to keep the calls and assert the agreement instead: a check that every sidebar entry appears in the chain exactly once, in the sidebar's order, run beside the existing docs/ checks. That keeps the wikitext as simple as it is now and moves the duplication from unwatched to watched, without Scribunto.
The documentation pages are a sequence, and the sequence is written down twice: once as the order of
MediaWiki:Sidebar, and once as the arguments of the{{prevnext}}call at the bottom of each page. Nothing checks that the two agree, and they already do not.They already disagree
The sidebar's two groups list 17 pages. The prevnext chain covers 16 and then stops:
So
Standalone binary's next step points atDevelopment, and a reader who takes it arrives at a page with no navigation at all — no way onward toWriting an extensionorLicenses, and no way back.Writing an extensionwas added to the sidebar and never wired into the chain, which is the failure mode this shape produces: adding a page means editing the sidebar, editing the new page, and editing the page before it, and forgetting the third is invisible.indexis the other edge: it starts the chain but is not a sidebar entry (the sidebar names it throughmainpage).The proposal
Make
MediaWiki:Sidebarthe one place the order lives, and have the bottom navigation read it, so{{prevnext}}takes no arguments at all.The direction is forced, and it is worth stating why, because the obvious instinct is the opposite one.
MediaWiki:Sidebaris parsed line by line by the skin, not as ordinary wikitext: Manual:Interface/Sidebar allows a parser function only when the**stays outside it and it does not span lines, and a template that expands into several entries is not something it can hold. The sidebar cannot read anything. But it is an ordinary page in theMediaWiki:namespace, so anything else can read it. Sidebar-as-source is the only arrangement that needs no extension code.What it would take
A Lua module. Reading the sidebar means splitting lines and stripping the
Special:MyLanguage/prefix and the|message-keylabel off each entry, which core parser functions cannot do. Scribunto is bundled, so enabling it is one line indocs/.wikven.ymlwith nothing to fetch — but check first that it runs in the image: Scribunto needs either the LuaSandbox PHP extension or a standaloneluabinary, and neither is obviously present in the Alpine-based image. If it is missing, this proposal costs a Dockerfile change, and that changes the trade.A base-name lookup for the current page. On a translation page
{{PAGENAME}}isSearching/ko, so the module has to match on{{ROOTPAGENAME}}to find its place in a list of source-page names.A decision about the group boundary. The chain crosses from the docs group into the references group today (
Troubleshooting → Configuration). Either it keeps spanning groups, or each group becomes its own chain and the crossing goes away — worth deciding deliberately rather than inheriting.A place for
index. It heads the chain without being a sidebar entry, so the module needs it prepended, orindexkeeps a hand-written call.What it does not change
Link labels. Since #449 the label is the target page's own title, read from that page's title unit, so the labels stay translated and stay out of this. What the sidebar contributes is order alone.
The sidebar's own labels stay message keys (
MediaWiki:Sidebar-searchingand its/ko), which is a second copy of every page title that this proposal does not reach. Reaching it means building the sidebar in PHP throughSidebarBeforeOutput, which is a wikven feature and not a docs change.The alternative
Leave the order in the pages and fix the drift by hand: give
Development,Writing an extensionandLicensestheir prevnext calls. That costs one commit today and pays the same cost again for every page added or reordered, with nothing to notice when someone forgets — which is how the three above came to be missing.A middle option is to keep the calls and assert the agreement instead: a check that every sidebar entry appears in the chain exactly once, in the sidebar's order, run beside the existing
docs/checks. That keeps the wikitext as simple as it is now and moves the duplication from unwatched to watched, without Scribunto.