You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A moyen terme, cartes.gouv.fr aura besoin qu'une partie de ses interfaces soient traduite dans d'autres langues pour des partenaires non francophones.
Il s'agit en amont de trouver un mécanisme de gestion de l'internationalisation qui rend la gestion des chaines internationalisées plus facile que l'existant.
L'existant c'est un seul fichier (par langue) contenant toutes les chaines de l'application : https://github.com/IGNF/cartes.gouv.fr/blob/main/translations/cartesgouvfr.fr.yml
Ce fichier est nécessaire pour les chaines à traduire côté serveur (messages de retour) mais il est également utilisé côté client par l'intermédiaire du package php willdurand/js-translation-bundle.
Il peut devenir facilement très volumineux et difficile à maintenir. L'expérience sur d'autres projets montre que les fichiers par langue peuvent rapidement devenir incohérents entre eux (au minimum au niveau de l'ordre des éléments) et que les clés inutilisées ne sont pas facilement identifiables (on oublie en général de les supprimer). L'arborescence des clés ne correspond parfois plus à la structure de l'application.
react-dsfr internationalise chaque composant indépendamment. Chaque composant contient les chaines nécessaires. L'inconvénient est la dispersion des chaines à traduire (ce qui rend complexe la traduction par un tiers non développeur) et une multiplication des doublons si certaines chaines sont utilisées dans plusieurs composants, mais l'avantage est une complexité moindre des clés et une proximité des chaines avec leur utilisation (même fichier).
Trouver un système d'internationalisation qui satisfait toute l'équipe : simple d'utilisation, avec un fallback sur une langue par défaut quand la chaine manque dans la langue souhaitée, qui permet d'identifier facilement les chaines inutilisées et les chaines manquantes...
s'astreindre à ne plus mettre de chaîne "en dur" dans le code, tout devrait passer par le système d'i18n.
Placer le sélecteur de langue (reporté à un moment ou suffisamment de contenus multilingues seront disponibles - échéance prévisionnelle mi-2024)
The text was updated successfully, but these errors were encountered:
Sans le sélecteur de langue, le changement se fait en ajoutant à l'URL : ?lang=en pour passer en anglais ou ?lang=fr pour repasser en français.
Cette manipulation n'est à faire qu'une seule fois, le changement de langue étant enregistré dans le stockage local du navigateur il s'applique pour toutes les pages et visites suivant le changement.
Très peu de contenu disponible en anglais à l'heure actuelle, mais en tout cas le ?lang=en permet bien d'afficher ces contenus et possède bien une rémanence en changeant de page.
Recette à poursuivre quand plus de contenu sera disponible, en particulier quand ce changement de langue sera disponible via un bouton/menu.
A moyen terme, cartes.gouv.fr aura besoin qu'une partie de ses interfaces soient traduite dans d'autres langues pour des partenaires non francophones.
Il s'agit en amont de trouver un mécanisme de gestion de l'internationalisation qui rend la gestion des chaines internationalisées plus facile que l'existant.
L'existant c'est un seul fichier (par langue) contenant toutes les chaines de l'application : https://github.com/IGNF/cartes.gouv.fr/blob/main/translations/cartesgouvfr.fr.yml
Ce fichier est nécessaire pour les chaines à traduire côté serveur (messages de retour) mais il est également utilisé côté client par l'intermédiaire du package php willdurand/js-translation-bundle.
Il peut devenir facilement très volumineux et difficile à maintenir. L'expérience sur d'autres projets montre que les fichiers par langue peuvent rapidement devenir incohérents entre eux (au minimum au niveau de l'ordre des éléments) et que les clés inutilisées ne sont pas facilement identifiables (on oublie en général de les supprimer). L'arborescence des clés ne correspond parfois plus à la structure de l'application.
react-dsfr internationalise chaque composant indépendamment. Chaque composant contient les chaines nécessaires. L'inconvénient est la dispersion des chaines à traduire (ce qui rend complexe la traduction par un tiers non développeur) et une multiplication des doublons si certaines chaines sont utilisées dans plusieurs composants, mais l'avantage est une complexité moindre des clés et une proximité des chaines avec leur utilisation (même fichier).
Placer le sélecteur de langue(reporté à un moment ou suffisamment de contenus multilingues seront disponibles - échéance prévisionnelle mi-2024)The text was updated successfully, but these errors were encountered: