`theme.font: {text, code}` faisait injecter par Material, dans le <head> de
chacune des 316 pages, un preconnect vers fonts.gstatic.com et une feuille
depuis fonts.googleapis.com (Sans 300/300i/400/400i/700/700i + Mono
400/400i/700/700i). Chaque visite transmettait donc l'IP du visiteur à Google
AVANT tout consentement.
Ce qui rendait ça gênant n'est pas la règle en soi, c'est l'asymétrie : le site
vitrine a fait exactement l'inverse en T10, délibérément, pour cette raison
(jurisprudence LG München 2022, doctrine CNIL) et pour ne pas contredire « vos
données ne sortent pas de chez vous ». La doc affichait donc le contraire de
l'engagement que le produit met en avant, sur le même nom de domaine.
Correctif : `theme.font: false` retire les deux balises ; les 16 woff2 viennent
du dépôt du site — mêmes fichiers, mêmes unicode-range (latin + latin-ext pour
les accents), déjà éprouvés en production depuis juin. Les 16 blocs @font-face
sont repris tels quels plutôt que réécrits, avec les chemins adaptés. Material
lit `--md-text-font` / `--md-code-font`, qu'extra.css définit.
312 Ko d'actifs, servis localement.
⚠️ LES ITALIQUES SONT DÉSORMAIS SYNTHÉTISÉES, et c'est la contrepartie à
connaître. Google servait 4 fontes italiques que nous n'avons pas (aucun fichier
italique dans le dépôt du site, aucune IBM Plex installée sur la machine de
build) : le navigateur incline donc la romaine. Visible sur les intertitres en
italique des blocs générés — `_Einstellungen:_`, `_Gemessene Größen:_`. Pour y
remédier : récupérer les woff2 italiques depuis le dépôt officiel IBM/plex (OFL)
et ajouter les @font-face correspondants. La méthode est celle déjà documentée
au T10 du site, et je ne l'ai pas prise d'office — c'est un ajout de binaires
depuis Internet.
Vérifié sur le site construit, et pas seulement sur le <head> :
· 0 url() externe dans toute la CSS
· 0 preconnect
· 0 ressource (link/script/img/iframe) chargée depuis un tiers — le seul hôte
cité est docs.etm-powersync.fr lui-même, par les <link rel="canonical">
· les 16 woff2 présents dans le build, 16 références, 0 chemin cassé
· build --strict sans avertissement
La seule mention restante de Google dans le dépôt est le commentaire d'extra.css
qui explique pourquoi elle n'y est plus.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
mkdocs.yml : plugin i18n en mode `suffix` (page.md = fr, page.de.md,
page.en.md), fr par défaut, fallback_to_default, un index de recherche par
langue, et nav_translations — 29 éléments traduits par langue, vérifié au
build. i18n est placé AVANT literate-nav et search : il réécrit l'arbre des
fichiers par langue, les autres doivent voir l'arbre déjà localisé.
navigation.instant est RETIRÉ de theme.features. Ce n'est pas un arbitrage de
confort : il est incompatible avec le lien contextuel du sélecteur de langue de
mkdocs-static-i18n, et l'avertissement fait ÉCHOUER `mkdocs build --strict`.
Le sélecteur l'emporte — atterrir sur la même page dans l'autre langue vaut
plus qu'un chargement instantané qui renvoie à l'accueil. Le commentaire est à
l'endroit du retrait, pas ailleurs.
Vérifié que literate-nav et static-i18n cohabitent, plutôt que supposé : build
construit, nav de /de/ relue dans le HTML produit (« Geräte », « Kompatibilität »,
liste des appareils bien dépliée).
CI : --locales fr,de,en sur la génération ET sur le contrôle d'idempotence. Et
une étape qui manquait — gen_api_reference.py n'était pas dans le pipeline, sa
sortie ne se propageait donc qu'au prochain passage manuel.
requirements.txt : mkdocs-static-i18n >= 1.3.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
