Réflexion sur la traduction et l'i18n [WIP]

[laem]

À mon avis il faut adopter un format commun de diff pour la t8n et l'i18n.

# traduction du modèle France en langue anglaise
# data/lang/en.yaml
transport . avion . usager:
  question: Do you fly ?

transport . avion . court courrier . heures de vol:
  suggestions:
    super low: 393003
    middle low: 8934940


transport . avion . long courrier . vitesse moyenne:
  note: |
   We estimate the speed instead of asking the user the kilometers, he can't answer that.


# i18n du modèle france en modèle écosse
# data/country/GB-SCT.yaml

# fonctionnalité : diff par rapport à un autre modèle que la France, considéré par défaut comme le standard. Par exemple pour l'écosse, c'est bien plus pertinent de faire diverger le modèle UK que de faire diverger le modèle FR. 

transport . avion . long courrier . vitesse moyenne:
  formule: 6500 / 10
  note: |
    Because the ministry of aviation said so.

# i18n du modèle france en modèle polynésie
# data/country/PF.yaml

transport . avion:
  somme: 
    - vols internationaux
    - vols inter-île

transport . avion . vols internationaux: blabla

Algo :

• je parse le modèle de référence -> objet JS
• je parse le modèle alternatif : si le chemin de clef existe déjà, je les écrase. Sinon je les ajoute

La difficulté de notre côté serait de gérer les évolutions et conflits : si la France améliore le modèle avion et que la polynésie l'a réécrit entièrement, il faut trouver un moyen de les informer du fait qu'il y a eu des évolutions, charge à eux de les reprendre.

Ça demande à mon avis à trouver un moyen de dater nos variables avec leur date de dernière modification. Ce serait aussi super pour le SEO !

Ne pas oublier le système de template de publicodes. https://publi.codes/docs/m%C3%A9canismes#texte

On générerait donc des fichiers co2-modele-fr-lang-fr.json co2-modele-fr-lang-de.json

L'autre option étant de lancer une API du style : /ngc-data?lang=fr&modele=sct, et de cacher le résultat via un Nginx.