feat(l10n): geef vertalers een route zonder Dart (#633) #697

Merged
brenno merged 1 commit from feat/vertaalroute-633 into main 2026-07-22 21:54:43 +00:00
Owner

Sluit #633. Beide punten uit je voorstel, geen platform.

(1) De route

make l10n-export LANG_=ga OUT=my-irish.json   # 2.261 strings, plat JSON
make l10n-import LANG_=ga IN=my-irish.json    # terug, geformatteerd

De Nederlandse bronstring ís de sleutel, dus de vertaler ziet altijd waarvan hij een vertaling maakt — geen Dart-bestand ernaast nodig.

JSON en geen PO, en dat is een keuze en geen gemakzucht. PO is de standaard in vertaalland, maar draagt hier niets extra's: geen meervoudsvormen, geen contexten, geen fuzzy-vlaggen in dit corpus. JSON opent met elk gereedschap zonder dat iemand gettext moet installeren. Wél in PO-geest: de bron als sleutel.

Wat het bewust níét doet is sleutels toevoegen. Een import die een onbekende sleutel tegenkomt weigert het hele bestand — dat betekent bijna altijd dat de vertaler op een oudere versie werkte, en dan is stilzwijgend doorgaan de manier waarop zijn werk half landt. Erger nog: zo zou een nieuwe string in één taal kunnen bestaan en in dertig niet, precies wat add_l10n.dart afdwingt te voorkomen.

(2) De gesplitste eis

CONTRIBUTING.md zegt nu dat een PR die één taalbestand raakt en geen sleutels toevoegt zelfstandig welkom is. Alles wat daar stond ging over een string toevoegen, en die eis — 31 talen — is voor een verbetering onzinnig streng. Dat was de helft die de drempel in stand hield.

De scherpste test

De ronde-trip zónder wijziging: exporteren en meteen terugimporteren moet nul strings bijwerken. Doet het er wél één, dan verliest of vervormt de heenweg iets — een aanhalingsteken, een regeleinde, een euroteken — en dan brengt elke vertaalronde ongemerkte wijzigingen mee. Verder: een onbekende taal, een onbekende sleutel, en invoer die geen JSON is, allemaal een nette weigering in plaats van een stacktrace.

Eén detail dat me verraste en dat nu in de Makefile staat: de variabele heet LANG_ en niet LANG, want make erft de omgeving en LANG is op vrijwel elke shell al gezet. Anders draait het gereedschap stilzwijgend op de verkeerde taal.

Poort

make check groen (niet door tail gepijpt). Handmatig getoetst tegen ga: 2.261 strings eruit, één gewijzigde waarde er precies terug in, en niets anders aangeraakt.

Sluit #633. Beide punten uit je voorstel, geen platform. ## (1) De route ```bash make l10n-export LANG_=ga OUT=my-irish.json # 2.261 strings, plat JSON make l10n-import LANG_=ga IN=my-irish.json # terug, geformatteerd ``` De Nederlandse bronstring ís de sleutel, dus de vertaler ziet altijd waarvan hij een vertaling maakt — geen Dart-bestand ernaast nodig. **JSON en geen PO**, en dat is een keuze en geen gemakzucht. PO is de standaard in vertaalland, maar draagt hier niets extra's: geen meervoudsvormen, geen contexten, geen fuzzy-vlaggen in dit corpus. JSON opent met elk gereedschap zonder dat iemand gettext moet installeren. Wél in PO-geest: de bron als sleutel. **Wat het bewust níét doet is sleutels toevoegen.** Een `import` die een onbekende sleutel tegenkomt weigert het hele bestand — dat betekent bijna altijd dat de vertaler op een oudere versie werkte, en dan is stilzwijgend doorgaan de manier waarop zijn werk half landt. Erger nog: zo zou een nieuwe string in één taal kunnen bestaan en in dertig niet, precies wat `add_l10n.dart` afdwingt te voorkomen. ## (2) De gesplitste eis `CONTRIBUTING.md` zegt nu dat een PR die **één** taalbestand raakt en geen sleutels toevoegt zelfstandig welkom is. Alles wat daar stond ging over een string *toevoegen*, en die eis — 31 talen — is voor een *verbetering* onzinnig streng. Dat was de helft die de drempel in stand hield. ## De scherpste test De ronde-trip zónder wijziging: exporteren en meteen terugimporteren moet **nul** strings bijwerken. Doet het er wél één, dan verliest of vervormt de heenweg iets — een aanhalingsteken, een regeleinde, een euroteken — en dan brengt elke vertaalronde ongemerkte wijzigingen mee. Verder: een onbekende taal, een onbekende sleutel, en invoer die geen JSON is, allemaal een nette weigering in plaats van een stacktrace. Eén detail dat me verraste en dat nu in de Makefile staat: de variabele heet `LANG_` en niet `LANG`, want make erft de omgeving en `LANG` is op vrijwel elke shell al gezet. Anders draait het gereedschap stilzwijgend op de verkeerde taal. ## Poort `make check` groen (niet door `tail` gepijpt). Handmatig getoetst tegen `ga`: 2.261 strings eruit, één gewijzigde waarde er precies terug in, en niets anders aangeraakt.
feat(l10n): geef vertalers een route zonder Dart (#633)
Some checks failed
CI / Web hardening (pull_request) Failing after 26s
CI / Gate (Linux) · Format · Analyze · Coverage (pull_request) Failing after 28s
CI / Docs links (pull_request) Failing after 24s
CI / Supply-chain (Trivy · advisory) (pull_request) Failing after 24s
CI / Gate (Linux) · Format · Analyze · Coverage (push) Failing after 24s
CI / Web hardening (push) Failing after 25s
CI / Docs links (push) Failing after 26s
CI / Supply-chain (Trivy · advisory) (push) Failing after 21s
CI / Test (macos-latest) (pull_request) Has been cancelled
CI / Test (windows-latest) (pull_request) Has been cancelled
CI / Test (macos-latest) (push) Has been cancelled
CI / Test (windows-latest) (push) Has been cancelled
c5807b5530
De strings wonen in 32 Dart `part`-bestanden van elk ~3.000 regels. Een
Ierse of Maltese moedertaalspreker die één slechte zin wil verbeteren
moest daarvoor Dart-syntaxis, een `part`-bestand en `make check`
overleven. Die drempel duwt precies de bijdrage weg die dit project het
hardst nodig heeft — moedertaalcontrole op 31 talen — en duwt richting
meer machinevertaling.

`tool/l10n_po.dart` haalt één taal eruit als plat JSON en zet hem er weer
in. De Nederlandse bronstring ís de sleutel, dus de vertaler ziet altijd
waarvan hij een vertaling maakt.

JSON en geen PO, en dat is een keuze: PO is de standaard in vertaalland,
maar draagt hier niets extra's. Geen meervoudsvormen, geen contexten,
geen fuzzy-vlaggen in dit corpus — en JSON opent met elk gereedschap
zonder dat iemand gettext moet installeren.

Wat het bewust níét doet is sleutels toevoegen. Een `import` die een
onbekende sleutel tegenkomt weigert het hele bestand, want dat betekent
bijna altijd dat de vertaler op een oudere versie werkte; stilzwijgend
doorgaan is de manier waarop zijn werk half landt. Nieuwe strings gaan
via `add_l10n.dart`, dat alle 31 talen afdwingt.

De scherpste test is de ronde-trip zonder wijziging: exporteren en meteen
terugimporteren moet nul strings bijwerken. Doet het er wél één, dan
verliest of vervormt de heenweg iets — een aanhalingsteken, een
regeleinde, een euroteken — en dan brengt elke vertaalronde ongemerkte
wijzigingen mee.

Tweede helft van het issue: CONTRIBUTING zegt nu dat een correctie in één
taal zelfstandig mag landen. Alles wat daar stond ging over een string
tóevoegen, en die eis (31 talen) is voor een verbetering onzinnig streng.

Sluit #633.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
brenno merged commit b75fbde023 into main 2026-07-22 21:54:43 +00:00
Sign in to join this conversation.
No description provided.