325409dd3f
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>
2.0 KiB
AppData
Methods
AppData.Load
CONTROL
Retrieve an app data storage value that has previously been set with Store(). If no value had been set for this appId/key combination before, an empty value will be returned.
Parameters:
| Field | Type | Notes |
|---|---|---|
appId |
String |
|
key |
String |
|
group |
String |
optional |
Returns:
| Field | Type | Notes |
|---|---|---|
value |
String |
AppData.Store
CONFIGURE
Store an app data entry to the server. App data can be used by the client application to store configuration values. The app data storage is a key-value pair storage. Each entry value is identified by an appId, a key and optionally a group. The value data is a bytearray and can contain arbitrary data, such as a JSON map or image data, however, be aware of the maximum packet size for the used transport. This might be useful to a client application to sync settings across multiple instances of the same application. The group parameter might be used to create groups for this application. IMPORTANT: Currently no verification of the appId is done. The appid is merely a mechanism to prevent different different client apps from colliding by using the same key for data entries. This implies that the app data storage may not be suited for sensitive data given that anyone with a valid server token can read it.
Parameters:
| Field | Type | Notes |
|---|---|---|
appId |
String |
|
key |
String |
|
group |
String |
optional |
value |
String |
Returns:
No parameters.
Notifications
AppData.Changed
Emitted whenever the app data is changed on the server.
Parameters:
| Field | Type | Notes |
|---|---|---|
appId |
String |
|
key |
String |
|
group |
String |
optional |
value |
String |