4 Commits

Author SHA1 Message Date
Patrick Schurig
bba9c87608 docs: prévision PV et tarif saisi de la version Community, FAQ alignée
Nouvelle page fonctionnalites/prevision-pv (FR/DE/EN, dans la nav) : courbe
horaire jusqu'à la fin du lendemain par plan, correction de température et
plafond onduleur (modèles déterministes publics, aucun apprentissage),
« plafond optimiste », « une heure sans donnée est un trou, jamais un zéro »,
fourchette météo (qualifie la météo seulement), météo horaire, mise en
service, règle centrale de la Community (affiché et enregistré localement,
jamais utilisé pour décider), consommation de base « à venir », données qui
sortent, optimiseur seulement comme interface prévue.

Tarifs (3 langues) : section BETA « tarif saisi », exposé et non utilisé pour
décider ; les tarifs dynamiques restent en roadmap.

FAQ (3 langues) : réponse « données » réécrite avec la liste de ce qui sort ;
« Predict AI », `optimizer-plugin` et « socket Unix » retirés ; la prévision
physique passe dans Community, Pro garde les prévisions apprises.
Accueil : « sans dépendance au cloud ». Tableau des fonctionnalités : trois
lignes. Fiche OpenMeteo : lien vers la page, plafond appliqué par le moteur.

Sources : INTERFACE.md et DESIGN_PREVISION_PV.md (feature/forecast-protocol-1.1),
CONTRACT_A v4, CONSIGNE-app-etm66-prevision.md. Aucune donnée du banc.
Vérifié comme en CI : génération, --check et mkdocs build --strict passent.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-16 22:29:53 +02:00
Patrick Schurig
b2513a86a4 docs(openmeteo): guide d'installation en trois langues, à la place du « à venir »
La fiche openmeteo n'avait que son bloc de référence généré. Elle porte
maintenant la prose, en FR, DE et EN : ajout du site et des plans PV (avec
l'avertissement azimut 0 = nord), « une prévision, jamais une mesure » (la
conversion ignore ombrage, encrassement et écrêtage : la prévision est
optimiste), rafraîchissement et relance, comportement sans internet, ce qui
quitte la box, usage commercial et attribution CC-BY.

Chaque affirmation a été vérifiée dans le code de feature/beta-forecast
(etm16) : coordonnées arrondies à deux décimales, altitude envoyée seulement
si renseignée, puissance crête et rendement jamais transmis. La prose reste
juste aussi pour master, dont la CI génère le bloc de référence.

Accroche corrigée dans i18n/devices.yaml : le meta.json annonce « current
weather data », alors que le plugin publie surtout des prévisions.

Supprimé : la ligne commentée `openmeteo, channel: nightly` de
PORTING_STATUS.yaml, un vestige qui contredisait l'entrée active.

TODO : noté que la référence publiée retarde sur le paquet testing (master
d'etm-powersync-plugins a 39 commits de retard sur feature/beta-forecast).

Vérifié dans une copie, à partir des branches par défaut des 5 dépôts de
plugins comme en CI : génération, --check et mkdocs build --strict passent.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-16 22:08:34 +02:00
Patrick Schurig
846c0c7525 feat(i18n): traduire ce qu'on écrit, garder verbatim ce que la machine affiche
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>
2026-10-13 08:42:21 +02:00
Patrick Schurig
325409dd3f feat(i18n): prose traduite DE/EN et référence régénérée en anglais
82 pages .de.md et 82 .en.md. La volumétrie explique la forme : 95 % du volume
est GÉNÉRÉ (74 013 mots contre 3 506 rédigés, mesuré sur 107 pages). On ne
traduisait donc pas 77 500 mots — on traduit la prose, et le vocabulaire des
générateurs fait le reste.

Prose traduite à la main : accueil, installation (4), fonctionnalités (4),
tarifs, référence, dépannage, FAQ, intégrations (2), api/index, et les 6 fiches
appareils qui portent une vraie prose + compatibilite.md. Les blocs générés ne
sont JAMAIS recopiés dans une traduction : le script de pose les reprend
verbatim du fichier français via des placeholders, pour qu'une traduction ne
puisse pas désynchroniser un bloc généré.

Les 49 fiches légères n'ont rien à traduire : leur tagline vient d'amont et est
DÉJÀ en anglais (« Connects nymea to powerfox. »). Constat, pas renoncement.

Localisation ≠ traduction, et tarifs.md en est l'exemple à connaître : la
version FR parle de Tempo et du signal RTE, la DE de §14a EnWG et de SMARD,
l'EN des deux. Ce ne sont pas des traductions l'une de l'autre, et c'est
volontaire — les signaux tarifaires sont nationaux. Aucune des deux n'est
annoncée comme livrée : les deux sont Roadmap, et les pages le disent.

Référence régénérée : en-têtes et libellés en anglais (Field/Type/Notes,
Supported models, Settings, Read-only, Brand / Model…). Conséquence assumée et
signalée : les pages FR en ligne changent aussi.

README.md (il était VIDE) : la règle du 95 % généré en tête, la frontière de
décision du multi-langue avec sa mesure, pourquoi SCAFFOLD existe, et le piège
--strict/navigation.instant.

TODO : multi-langue clos, et trois points ouverts qui en restent — les tagline
vivent dans les meta.json de 5 autres dépôts (forme à ajouter : tagline_de /
tagline_en), les stubs traduits restent des stubs (la dette éditoriale a triplé
en surface, pas en fond), api/types.md n'a pas besoin de variante. Le P1
openmeteo est corrigé sur constat : il EST dans PORTING_STATUS depuis, et une
ligne commentée contradictoire y traîne encore.

Vérifié : mkdocs build --strict vert sur les trois langues, 322 pages HTML,
contenu traduit relu dans le HTML produit, et les deux générateurs rendent
« Doc à jour » en --check.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-10-13 06:39:20 +02:00