Signalé sur /de/appareils/bornes/goecharger/ : la page était allemande sur deux
lignes et anglaise sur tout le reste. Le diagnostic a séparé deux choses que
j'avais mises dans le même sac le 2026-10-12.
LA LIGNE DE PARTAGE, écrite en tête du générateur :
• les LIBELLÉS QUE NOUS ÉCRIVONS (en-têtes de colonnes, titres de section,
oui/non, « Documentation fabricant ») → TRADUITS. Ils ne désignent rien à
l'écran, l'anglais n'y était qu'une friction. REF devient REF_I18N, trois
jeux de 20 libellés.
• le CONTENU VENANT DE NYMEA (noms de modèles, clés de registres, libellés de
champs comme « MAC address », unités) → VERBATIM, en anglais. Ce sont
exactement les chaînes que l'installateur lit DANS L'APP, qui tourne en
en_US. Les traduire rendrait la doc inutilisable pour retrouver un champ à
l'écran.
Et la pièce qui change l'expérience plus que la traduction elle-même : une note
`verbatim`, générée dans la langue de la page, en tête du bloc de référence.
Sans elle le mélange FR/EN passe pour une traduction bâclée ; avec elle c'est
une convention que le lecteur comprend.
L'injection devient sensible à la langue : `locale_of()` déduit la langue du
suffixe du fichier et `process()` rend le bloc en conséquence. Sans ça le même
bloc partait à l'identique dans les trois versions.
TAGLINES ET TITRES — i18n/devices.yaml, 52 entrées
Le tagline vivait en paragraphe libre, écrit UNE SEULE FOIS à la création de la
page : il restait donc en anglais sur les trois versions, y compris la
FRANÇAISE. Il entre dans le bloc badges, donc il est régénéré, donc traduisible
pour toujours. 52 taglines en fr et de ; l'anglais retombe sur l'amont.
Les traductions vivent dans le dépôt de DOC et pas dans les meta.json : trois
des cinq dépôts plugins sont des dépôts nymea amont que l'AGENTS.md interdit de
modifier. Repli sur l'amont pour toute entrée absente.
Deux titres s'affichaient en FRANÇAIS sous /de/ et /en/ — « Compteur ABB B2x »,
« Borne ABB Terra AC » : corrigés, dans la page et dans la nav.
Deux coquilles AMONT corrigées au passage, repérées en relisant les 57 entrées :
meta.json annonçait « Bestel » pour Vestel et « Easeex » pour Easee. Signalées
comme corrections, pas comme traductions, dans i18n/devices.yaml.
48 FICHES FR ÉTAIENT DANS UN ANCIEN FORMAT, ET MENTAIENT
Trouvé en vérifiant : 48 fiches FR n'avaient pas de marqueur `__badges_*__`.
Leurs badges étaient du HTML figé, écrit une fois — goecharger affichait
« NIGHTLY » alors que PORTING_STATUS dit `stable` depuis. Elles sont migrées au
format canonique : badges générés, donc exacts, plus titre localisé, tagline et
intertitre. Reste `hvac/homeconnect.md`, orpheline (plugin hors PORTING_STATUS).
NAV : UN CONSTAT QUI ÉVITE DE REFAIRE L'ESSAI
`literate-nav` ne lit que son `nav_file` : la substitution par suffixe de
mkdocs-static-i18n ne s'y applique PAS. Un `SUMMARY.de.md` généré n'était lu par
personne et la barre latérale allemande gardait les noms français. Testé, puis
retiré — et la raison est écrite dans le générateur pour que personne n'y
revienne. Les libellés de nav passent par `nav_translations` : 31 éléments
traduits par langue au lieu de 29.
RÉFÉRENCE API : LAISSÉE EN ANGLAIS, DÉLIBÉRÉMENT
Les 23 pages de l'API n'ont pas de variante par langue. Leur traduire les
libellés aurait fait voir du FRANÇAIS aux lecteurs /de/ et /en/ par le repli —
une régression. Créer 46 variantes pour traduire dix libellés aurait triplé
28 000 mots de contenu généré pour un gain nul : le reste de la page (noms de
méthodes, de champs, de types, descriptions) est l'API elle-même, et ce sont les
chaînes qu'on écrit dans ses requêtes. À la place, une note explique dans les
trois langues POURQUOI cette référence est en anglais.
Vérifié : build --strict sans avertissement, les deux générateurs rendent « Doc à
jour » en --check, et la fiche goecharger relue dans les trois langues.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
validate_entries() arrête la génération quand une entrée de PORTING_STATUS d'un
canal autre que nightly n'a pas son integrationplugin*.json dans --src. L'entrée
waveshare-relay-d8 était en `channel: testing` pour un plugin qui n'a JAMAIS été
livré : la CI a donc échoué chaque nuit du 2026-08-02 au 2026-10-13, et le site de
doc est resté gelé au build du 1er août. Dix semaines, en silence.
Le garde-fou avait raison. C'est l'entrée qui était fausse, pas le contrôle — d'où
le choix de retirer l'entrée plutôt que de la basculer en nightly (ce qui aurait
publié « portage en cours » là où il n'y a pas de portage) ou d'assouplir
validate_entries() (ce qui aurait échangé un échec visible contre une doc
silencieusement incomplète).
Retirés : l'entrée de PORTING_STATUS — remplacée par le motif complet, sur place,
pour que personne ne la réintroduise sans savoir — et les trois fiches
smart/waveshare.{md,de.md,en.md}. Le reste des mentions vivait dans du contenu
généré (SUMMARY.md, index de catégorie, matrice de compatibilité) et a disparu à
la régénération.
Au passage, deux choses trouvées en nettoyant :
- `appareils/index.md` citait « SmartDevices — Waveshare » comme exemple de la
catégorie ; remplacé par Shelly, Tasmota, GPIO, qui sont en canal stable.
- cette même page n'avait AUCUNE variante traduite : une entrée de nav de premier
niveau servie en français sous /de/ et /en/. Traduite.
Chaîne CI rejouée en entier dans l'ordre, après correction : génération appareils
OK, génération API OK, `mkdocs build --strict` sans aucun avertissement,
contrôle d'idempotence OK.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Correction 2 — canal par défaut selon l'origine :
- Tous les plugins origin:nymea passent de nightly→stable (upstream redistribué tel quel)
- Plugins ETM conservent leur canal manuel (eastron=stable, abb-b2x/abb-terra/waveshare=testing)
- Ajout name: sur 5 plugins sans meta.json (v2xeamberelectric→Amber Electric, mtec,
genericenergy, genericheatingcooling, genericcar)
Correction 3 — Keba fork ETM :
- repo: etm-powersync-plugins (fork corrigé KC-P30), channel: testing, origin: etm
- La version nymea-plugins (bugguée) n'est plus déclarée → écartée de facto
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
