Regenerate the README language tables when Weblate's translations land #1044

New issue

Closed

opened 2026-10-24 15:08:12 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-10-24 15:08:12 +00:00

Owner

Problem

README.md and .github/README.md carry a language table written by scripts/readme_languages.py (and copied by scripts/github_readme.py). It lists every language with a translated tagline, so it changes whenever Weblate translates or edits that string, or a language crosses the line into the table.

tests/test_readme.py::test_the_language_table_is_current (and test_the_github_readme_is_current) then fail on the Weblate pull request, and someone has to regenerate both files by hand and push to the weblate branch. That does not stick: Weblate rebases its branch onto main before pushing, and drops the hand-made commit. It happened twice on #1041 (6f2e55f26 and 8fcfe3868 were dropped; 473b17669 is the third copy).

What we want

The tables are brought up to date without anyone running the scripts, and a Weblate PR is not red only because of them.

Constraints

Weblate cannot run our scripts: it has no add-on that runs arbitrary commands.
Since 2026-10-24, main requires signed commits. Forgejo signs its own merge and squash commits, and Weblate signs its own, but a commit made by a CI job is unsigned. If that commit reaches main through a merge commit (the way Weblate PRs are merged), the merge is refused.
Translations change only in Weblate (#706). The tables are generated files, not translations, so that rule doesn't stop us regenerating them.

Options

Regenerate after the merge. A workflow on push to main runs both scripts. If anything changed, it opens a PR from a bot branch, which is squash-merged and so signed by Forgejo. The two README tests are skipped on PRs whose head is weblate (or turned into a warning there), so Weblate PRs stay green.
Regenerate on the Weblate PR. A workflow on pull_request from weblate commits the regenerated files to the branch. This needs a signing key as a CI secret, and still loses the commit when Weblate next rebases. Not recommended.
Stop committing the table. Render it at release time or into the wiki, and leave the READMEs with a link. This changes what the GitHub mirror shows.

Option 1 looks like the smallest change that works with how Weblate already behaves.

## Problem `README.md` and `.github/README.md` carry a language table written by `scripts/readme_languages.py` (and copied by `scripts/github_readme.py`). It lists every language with a translated tagline, so it changes whenever Weblate translates or edits that string, or a language crosses the line into the table. `tests/test_readme.py::test_the_language_table_is_current` (and `test_the_github_readme_is_current`) then fail on the Weblate pull request, and someone has to regenerate both files by hand and push to the `weblate` branch. That does not stick: Weblate rebases its branch onto `main` before pushing, and drops the hand-made commit. It happened twice on #1041 (`6f2e55f26` and `8fcfe3868` were dropped; `473b17669` is the third copy). ## What we want The tables are brought up to date without anyone running the scripts, and a Weblate PR is not red only because of them. ## Constraints - Weblate cannot run our scripts: it has no add-on that runs arbitrary commands. - Since 2026-10-24, `main` requires signed commits. Forgejo signs its own merge and squash commits, and Weblate signs its own, but a commit made by a CI job is unsigned. If that commit reaches `main` through a merge commit (the way Weblate PRs are merged), the merge is refused. - Translations change only in Weblate (#706). The tables are generated files, not translations, so that rule doesn't stop us regenerating them. ## Options 1. **Regenerate after the merge.** A workflow on push to `main` runs both scripts. If anything changed, it opens a PR from a bot branch, which is squash-merged and so signed by Forgejo. The two README tests are skipped on PRs whose head is `weblate` (or turned into a warning there), so Weblate PRs stay green. 2. **Regenerate on the Weblate PR.** A workflow on `pull_request` from `weblate` commits the regenerated files to the branch. This needs a signing key as a CI secret, and still loses the commit when Weblate next rebases. Not recommended. 3. **Stop committing the table.** Render it at release time or into the wiki, and leave the READMEs with a link. This changes what the GitHub mirror shows. Option 1 looks like the smallest change that works with how Weblate already behaves.

tiagoagueda referenced this issue from a commit

2026-10-24 15:35:07 +00:00

Write the README language tables after translations land (#1044)

tiagoagueda referenced this issue from a commit

2026-10-24 15:35:24 +00:00

Write the README language tables after translations land (#1044)

tiagoagueda referenced this issue from a pull request that will close it,

2026-10-24 15:35:36 +00:00

Write the README language tables after translations land #1045

tiagoagueda closed this issue

2026-10-24 16:52:49 +00:00