Translations: a working round trip between this repository and its Weblate project on translate.tiagoagueda.com #10

New issue

Closed

opened 2026-10-01 10:14:21 +00:00 by tiagoagueda · 1 comment

tiagoagueda commented

2026-10-01 10:14:21 +00:00

Owner

Requested by the maintainer on 2026-10-01, for every repository: integration and a fully working workflow of string translation with the corresponding translation project hosted on translate.tiagoagueda.com (Weblate). The shared decisions (how a translation comes back, drafts, who may translate) are made in postulo/postulo#349; this issue is this repository's share.

Where it stands

This repository is not in Weblate at all. Its sentences are WebExtension catalogues, src/_locales/<locale>/messages.json (three locales today: English, French and European Portuguese), translated by hand and by copying; the Weblate project postulo holds only the gettext catalogues of the core and of the Python plugins.

What "fully working" means

The same four things in every repository:

Out: a string added or changed here appears in Weblate without anybody doing anything (Weblate is told of each push, or pulls on a schedule).
In: a translation saved in Weblate arrives here without anybody exporting a file: Weblate commits and proposes the change, and this repository's CI runs on it before it reaches main.
Accepted: what Weblate writes passes this repository's own catalogue checks unchanged, and what this repository's tooling writes does not show up in Weblate as a change.
Explained: the README (and the core's docs/TRANSLATING.md) tell a speaker where to go and what happens to what they type.

Here

A component for this repository, in Weblate's WebExtension JSON format, with the English catalogue as the source and each message's description as the translator's context.
Locale folders and codes. The browser demands folder names like pt_PT; the tags the code uses are decided in postulo/postulo#337. The component's language-code style has to produce the folder names the browser accepts.
Completeness. test/i18n.test.mjs demands every key, non-empty, in every locale shipped. A language arriving from Weblate half translated must not ship half translated: either it stays out of _locales/ until complete, or the build leaves it out. #7 is where the list of languages shipped is tied to the core's.
Drafts. The JSON format has no flag for "a machine wrote this and nobody has read it". Say where that is recorded (Weblate's own review state, with a note of it in the repository), so the honesty the gettext catalogues have is not lost here.
Translations come back the way postulo/postulo#349 decides, and this repository's CI runs on them.
Sentences shared with the browser extension. Most of this extension's sentences are postulo-chromium's own (shared.json). They should be translated once: Weblate's translation memory, or one shared component, so a speaker is not asked the same sentence twice and the two extensions cannot drift.

Done when

A sentence added to the English catalogue appears in Weblate with no manual step.
A translation saved in Weblate arrives as a change that passes npm test, and ships only when its language is complete.
The README's Languages section says where to translate the extension.

Requested by the maintainer on 2026-10-01, for every repository: **integration and a fully working workflow of string translation with the corresponding translation project hosted on translate.tiagoagueda.com (Weblate).** The shared decisions (how a translation comes back, drafts, who may translate) are made in postulo/postulo#349; this issue is this repository's share. ## Where it stands This repository is not in Weblate at all. Its sentences are WebExtension catalogues, `src/_locales/<locale>/messages.json` (three locales today: English, French and European Portuguese), translated by hand and by copying; the Weblate project `postulo` holds only the gettext catalogues of the core and of the Python plugins. ## What "fully working" means The same four things in every repository: 1. **Out:** a string added or changed here appears in Weblate without anybody doing anything (Weblate is told of each push, or pulls on a schedule). 2. **In:** a translation saved in Weblate arrives here without anybody exporting a file: Weblate commits and proposes the change, and this repository's CI runs on it before it reaches `main`. 3. **Accepted:** what Weblate writes passes this repository's own catalogue checks unchanged, and what this repository's tooling writes does not show up in Weblate as a change. 4. **Explained:** the README (and the core's `docs/TRANSLATING.md`) tell a speaker where to go and what happens to what they type. ## Here - **A component for this repository**, in Weblate's WebExtension JSON format, with the English catalogue as the source and each message's `description` as the translator's context. - **Locale folders and codes.** The browser demands folder names like `pt_PT`; the tags the code uses are decided in postulo/postulo#337. The component's language-code style has to produce the folder names the browser accepts. - **Completeness.** `test/i18n.test.mjs` demands every key, non-empty, in every locale shipped. A language arriving from Weblate half translated must not ship half translated: either it stays out of `_locales/` until complete, or the build leaves it out. #7 is where the list of languages shipped is tied to the core's. - **Drafts.** The JSON format has no flag for "a machine wrote this and nobody has read it". Say where that is recorded (Weblate's own review state, with a note of it in the repository), so the honesty the gettext catalogues have is not lost here. - Translations come back the way postulo/postulo#349 decides, and this repository's CI runs on them. - **Sentences shared with the browser extension.** Most of this extension's sentences are postulo-chromium's own (`shared.json`). They should be translated once: Weblate's translation memory, or one shared component, so a speaker is not asked the same sentence twice and the two extensions cannot drift. ## Done when - A sentence added to the English catalogue appears in Weblate with no manual step. - A translation saved in Weblate arrives as a change that passes `npm test`, and ships only when its language is complete. - The README's *Languages* section says where to translate the extension.

tiagoagueda added this to the 0.5.0 milestone

2026-10-01 10:14:21 +00:00

tiagoagueda added the

enhancement

label

2026-10-01 10:14:21 +00:00

tiagoagueda referenced this issue from Postulo/postulo

2026-10-01 10:14:23 +00:00

Translations: a working round trip between this repository and its Weblate project on translate.tiagoagueda.com #349

tiagoagueda referenced this issue from a commit

2026-10-10 12:02:41 +00:00

Take translations from Weblate only: the build writes each catalogue's language, a guard refuses the rest

tiagoagueda commented

2026-10-10 15:37:14 +00:00

Author

Owner

Done, as postulo/postulo#349 decided: this repository is a component in Weblate (translate.tiagoagueda.com) that follows main through a Forgejo webhook, drafts new strings by machine, and sends translations back as a pull request from the weblate branch; CI refuses a translation written outside Weblate. See this repository's commit referencing this issue, and postulo/postulo#829 for the first round trip, merged green.

Done, as postulo/postulo#349 decided: this repository is a component in Weblate (translate.tiagoagueda.com) that follows main through a Forgejo webhook, drafts new strings by machine, and sends translations back as a pull request from the `weblate` branch; CI refuses a translation written outside Weblate. See this repository's commit referencing this issue, and postulo/postulo#829 for the first round trip, merged green.

tiagoagueda closed this issue

2026-10-10 15:37:14 +00:00