Attrapez les problèmes i18n à chaque pull request

Ce que ça vérifie

Sur les fichiers qu'une pull request modifie :

• Structurel (clés self-namespaced). Une clé préfixée par son propre namespace, ce qui 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.

Disponible aujourd'hui : la commande sonenta ci

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.

1npx @sonenta/cli 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>.

Branchez-la dans une GitHub Action :

1name: i18n2on: pull_request3jobs:4  i18n:5    runs-on: ubuntu-latest6    steps:7      - uses: actions/checkout@v48        with:9          fetch-depth: 010      - uses: actions/setup-node@v411        with:12          node-version: 2013      - run: npx @sonenta/cli ci --base "origin/${{ github.base_ref }}" --source-lang en

L'App GitHub hébergée (bientôt disponible)

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.

Configurer avec .sonenta/ci.json

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

1{ "project_id": "<your Sonenta project UUID>" }

• 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.

Indicatif ou bloquant

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 client sous GitHub CI. Seul le check structurel peut bloquer ; les résultats de qualité, chaînes en dur et placeholders restent toujours indicatifs.

• 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.

À quoi ressemble le résultat

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é).