← Retour aux issues

i18n in practice

publié le , mis à jour
Avatar Codeberg de laemlaem

Following the high level i18n issue !574, we'll talk here about the details of how to internationalize cartes.

As always, my native language is French so I write in French. Use e.g. Firefox's translate tool or Mistral LeChat to read this page if needed.

  1. Avatar Codeberg de laemlaem

    J'ai commencé à utiliser Lingui. Ça commence à marcher en suivant le guide Nextjs, mais un truc me chiffonne : ils recommandent de tout bouger app dans app/[lang]. À quoi ça sert ? Deux choses.

    1. ségmenter l'app en plusieurs blocs pour ne pas imposer aux utilisateurs fr le poids des traductions en. Sauf que dans notre cas, c'est anecdotique. La base de l'application n'a que quelques petits textes. Les traductions des tags OSM sont déjà faites via des requêtes fetch. La traduction des catégories de lieux ne pèse pas trop lourd non plus et pourrait être faite de façon asynchrone également. Bref, pour notre app (par opposition à un blog où le contenu texte représente beaucoup de poids), je ne vois pas trop l'intérêt

    2. ça sert surtout aux SEO. Les moteurs de recherche dans le passé étaient plus ou moins tous anglophones. L'en-tête HTTP accept-language (AL) nous permettrait au contraire aujourd'hui de localiser le contenu en fonction de la langue du navigateur de l'utilisateur (tout en ayant bien sûr un sélecteur de langue dans l'interface). Le Web n'est pas trop d'accord sur la question de si oui ou non Google gère bien cet en-tête.

    Le risque pour nous est évident : si Google requête cartes.app/?allez=Bistrot de la gare avec un AL en, ce bistrot ne sera jamais montré aux utilisateurs FR. Ça c'est la théorie. En pratique, il se peut A) que Google fasse maintenant des requêtes depuis plusieurs AL. Pour faciliter la découverte, il faudrait qu'on propose au moteur toutes les alternatives de cette page dans d'autres langes. Mais comment faire sans ce app/[lang] ? Un simple ?lang=fr pourrait permettre de forcer la langue, mais alors on revient un peu à la solution du préfixe de chemin [lang] mais en pire, car ces searchParams sont moins bien gérés en termes de rendu côté serveur.

    Vraiment l'idéal serait que les moteurs ne soient pas archaïques et gère tout ça correctement via une balise ou un réglage du site qui dirait "pour avoir la version espagnole du bistrot de la gare, utilisez simplement un AL es".

    De notre côté, ce [lang] introduit une complexité dans le code pour des gains pas si évidents, car le contenu à traduire est disons pour simplifier : 1 tiers sur le fond de carte / un tiers dans des fichiers YAML (comme le categories.yaml) / un tiers dans le JSX / un autre tiers (hehe) dans les traductions de tags OSM / un autre encore dans le blog / etc.

    Parlons du blog également, qui restera une grande source de contenu et d'attractivité.

    Nous avons déjà un système de traduction facile à utiliser.

    https://cartes.app/blog/nlnet-funding-2025 https://cartes.app/blog/bourse-nlnet-2025

    C'est bien mieux que d'avoir un préfixe en/fr et pas de traduction du titre. Ajouter ce préfixe n'apporte que très peu d'intérêt pour l'utilisateur : il est implicite dans le slug et l'app le trouve facilement dans les métadonnées de l'article.

  2. Avatar Codeberg de laemlaem

    Une solution double pourrait être un bon compromis.

    D'un côté, un utilisateur allemand n'a pas besoin d'être redirigé vers cartes.app/de/?allez=bistrot pour voir la page en allemand : son AL suffit.

    D'un autre, cet utilisateur allemand qui voudrait lire le site en anglais (ou un utilisateur dont la langue ne serait pas prise en charge mais qui voudrait lire en espagnol plutôt qu'en anglais, la langue par défaut) devrait pouvoir mémoriser son choix. Le local storage est une option, mais qui ne pourra être compris par le serveur, car seulement client. Le SP (search param, ?lang=es) en est une autre. Le préfixe [lang] aussi mais relou quand même de tout préfixer juste pour cet usage. L'option côté client n'est pas bête non plus : ce qu'on développe est une app, donc une grande partie est de toutes façon rendu côté client.

    Scenario avec cet utilisateur.

    Il va sur cartes.app, la langue anglais ne lui plait pas. Il choisit l'espagnol dans le menu déroulant. Un localstorage est mis à "lang: es". Il va sur le blog : le localstorage ne peut être lu que côté client, la traduction des éléments de l'interface peut nécessiter un flash. La redirection vers l'article de blog dans sa langue pareil. C'est pas fou, donc... si seulement il y avait un moyen d'écraser le Accept-Language pour un domaine entier...

  3. Avatar Codeberg de laemlaem
  4. Avatar Codeberg de laemlaem
    • voir si on peut utiliser ce guide Next pour utiliser Lingui sans /[lang]

    Oui on dirait, ici https://github.com/amannn/next-intl/issues/366 par exemple pour une autre lib.

  5. Avatar Codeberg de laemlaem

    Ce qu'on peut tester, c'est de mettre des liens

    <link rel="alternate" hreflang="de" href="https://cartes.app/?place=1902J09JD" /> <link rel="alternate" hreflang="en" href="https://cartes.app/?place=1902J09JD" /> <link rel="alternate" hreflang="fr" href="https://cartes.app/?place=1902J09JD" />

    Et la page en question doit renvoyer ce tag

    <html lang="de">

    ou le Content-Language HTTP header.

    Reste à voir si les moteurs vont comprendre. On peut dans tous les cas commencer avec le français par défaut pour ne pas pêter notre SEO. On a de toutes façon de gros progrès à faire, on part de loin.

    Si c'est pas le cas, il faudra qu'on fasse des URL explicites pour les navigateurs, tout en laissant les utilisateurs utiliser le site sans préfixe de langue, ils pourront arriver sur une page avec préfixe via les moteurs de recherche.

  6. Avatar Codeberg de laemlaem
    • gérer l'option de langue pour ouvrir n'importe quelle fichier dans une langue via l'URL
✏️ Participer à la discussion