Wiki: nothing runs `wiki_site.py stale --strict` or builds the translated pages, so a moved English source is noticed only by hand #1147

New issue

Open

opened 2026-10-31 03:04:21 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-10-31 03:04:21 +00:00

Owner

What exists today

scripts/wiki_site.py (#352) builds the pre-install pages (PUBLIC_PAGES: Home, Installing-Postulo, Getting-started) as a static site in each language the wiki holds, and stale --strict fails when an English page changed after its translation was stamped. tests/test_wiki_site.py tests the script against fixtures, not against the wiki.
postulo.wiki now holds site.json and lang/fr-FR, lang/pt-PT, so there is something to go stale.
It is all manual: CONTRIBUTING.md:561 asks whoever changes an English page to run stale, and docs/TRANSLATING.md:413-416 lists the commands. No workflow in the core runs it, and no published copy of the built site exists.

Correction to the candidate: "no CI on the wiki repo" cannot be fixed in the wiki itself. postulo.wiki is Forgejo's built-in wiki (…/Postulo/postulo.wiki.git); Forgejo Actions run for repositories, not for a repository's wiki, so there is no .forgejo/workflows to add there. The check has to run from the core's CI, cloning the wiki.

No duplicate: searches for "wiki CI", "wiki stale", "wiki_site" find nothing beyond #352 and #1044 (README tables).

What would change

Add a step to the core's scheduled run (ci.yml lines 46-49, Monday) that clones postulo.wiki with fetch-depth: 1 and runs uv run python scripts/wiki_site.py stale ../postulo.wiki --strict. It needs only markdown-it-py, already installed; a few seconds. A stale translation then shows as a red weekly run naming the page.
Building and publishing the site is a separate decision (a Forgejo Pages-style host, the release assets, or beside the instance) and should wait for it.

What it saves or protects

small: a translated wiki page that describes an older interface is caught within a week instead of whenever someone runs the command

Accessibility

none

Decided by the maintainer (2026-10-31)

the weekly run fails on a stale wiki translation; site publishing stays with #352

Decisions

Fail the weekly run on a stale page, or report it? Recommended: fail it; unlike pictures (W5), a stale translation only happens when an English page moves, so it is rare and actionable, and the fix is in Weblate.
Publish the built site from CI? Recommended: not in this issue; it needs the hosting decision #352 left open.

Found by the efficiency and reliability audit of 2026-10-30 (finding W6; index postulo/postulo#1108). Checked against main at daee30b15 (2026-10-30).

## What exists today - `scripts/wiki_site.py` (#352) builds the pre-install pages (`PUBLIC_PAGES`: Home, Installing-Postulo, Getting-started) as a static site in each language the wiki holds, and `stale --strict` fails when an English page changed after its translation was stamped. `tests/test_wiki_site.py` tests the script against fixtures, not against the wiki. - `postulo.wiki` now holds `site.json` and `lang/fr-FR`, `lang/pt-PT`, so there is something to go stale. - It is all manual: `CONTRIBUTING.md:561` asks whoever changes an English page to run `stale`, and `docs/TRANSLATING.md:413-416` lists the commands. No workflow in the core runs it, and no published copy of the built site exists. Correction to the candidate: "no CI on the wiki repo" cannot be fixed in the wiki itself. `postulo.wiki` is Forgejo's built-in wiki (`…/Postulo/postulo.wiki.git`); Forgejo Actions run for repositories, not for a repository's wiki, so there is no `.forgejo/workflows` to add there. The check has to run from the core's CI, cloning the wiki. No duplicate: searches for "wiki CI", "wiki stale", "wiki_site" find nothing beyond #352 and #1044 (README tables). ## What would change - Add a step to the core's scheduled run (`ci.yml` lines 46-49, Monday) that clones `postulo.wiki` with `fetch-depth: 1` and runs `uv run python scripts/wiki_site.py stale ../postulo.wiki --strict`. It needs only `markdown-it-py`, already installed; a few seconds. A stale translation then shows as a red weekly run naming the page. - Building and publishing the site is a separate decision (a Forgejo Pages-style host, the release assets, or beside the instance) and should wait for it. ## What it saves or protects small: a translated wiki page that describes an older interface is caught within a week instead of whenever someone runs the command ## Accessibility none ## Decided by the maintainer (2026-10-31) the weekly run fails on a stale wiki translation; site publishing stays with #352 ## Decisions - **Fail the weekly run on a stale page, or report it?** Recommended: fail it; unlike pictures (W5), a stale translation only happens when an English page moves, so it is rare and actionable, and the fix is in Weblate. - **Publish the built site from CI?** Recommended: not in this issue; it needs the hosting decision #352 left open. --- Found by the efficiency and reliability audit of 2026-10-30 (finding W6; index postulo/postulo#1108). Checked against `main` at `daee30b15` (2026-10-30).

tiagoagueda added this to the 1.0.0 milestone

2026-10-31 03:04:21 +00:00

tiagoagueda added the

performance

enhancement

documentation

labels

2026-10-31 03:04:21 +00:00

tiagoagueda referenced this issue

2026-10-31 03:04:41 +00:00

Efficiency and reliability audit of 2026-10-30: index #1108