Nous allons mettre en place cette semaine un nouveau système de traitement des plugins. Le changement est surtout un passage à jenkins pour le traitement des plugins. Globalement le processus sera :
La nuit à 00h01 le job de synchronisation avec github se lance
Si ya un nouveau numéro de commit alors :
- si beta, envoi à jenkins qui s’occupera de chercher les phrases à traduire et de générer le fichier json en fr. Il génère aussi les autres fichiers de langue (temporaire cette 2eme partie le temps de mettre en place l’alternative à transifex). Puis il commit tout cela sur votre git et prévient le market qu’il peu mettre à jour le zip pour les utilisateurs
- si stable, alors il met à jour le zip sur le market et demande à jenkins de mettre à jour le git global de documentations (pas encore utilisé, c’est pour plus tard).
Plus tard dans la partie beta, sera rajouté la partie traduction.
Ça a l’air de rien comme ça mais le passage à jenkins bien qu’étant une très bonne et pas une mince affaire, on va surveiller ça de près mais il risque d’avoir quand même des imprévus…
Donc si je comprend bien, plus besoin de générer les fichiers de traductions sur un « jeedom de dev » (sur lequel est activée l’option correspondante donc), les .json seront créés et commit automatiquement par votre job sous jenkins?
Et si nouvelle phrase dans un plugin existant, pareil? du coup, il réécrit le fichier ou le complète?
De manière général, et aussi car tu t’attends à des imprévus, ne serait-ce pas une meilleur option de commit dans un nouvelle branche (créé dynamiquement/automatiquement) et de faire un PR (que le dev doit approuver) plutôt que de commit sur la branch beta directement?
Cela donnerait plus de « confiance » au dev qui reste maitre de son repo (vu qu’il y a déjà eu des débats du genre)
oui plus besoin de générer des phrase le nouveau processus s’en occupe.
Pour les imprévu c’est pas la que je m’y attend la partie modification de votre git a été testé dans tout les sens et possède de nombreuse sécurité (je ne suis pas inconscient quand même). les imprevu c’est plus du genre j’ai mis a jour mon plugin sur git mais le market la pas pris.
Bonne nouvelle pour la génération des phrases, ca va faciliter la vie ca.
Pour la deuxième partie, je ne voulais pas sous-entendre que tu étais inconscient ni que tu n’avais pas testé
Même si pas d’imprévu je suis plutôt pour la création de branch + pr que de commit directement dans les branches de release (beta et stable) comme principe de gestion général (que ce soit pour ce process ou tout autre dev donc ma proposition valait de manière générale et ne se limitait pas aux traductions.
bref, si cela peut servir de tester le rollout, et vu que j’ai vu passer le job sur ifttt (notamment), tu peux l’activer pour mon plugin #plugin-rocketchat si c’est techniquement possible et utile pour toi.
Ce plugin n’est pas encore traduit par transifex (et les json ne sont pas encore généré).
En faite c’est deja actif pour tous les plugins juste faut qu’il change mais le job marche bien pas de soucis comme dis c’est plus au cas ou le market ne mets pas a jour votre plugin qu’il faut me contacter
je me permet de réagir, je vois que le nouveau moteur n’est pas passé sur mon plugin (plugin rosee, plugin que j’ai récupéré très récemment ),
Dans le plugin, il n’y a pas de dossier core/i8n; je viens de l’ajouter
Comme indiquer dans la doc Plugin template | plugin-template
Par contre, il faut que je fasse au moins de le fichier fr_FR.json ? pour moi oui si je comprends bien oui. Par contre le lien
i18n
C’est ici que votre traduction doit se trouver sous forme de fichier json (le mieux et de regarder par exemple le plugin zwave pour voir la forme du fichier)
Non, ma question était as-tu fait de nouveau commit, toi. Pas le système mais toi.
Le robot ne passera que s’il y a eu un nouveau commit d’après les explications de Loic, meme si les traductions ne sont pas encore là.
pour l’instant plus moyen de rafraichir une beta (pas essayé en stable), je veux dire que le bouton « Github beta » (dans la capture ci-dessous) ne permet plus de rafraichir la version du market; j’en ai besoin pour livrer une beta pour tester afin débloquer qlqun; j’espère que ca ira demain.
j’ai essayé le bouton « Générer traduction » (voir capture ci-dessous) en me disant que ca allait lancer le job (ce qui est le cas) et rafraichir le market automatiquement: cette partie n’a pas fonctionnée.
les fichiers json généré sont incomplets: sur mes fichiers j’ai perdu 80% des traductions: le manque principale c’est que le job ne voit pas les labels généré dans une boucle, par exemple issue d’un json lors de la création d’équipement et commandes dans une boucle
J’ai des fichiers de définitions pour mes équipements avec leurs commandes dans des .json et en fonction des équipements trouvés, le code boucle et créé toutes les commandes => tous les noms de commandes concerné ne sont pas vu (logique en fait si c’est une analyse statique)
Je pense être loin d’être le seul dans ce cas, rien que les plugin de protocol (zwave, rfx, …) auront le problème
les traductions faites (je n’avais pas compris que ca allait être le cas) sont en fait vraiment foireuses, c’est du très mauvais anglais (outils automatique?), c’est complétement inutilisable;
exemple les plus criant:
le mot « action » est traduit par « stock » (= action en bourse).
Et vu que le commit est fait directement dans ma branch beta, je ne peux meme pas rejeter le PR; franchement travailler en PR devrait être une obligation; là je vais devoir m’amuser pour revenir en arrière sur le commit foireux fait par jeekins et ca ne sert à rien puisque si je refait un commit pour corriger demain il va refaire un commit foireux.
Quel droit dois-je retirer pour ne plus laisser générer les traductions par le robot mais tout de même laisser la documentation disponible sur le site officiel?
Bonjour
Je m’y attendais de toute façon le moindre changement va jamais… Je vais répondre à tes questions et prendrai un peu de distance après :
traduction dans des boucles sur des variables ça devrait jamais être le cas la méthode utilisée est pas la bonne
traduction disparu c’est que le texte n’est plus dans le code ou que tu veux traduire une variable (c’est pas une bonne pratique)
forcé la beta devrait marcher ça peut juste prendre plusieurs heure
les traductions sont faite par Google translate si ça n’a pas été traduit avant, si la traduction va pas il suffit de mettre celle que tu voudrais (j’ai juste un soucis quand la traduction est identique a la phrase a traduire mais je travail dessus)
Pour le pr je ne sais pas et vu tes retours le mieux est que tu ailles décocher la case qui autorise le market a gérer les traductions et la documentation comme ça tu pourras être parfaitement autonome.
Ce matin (tôt, avant 8h) la synchro market ne fonctionnait toujours pas, je confirme qu’elle fonctionne à présent.
Concernant ton message précédent, je voudrais recadrer un peu quand même.
Je suis venu avec des faits concrets que j’ai essayé d’expliquer et de justifier le mieux possible, j’ai passé ma soirée hier soir à valider tout ce que je faisais pour ne pas venir avec juste un message « ca ne marche pas », j’espère que tu as remarqué cette approche que j’ai eu sur tous les sujets que je t’ai remonté: quand je contacte, jusqu’à présent, c’est avec du concret et que j’ai mis le doigt sur quelque chose…
Et dans mon message j’ai tenté d’éviter tout coté émotionnel (alors que j’ai effectivement perdu pas mal de temps hier soir la dessus et que j’étais énervé);
Je n’ai absolument pas dit que « jamais rien n’allait » et cela n’a jamais été le cas lors de mes interventions sur ce forum, ni envers toi ni envers les autres. Au contraire il me semble. J’ai même souligné les avantages que je voyais au nouveau système dans mes messages précédents.
Pour revenir sur le fond et sur tes réponses, voici mon retour:
Alors là, c’est incorrecte, tu n’as probablement pas compris l’approche et je n’ai pas bien expliqué.
Et prétendre de frond que ce n’est juste pas la bonne méthode… parce qu’il n’y en a qu’une?
J’ai un fichier json avec mes configs et 1 (un) bout de code (genre 10 lignes) qui génère toutes mes commandes.
Et je ne l’ai pas inventé, c’est ce qui est fait dans plugin-blea , plugin-openzwave, plugin-rfxcom pour ne citer que des plugins officiels; dès que t’as une dizaine d’équipements différents possible pour un plugin ca n’est plus très efficace de tous les coder en php à mon humble avis;
mais dans tous les cas, je ne fais qu’utiliser les fonctions classiques du core etc, je n’ai fait aucune entourloupe ici, tu ne peux pas dire que « ce n’est pas bon ».
Non c’est faux, outre les traductions manquantes des commandes car une analyse statique du code est incapable de les voir (logique mais c’est un manque) il y a d’autres impacts: il ne retrouve pas les traductions qui existaient et retraduit, peut-être du au fait que le path à changé? (d’ailleurs est-ce que cela va fonctionner dans jeedom? je n’ai pas testé encore)
exemple extrait du commit :
anciennement on avait donc plugins\arlo/desktop/modal/health.php" avec le path qui commence à plugins\arlo
On peut voir que « Mode » anciennement traduit en « Mode » est maintenant traduit par « Fashion »
C’est dans le commit, je ne l’invente pas, tu pourrais aller vérifier toi même si tu voulais vu que tu as accès.
Mais autre exemple sur le plugin jeedom « mode »; donc il y a aussi un problème pour un des plugins jeedom que tu gères
"core\/class\/mode.class.php": {
"Mode": "Fashion",
"Mode precedent": "Previous mode",
"Retour mode précedent": "Return to previous mode",
"Erreur lors de l\\'éxecution de ": "Error while executing",
". Détails : ": ". Details:",
"La commande de mode courant est introuvable": "Current mode command not found"
}
le path est changé et « Mode » est à présent traduit par « Fashion »
Donc je persiste: les traductions ont été faite même si elles existaient déjà.
Et je répète, outre le problème de traduction loufoque issu d’une traduction automatique, le changement dans le path ne risque-t-il pas d’être un problème? (je n’ai pas encore testé ca)
