Comment vérifier si votre site web est bien internationalisé.

Simon Mulquin
7 min readAug 26, 2024

--

Apprenez à parler à une audience internationale au delà des limites de i18n. (Available in English here)

Photo par Matthew TenBruggencate on Unsplash

Localisez les ressources graphiques

La première chose que je remarque sur un site web mal internationalisé, est généralement la présence d’images, vidéos ou autres ressources non traduites.

À titre d’exemple, un service d’organisation d’événements demande à un graphiste de créer tous les contenus imprimables pour annoncer l’événement et décidera plus tard de les utiliser sur le Web.

Sans aucune instruction, le graphiste crée des affiches et des flyers dans une seule langue et les livrera dans le but d’être utilisés dans un espace physique et monolingue.

Plus tard, l’porganisateur de l’événement réduira son budget et utilise ces mêmes ressources sur le Web après un peu de recadrage ou autres adaptations mineures.

Lorsque les participant à l’événement parlant une autre langue changent celle du site Web, ils verront aléatoirement des textes dans la mauvaise langue s’afficher sur les images ou démarreront des vidéos, téléchargeront des documents, etc. dans la mauvaise langue.

La solution à ce problème est assez simple à gérer mais elle nécessitera bien sûr que vous adaptiez la création et la livraison de ces ressource, ce qui peut être couteux.

La solution pour les petits budgets consiste à éliminer tous texte des ressources graphiques que vous publiez sur le web si celà est possible.

Cela peut poser un problème pour les vidéos et les documents PDF tels que les formulaires ou les tickets. Si vous souhaitez les rendre accessibles à un public international mais que votre budget est limité, vous pouvez adapter votre processus de localisation similaire en remplacant le travail humain par des technologies telles qu’un OCR ( Reconnaissance optique des caractères) ou du sous titrage automatique.

Le résultat sera mauvais et nuira au marché de la localisation (et donc à votre relation avec les agences ou traducteurs indépendants) mais ce serait trop partisan de ne pas mentionner que vous pouvez toujours faire ce choix si cela a du sens pour vous.

Que vous optiez pour un humain ou une machine, vous pouvez mettre en œuvre les deux solutions à l’aide de Crowdin grâce à leur fonctionnalité d’asset localization (lien en anglais uniquement) ou l’application de traduction d’image de Canva (lien en anglais uniquement).

Configurez vos intégrations pour interopérer la langue sélectionnée.

La deuxième chose que je remarque, c’est l’intégration d’outils dans le site web sans s’assurer que ceux-ci soient traduits.

Avez-vous déjà vu une carte, un diagramme, un formulaire ou un écran de connexion ou de paiement apparaître dans une langue aléatoire pendant que vous utilisiez un site web auquel vous accédez en Français ? J’ai subit cette situation quelques fois et c’est vraiment mauvais.

Les entreprises non internationales oublient souvent de définir la configuration appropriée lorsqu’elles intègrent ces outils, peut-être parce qu’elles copient aveuglément un lien d’intégration ou d’API sans lire les spécifications propres à l’internationalisation.

C’est dommage car les outils les plus populaires offrent souvent de telles fonctionnalités et elles sont très simples à utiliser, il suffit la plupart du temps de ne changer que deux caractères dans une URL mais beaucoup ne feront que copier coller l’URL aveuglément.

Une URL est une interface et comporte donc différentes fonctions définies par le développeur, il est toujours bon de comprendre ces fonctions avant de les intégrer à votre site internet.

Bon, vous pourriez penser que ce n’est pas un problème pour les entreprises internationales qui emploient de nombreux ingénieurs… Ce serait bien si c’était le cas bien sûr, mais… penchons nous la question.

Ces outils sont souvent implémentés de telle façon qu’ils tentent de détecter la langue de l’utilisateur afin d’assurer la continuité linguistique du service.

Premièrement, la détection de la langue de l’utilisateur peut donner des résultats différents selon la manière dont elle est mise en œuvre, ce qui devrait suffire pour comprendre que trop compter dessus n’est pas une bonne solution en terme de continuité.

Deuxièmement, les algorithmes de détection de langue ne se valent pas tous et peuvent être très mauvais.

Je suis né en Belgique, nous avons 3 langues officielles et j’ai été confronté à plusieurs reprises à de mauvaises pratiques de détection des langues avant même de savoir ce que signifiait l’internationalisation.

Des entreprises comme Samsung, Google ou Microsoft passaient aléatoirement du français au néerlandais quand on essayait d’utiliser leurs service normalement, ce qui rendrait la tâche très difficile.

Plus tard, lorsque j’ai déménagé successivement dans 4 nouveaux pays européens, j’ai fait l’expérience d’institutions étatiques proposant des services localisés conformément aux politiques de Schengen, mais partageant finalement un numéro de téléphone non localisé.

Le résultat est une experience frustrante dans laquelle plusieurs minutes d’utilisation aboutissent à un répondeur automatique dans une langue que vous ne comprenez pas.

Les intégrations sur le web ne sont pas que des API ou des liens embed, il s’agit parfois d’un simple numéro de téléphone menant à un service client qui lui n’est pas localisé.

Pensez donc à la finalité des informations que vous partagez et si celles-ci permettent une expérience localisée de facon continue ou pas.

S’il n’y a pas d’autre choix que d’intérrompre cette expérience, ne le faites pas brutalement, comme s’il s’agissait d’un bug ou d’un manque total de décence, préférez plutôt une approche informative clarifiant la limite de votre capacité à localizer cette partie du service.

Prévoyez aussi un moyen d’obtenir une aide personnelle ou, à défaut, ne localisez pas du tout car vous êtes peut être en train de dépenser des ressources pour développer un service que vous n’êtes de toute façon pas en mesure d’assurer.

Pensez découvrabilité

Une chose qui passera inaperçue lorsque vous testez votre site web, c’est sa capacité à être découvert par le public pour lequel il a été localisé.

La raison pour laquelle je dis que cela passera inaperçu est que si cette capacité n’est pas assurée, vous ne recevrez ni retours ni ne verrez de réèl problème lors des tests faits en amont du déploiement du site sur un serveur.

La découvrabilité est l’aspect stratégique qui a pour but d’indexer votre site web sur les moteurs de recherche ou d’assurer son partage sur les réseaux sociaux dans la bonne langue, mais pas seulement.

Cela peut également porter sur les partenariats de votre entreprise avec celles supposées amener des personnes à visiter votre site.

Supposons que vous vendez des voyages sur mesure en Francais et que vous souhaitez étendre vos services à l’Allemand, vous devrez très probablement travailler avec des agences de tourisme en Allemagne et adapter l’ensemble du processus de partenariat avant de pouvoir obtenir des résultats similaires à ceux que vous avez actuellement avec votre public francophone.

Si vous ne parvenez pas à rendre votre site web visible, vous aurez l’impression que vous avez dépensé de l’argent dans quelque chose que les gens ne veulent pas utiliser et vous ne saurez même pas pourquoi puisqu’ils ne savent même pas que cela existe et ne vous remonteront donc aucun problème.

Un site Web n’est pas seulement déployé sur un serveur et pour attirer passivement de nouveaux clients ou fournir des informations aux personnes qui en ont besoin, il est fourni par une organisation qui grâce à d’énormes efforts de marketing à partenariat ou d’optimisation du contenu, s’assure d’atteindre les bonnes personnes.

Naviguez sans interruption.

Vous vous souvenez du vieux monde ? Certaines personnes croyaient que la terre est plate et que si vous naviguez jusqu’au bout des mers, vous finnissiez par tomber dans le vide.

Par Orlando Ferguson — The History Blog, actually Library of Congress 2011594831, G3201.A67 1893 .F4, Public Domain, https://commons.wikimedia.org/w/index.php?curid=15853213

C’est exactement ce qui se passe quand vous cliquez sur un lien, attendez le le temps d’un chargement et découvrez avec surprise une page 404.

Même si la plupart des administrateurs de site Web savent qu’ils doivent éviter les liens vers des pages vierges, il arrive souvent que certaines pages ne soient pas traduites ou utilisent une URL basée sur un titre qui change donc en fonction de la langue.

Cela conduit finalement l’utilisateur à la page 404 alors que le site Web pourrait soit créer un lien vers la bonne page, soit ne pas afficher de lien de toute facon trompeur.

Disons que vous souhaitez ajouter un lien vers votre huile d’olive favorite sur votre blog, mais ce blog est localisé à la fois en Italien et en Francais

Si vous vous utilisez un lien statique dans votre blog, la version francophone affichera un lien vers super-huile qui sera le même pour la version en Italien alors qu’il devrait en réalité mener à la page super-olio.

C’est un gros problème puisque les locuteurs de l’Italien ne pourront pas accéder à la page traduite pour eux

A l’inverse si vous n’avez pas créé cette page, pourquoi les Italiens voudraient-ils avoir un gros bouton menant à votre page en Français ?

J’espère que ce petit article vous aidera à atteindre de une nouvelle audience et être plus inclusif à l’avenir, suivez-moi pour plus de contenu lié à l’internationalisation.

Je suis Freelance européen en protection des données, internationalisation et usages sociaux des technologies d’interprétation et exécution des processus métiers, j’écris sur des sujets à la frontière des systèmes d’information et de l’intérêt général.

--

--

Simon Mulquin
Simon Mulquin

Written by Simon Mulquin

Freelance in public interest; passionated by human sciences, territory development, internationalization and privacy; I write in french or english 🙂

No responses yet