🏳️ Internationalisation

[laem]

Nous réfléchissons à l'internationalisation, c'est en cours, mais pas encore plug-and-play :)

Voir la discussion générale

Voir le travail en cours sur l'Outre mer

Ou une discussion plus technique

Suivre l'avancée des issues: Internationalisation - Roadmap

[EmileRolley]

(Brief) Meeting report \w @laem & @Clemog | 06-07-2022 |

Three main interrogations emerged and seem related to the internationalization (language & model):

1. How to make the existing model accessible for other languages?
2. Is there to adapt easily existing model without divergence ?
3. How to manage the divergence of models in the time?
4. How to have an intelligible UI for switching languages from the website?

Lexical translation

The first one can be solved with an (semi)-automatic translation of a rule file by using a translation table mapping each title and description to its corresponding translation -- a first version could be automatically generated with a translation tool such as DeepL before being refined by hand. Then, from this table and the source file, a new rule file is generated.

The suggested workflow consists of having a person in charge of maintaining the translation table for each targeted languages. Having a WUI may be necessary to facilitate the work of the translators.

Semantic diffing

However, when modifications are made in both the source and the target language, we can't simply translate one language to the other. This is why we might want to store semantic differences when a translation occurred. Therefore, the translator can simply apply wanted diffs when needed.

It could be interesting to study possibility to use semantic diff to deal with different models based on the same template. For european countries, difference might come from some changes of emission factor values (rule names would never changes). Yet, improvements on the French model should appear as well in other versions. We could use auto notifications to alert on these changes and let the referent translate, refine emission factors and accept the model changes or apply by default changes to other versions.

However, this could be easily become overwhelming to keep track of all changes when the two models differ significantly and we might want to assume that from a certain point the models evolved independently.

Storing models

The current mechanism consisting of having a PR for each model seems to be sufficient for the moment. But, when the number of models will increase this may become difficult to maintain. Therefore, a more sustainable solution should be found. For example, a first step could be to have dedicated repositories instead of branches, in this way model related issues could be separated and not being stack in the nosgestesclimat one.

UI

We can't agreed in the best way to design the UI for model switching.

Automatic localization

One approach developed in #482, consists in automatically tracking the current location of the user. But this can be intrusive.

One derivation of this approach, could be to ask to choose the language when the user is detected as being outside the France -- the user must still be located.

Let the user choose

A second approach consists in letting the user choose the country by him or herself. However, experience shows that a significant amount of user will skip the information and use the default model.

Custom domain names

The most pertinent approach might be to use a custom domain names for each country.

[Clemog]

Merci @EmileRolley ! J'ai complété un peu ton CR et je propose ce pad pour avoir la vision mind map (possible de compléter normalement) https://excalidraw.com/#room=ce6eb978c3696156ba34,SH36nARXCibuBDEdDTaXWA

[laem]

Mise à jour : on a pas mal parlé avec @EmileRolley à Bordeaux, et on se rend compte que le modèle qu'on a prévu avec un fork par pays n'est pas forcément une bonne idée.

@Clemog

Pourquoi ?

• Parce qu'il y a pas forcément beaucoup de modifications possibles pour un pays, pour avoir un premier modèle utilisable par les citoyens. Dans notre constat, la plupart des modifications sont valides à un certaine degré pour les autres pays. Par exemple, le fait de pouvoir sélectionner "pas de chauffage" est une norme en Guadeloupe, mais il y a surement des exceptions, en Guadeloupe (j'ai besoin d'un chauffage) comme en France métro (j'ai pas de chauffage, maison BBC). La climatisation demandée par la Guadeloupe est éminemment pertinente pour la France. Les ferries aussi.
• parce que la maille du pays n'est pas vraiment pertinente : il y a plus de différence entre la Sicile et la Lombardie qu'entre la Lombardie et la région Paca (mix électrique, mode de vie, etc.). Donc on s'en sort pas avec github/lombardie github/sicile etc.
• en cas de modification nécessaire sur le modèle, par exemple renommage de "somme" en "addition", devoir modifier 36 dépots sera très lourd, d'autant plus s'ils ne sont pas sous notre organisation datagir. On retrouve en fait les problèmes déjà constatés du fork, mais au niveau du fork du modèle (pas du site)
• on peut sans problème avoir un fichier par région qui modifie des attributs du modèle : "en Albanie, on fait beaucoup plus de scooter et moins de voitures, qui sont moins grosses -> variation des valeurs par défaut"
• on peut facilement publier une version "de base", avec un gros avertissement, en ne changeant que le facteur d'émission du mix électrique, et en variabilisant les calculs du modèle principal pour qu'ils utilisent au max cette variable centrale, qui dépend de la région et non pas du pays (sauf en France très centralisée, cf https://app.electricitymaps.com/map)

[laem]

Autre point : le modèle iframe permettrait à des organisations étrangères d'avoir l'impression de fournir un site (traduit et internationalisé) sans exposer l'URL nosgestesclimat.fr.

Par contre, ça ne résoud pas le problème de la disponibilité du calculateur pour tous les pays et ça enforce la mauvaise expérience utilisateur de l'iframe.

[laem]

Exemple de facteur d'émission qui sera à localiser : le biométhane. Il dépend fortement de la filière présente dans la région de simulation (pas encore intégré, voir #982 ) Comme on le voit ici. En Allemagne, de mémoire, on plante beaucoup de maïs pour faire du biométhane, ce qui change radicalement le résultat.

[Benjamin-Boisserie-ABC]

@laem Je pose ma question ici car ça me semble le bon endroit :

Est-ce qu'afin de faciliter l'internationalisation, le modèle de calcul ne devrait pas mettre à disposition un guide méthodologique qui prendrait un format plus classique (type Excel,pdf téléchargeable par exemple) ?

Le but de ce guide méthodo serait d'exposer les variables mères, les variables filles, petites filles, etc. hypothèses, sources, éventuellement des limites, etc. Un tel document me semblerait plus clair pour que les futurs réutilisateurs comprennent le modèle de calcul derrière NGC. L'exemple c'est d'ailleurs présenté tous récemment avec le CITEPA qui nous a demandé les règles de calcul. @Clemog a alors transmis un export des règles (mères) qui grâce à des noms explicites permet de se faire une idée des questions posées mais la encore si on nous avez demandé un export complet, ce listing de règles m'aurais semblé peu adapté sans organisation des variables entres elles. Ce genre de guide pourrait faciliter des tables de correspondances (dans une optique d'avoir une vue sur les modifications faites) ?

Il est vrai qu'on peut :

• naviguer dans le modèle via l'option "comprendre le calcul" en fin de simulation mais si on veut parcourir tout le modèle ce mode de navigation ne semble pas adapté
• se plonger dans github mais là encore ce n'est pas le plus simple pour comprendre ce qui est fait

Qu'en penses-tu @martinregner ?

[laem]

naviguer dans le modèle via l'option "comprendre le calcul" en fin de simulation mais si on veut parcourir tout le modèle ce mode de navigation ne semble pas adapté

Qu'est-ce qui te semble pas adapté dans la documentation en ligne, précisément ?

Notre modèle est devenu assez important aujourd'hui, il fait 6500 lignes (sans compter les actions plus qui sont du texte). Avant de l'exporter dans un tableur, il faut qu'on vérifie bien que ça profite à un certain public avec une contribution en échange.

Une chance de notre côté : l'équipe mon-entreprise.fr bosse sur une grosse amélioration de cette doc, qui ajoutera un menu à gauche pour naviguer entre les variables. Une autre amélioration pour rendre plus clair l'affichage de la documentation variable par variable. Globalement on a la main dessus également, on peut l'améliorer fonctionnalité par fonctionnalité si la contribution ou la lecture en dépend :)

Je vais mettre de l'ordre dans les tickets "documentation" sur le site.

Pour garder ce ticket sur le sujet internationalisation, on peut continuer la discussion sur https://github.com/datagir/nosgestesclimat-site/issues/484