Github action pour traduire vos plugins 🌐

[Mips]

Bonjour,

TL;DR

Le code et la documentation sont là: GitHub - Mips2648/plugins-translations

yml d’un workflow typique pouvant être réutilisé sur vos repos (dans .github/workflows/translations.yml):

name: translate

on:
  workflow_dispatch:
  push:
    branches:
      - beta

jobs:
  auto-translate:
    runs-on: ubuntu-latest
    steps:
      - uses: Mips2648/plugins-translations@v1
        with:
          deepl_api_key: ${{ secrets.DEEPL_API_KEY }}

il faut donner les droits d’écriture et PR à github action dans les settings de votre repo:

en bas:

ce workflow va faire le boulot et ensuite créer un PR sur la branch sur laquelle le workflow a tourné

A vous de valider … ou pas et plus besoin de s’en occuper, ca va tourner à chaque changement que vous faites.

Dans l’esprit de traduitjdm, je vous présente aujourd’hui un tool permettant également de gérer les fichiers de traductions de vos plugins.

Vous l’avez peut-être remarqué avec les posts précédents (outils d’install des dépendances & base de démon python): je suis paresseux et j’ai beaucoup de plugins à maintenir donc je ne veux pas faire d’actions répétitives et tout ce qui peut être automatisé, doit être automatisé

Donc si la méthode pour retrouver les chaines à traduire est quasi identique (analyse statique du code source), l’approche est différente car tout repose sur … une action Github (le titre est bien choisi ) déclenchée automatiquement lors de chaque push sur une branche et de là, toutes les traductions sont faites automatiquement, les fichiers sont mis à jour et un PR est généré sur la branch que je n’ai plus qu’à valider !

• L’outil prend en charge les 6 langues suivantes (celles sélectionnables dans la page de config jeedom): fr_FR,en_US,es_ES,de_DE,it_IT,pt_PT
• La langue source peut être celle de votre choix: fr_FR par défaut mais si vous voulez écrire votre plugin avec tous les prompts en anglais, c’est possible!
• lors de la découverte de nouveaux textes à traduire, le tool va regarder en priorité dans les traductions existantes du plugin, ensuite du core, ensuite traduire automatiquement via deepl si vous avez renseigné une clé api comme expliqué dans la documentation (compte gratuit donnant droit à 500.000 caractères par mois, c’est plus qu’assez pour 50 à 100 plugins par mois!)

Les plus patients d’entre-vous peuvent cliquer sur le résumé ci-dessus à présent

et si vous avez une question ou suggestion (c’est pas dit que je dise oui à tout ), la discussion est ouverte

C’est encore une version « beta » même si pas mal testée mais essayez sans crainte, au pire vous n’acceptez pas le PR qui sera fait donc aucun risque d’impact sur votre code

edit: j’ai créé un tag ga-translations (ga = Github Action mais s’il faut renommer pour que ca soit plus clair dites-moi)
Je propose de:

• créer un nouveau sujet dans la caégorie Aide Traduction avec le tag ga-translations s’il y a des questions sur l’utilisation du workflow
• créer un nouveau sujet dans la catégorie Aide Traduction sans ce tag s’il y a des questions plus générale sur les traductions sous Jeedom
• je laisse ce sujet ouvert s’il y a des infos à communiquer ou préciser en rapport avec le workflow

[nebz]

Mis en place sur tous mes plugins, fonctionne à merveille et plus besoin de se soucier de rien !!!

[Mips]

Merci pour l’accompagnement pendant la phase « tests alpha »

[Loic]

Salut,

Jolie je regarderais ca se trouve c’est meme mieux que notre système officiel !!!

[Flobul]

Testé sur un plugin et c’est nickel.
Je suis reparti d’une langue fr_FR de base en supprimant les autres langues, certaines lignes non traduites avec traduitjdm ne n’étaient pas traduites non plus. (__AT__)

[Mips]

Je ne l’ai pas précisé dans la doc mais:

• si un fichier est absent, le core va afficher la clé (donc le texte non traduit)
• si une clé est absente d’un fichier, pareil le core affiche le texte non traduit
• si une clé est présente mais pas de traduction, le core affiche aussi le texte non traduit

C’est pour cela que par défaut les fichiers ne sont pas générés s’il n’y a rien à y mettre et qu’il existe l’option pour ne pas générer les entrées sans traductions => c’est légèrement plus optimisé à l’affichage puisque le core stop la recherche un peu plus tôt mais je pense que c’est négligeable.
Donc par défaut les fichiers sont générés avec traduction vide (si vous n’avez pas activé deepl), cela permet de repérer très vite les traductions manquantes à complétée manuellement tout en n’ayant aucun impact sur votre plugin (il peut partir en beta/stable comme ça, au pire il n’est qu’à moitié traduit)…

mais lorsque vous aurez gouté au traduction full auto, vous ne reviendrez pas en arrière

[nebz]

@Mips

mais lorsque vous aurez gouté au traduction full auto, vous ne reviendrez pas en arrière

Oui c’est même grisant de déployer sur tous les plugins

Il traduit aussi la description du plugin dans info.json (@Loic dommage que utilization ne soit pas traduisible en passant ) voir le nom en lui même !

Reste plus que la traduction de la doc

[Mips]

Concernant la doc, j’avais (évidement) ca en tête aussi
le fait est que perso j’ai un repo séparé pour toute ma doc et que j’ai déjà un pipeline de traduction semi-auto dessus depuis des années donc ce n’était pas ma priorité (que je peux documenter si certains sont intéressés)

Mais cela serait possible de rajouter cela; la difficulté c’est de savoir quelle phrase correspond à quelle traduction lorsqu’il y a un changement du contenu et donc en auto ca reviendra vite à tout retraduire à chaque fois; à voir ce que ca donne en terme de « consommation » de quota.

[nebz]

Apparemment 12500 mots sur ma plus grosse doc x 5, ça va

Ou tu fais un diff et tu ne traduits que la diff

[Mips]

ou je « stock » chaque ligne du md avec la traduction générée pour les réutiliser aux runs suivants, ca deviendra une mémoire de traduction en quelque sorte.

Une version après pourrait même calculer la distance entre 2 chaines (genre distance de Levenshtein) pour « suggérer » une ancienne traduction sans rapprochant, voir la réutiliser automatiquement selon un pourcentage défini par le workflow

bref, il y a moyen de s’amuser
faut pas que ca devienne trop long non plus, je note l’idée et on va laisser mûrir quelques nuits

[nebz]

Avec la température ça va mûrir plus vite non ?

[Loic]

C’est ce que j’ai fait pour le système officiel en gros chaque traduction est stocké en base de données. Quand y’a besoin de traduire une phrase (je découpe pas phrase dans les doc c’est le plus compliqué surtout quand y’a des morceaux à pas traduire) je regarde d’abord dans le plugin lui même si elle existe déjà (le json mais aussi ce que j’ai traduis pour la doc) si ça existe pas je regarde dans la base globale (le core et tous les plugins) si ça existe pas je demande à Google de traduire la phrase.

[Flobul]

486 673 caractères pour 15 plugins faits. M’en reste 1

[Mips]

mais comment est-ce possible?

je suis à 274.000 pour plus de 25 plugins dans les 5 langues (y compris tous mes tests pendant le développement)

t’écris des romans?

[Flobul]

J’ai des plugins avec des traductions de noms de commandes énormes. (Smartthigns/homeconnect/lgthinq)

[nebz]

Ou alors tu as fait comme moi les premières fois… mis en place le yml et puis fait plusieurs modifications qui chaque fois relancent une nouvelle traduction par deepl.

Du coup la solution c’est de mettre en place le yml, puis merger le pr et ensuite on fait les modifs nécessaires

[sagitaz]

Merci

Mis en place sur import2calendar et frigate.

J’utilisais déjà Deepl pour les traductions du plugin JeeMate, mais à la main, quel gain de temps

[Xav-74]

Merci 1000 fois @Mips !!

Je repoussai la partie traduction de mes plugins de jour en jour
Je viens de mettre en place le workflow pour le plugin percelTracking. Résultat bluffant en moins de 15min !

Au boulot pour Verisure et myBMW

[vedrine]

Un immense bravo à toi @Mips je viens de le mettre en place pour les plugins Elm Touch, Sure Petcare et Wled et çà marche du tonnerre.
Je ne suis capable de juger que la traduction en anglais mais j’ai fait très peu de retouches.

[Xav-74]

Hello @Mips,

En peaufinant les trad du plugin parcelTracking, je m’aperçois que les fichiers des widgets (dashboard et mobile) ne sont pas traduits.
Envisageable de rajouter cela si techniquement possible ? Ou sinon comment fais-tu pour tes widgets ?
Merci d’avance

Xav