Webi18n

[laem]

Désolé, ecore une PR juste commencée

Notre système de traduction de la base de règles n'est pas génial aujourd'hui. Externalize.js génère externalized.yaml avec des traductions de google quand elles n'ont pas été traduites par nos soins. On fait cette opération de mise à jour avec un script nodejs donc. De plus, on gère relativement bien les clefs de premier niveau dans une règle, mais pas les éléments plus complexes, comme les suggestions et les contrôles. La structure de externalized.yaml n'est as adaptée à ces derniers.

Au lieu de ça, il faudrait créer une page /i18n sur le site qui liste, règle par règle, le nombre d'oublis de traduction. Les règles traduites seraient une duplication de base.yaml, dans laquelle on traduirait les éléments qu'il faut traduire (nom, titre, description, suggestion.texte,valeur etc.). On doit donc éviter dans la base d'utiliser des clefs d'objet yaml come textes à afficher à l'utilisateur, d'où le commit 2edf324. On peut utiliser deep-diff pour repérer les trous (élément présent dans base.yaml mais pas traduite dans base.en.yaml, et afficher les résultats sur i18n. On améliore la traduction, le script de comparaison se relance, et ainsi de suite. La page /i18n représente l'état de la traduction.

#357

[johangirod]

Si on choisi d'utiliser locize.io pour nos traductions #412, je verrais bien le flow suivant, à chaque build de prod :

• Génération automatique d'un fichier de traduction namespacé depuis base.yaml (fr.yaml)
• Envoie du fichier de trad sur locize.io
• Récupération du fichier de trads anglaises depuis locize.io (en.yaml)
• Si une trad est manquante, le build fail.

Ça permet de s'assurer que notre moteur est toujours bien traduit. Cette étape de build pourrait également être lancée avant chaque publication du moteur sur npm.

[mquandalle]

Je me permet de fermer parce que la PR n'a pas bougé depuis un moment, on pourra ré-ouvrir ultérieurement.