Aller au contenu

CI : attraper les problèmes i18n à chaque pull request

Sonenta évalue l'impact i18n d'une pull request, clés mal structurées, chaînes en dur, placeholders manquants et candidats de qualité de traduction, et les signale directement sur le diff. C'est indicatif par défaut, avec l'option de bloquer une pull request sur de vraies erreurs de structure.

Sur les fichiers qu'une pull request modifie :

Structurel, les clés auto-préfixées. Une clé préfixée par son propre namespace imbrique une couche redondante dans le bundle et peut faire retomber le SDK en silence sur la locale source. C'est le seul check qui peut bloquer une pull request.

Chaînes en dur. Du texte visible par l'utilisateur pas encore derrière une clé. Indicatif.

Placeholders divergents. Des variables d'interpolation ({{name}}, {count}, %{n}) qui ont dérivé par rapport à la source. Indicatif.

Candidats de qualité de traduction. same_as_source, looks_like_raw_key et wrong_language. Ce sont des heuristiques, attendez-vous donc à des faux positifs sur les marques et les acronymes. Toujours indicatif.

sonenta ci est livrée dans @sonenta/cli et tourne hors-ligne. Pointez-la sur une ref de base et elle imprime un rapport prêt pour la pull request.

Fenêtre de terminal
sonenta ci --base origin/main --source-lang en

Options : --base <ref> (défaut : la base de la PR, sinon origin/main), --source-lang <code> (active le check same-as-source), --strict (sort non-zéro quand le statut est FAIL), --format markdown|json, --out <file>, --dir <path>, --src <dir>. La commande a l'alias check.

Branchez-la dans une GitHub Action :

name: i18n
on: pull_request
jobs:
i18n:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: actions/setup-node@v4
with:
node-version: 20
- run: npx @sonenta/cli ci --base "origin/${{ github.base_ref }}" --source-lang en

sonenta ci n'a pas accès à votre glossaire Sonenta. Les checks de qualité (same_as_source, looks_like_raw_key) peuvent donc signaler à tort des termes gardés en source, marques et noms propres. Ils sont indicatifs et ne font jamais échouer le build.

L'autorité pour la qualité de traduction est validate_translations, en ligne et conscient du glossaire. Lancez-le avant de publier.

L'App hébergée poste un Check Run GitHub natif sur chaque pull request, avec des annotations inline au fichier et à la ligne exacts, et gère les modes indicatif et bloquant. Elle demande ces permissions sur le dépôt : Contents (lecture), Checks (lecture et écriture) et Pull requests (lecture et écriture), et s'abonne à l'événement Pull request.

Ajoutez un fichier .sonenta/ci.json à la racine de votre dépôt. Il est lu sur le HEAD de la pull request :

{ "project_id": "<UUID de votre projet Sonenta>" }
  • project_id (requis) : l'UUID de votre projet Sonenta. S'il est absent ou vide, le fichier est ignoré.
  • source_lang (optionnel) : réservé pour un usage futur.

Aucun autre champ n'est lu.

Par défaut le check est indicatif : les résultats apparaissent en annotations et le Check Run conclut neutral, donc une pull request n'est jamais bloquée.

Pour exiger un check de structure au vert, activez Bloquer les pull requests sur les erreurs de structure i18n pour le projet, dans le dashboard sous GitHub CI. Seul le check structurel peut bloquer ; les résultats de qualité, chaînes en dur et placeholders restent toujours indicatifs.

RéglageEffet
Blocage désactivé (défaut)Les résultats structurels sont des avertissements ; le Check Run conclut neutral.
Blocage activéLes résultats structurels font échouer le check ; le Check Run conclut failure.

Un Check Run nommé Sonenta i18n avec un titre, un résumé et des annotations inline, une par résultat au fichier et à la ligne.

Niveaux d'annotation : structurel = failure quand le blocage est activé, sinon warning ; qualité et chaînes en dur = warning. Le run conclut failure (erreur structurelle avec blocage activé), neutral (résultats indicatifs seulement) ou success (rien trouvé).