Les sites doivent-ils s'appuyer sur les adresses IP pour déterminer la langue à afficher

« Récemment, j'ai fait un voyage en Europe. Quand je suis arrivé à Berlin, j'ai ouvert mon ordinateur portable et suis allé sur Google. À ma grande surprise, malgré ma connexion, les résultats m’ont été retournés en allemand », a remarqué le développeur McKenzie.

« D'autres sites populaires sur lesquels je me suis rendu m’ont soudainement renvoyé leur version allemande. J’ai été redirigé de .com à .de et je devais chercher un lien “Passer en anglais“ ou essayer d'exécuter un traducteur sur le site », a-t-il continué.

Il a été très étonné de voir les sites se comporter comme ça. D’autant plus que, comme il le rappelle, les navigateurs web demandent dès leur première configuration en quelle langue l’utilisateur souhaite voir afficher les textes. Pourtant, cette configuration est totalement ignorée et l’adresse IP est utilisée à la place.

Mais pour quelles raisons ? Selon le Mozilla Developer Network, l’en-tête HTTP Accept-Language, qui définit la langue que l’utilisateur souhaite voir afficher à son écran et donc qu’il est capable de comprendre, est un indice à utiliser lorsque le serveur n’a aucun moyen de déterminer la langue à afficher d’une autre manière.

Une discussion avait également été ouverte dans ce sens au sein de la W3C. L’organisme de standardisation avait alors avancé que « l'en-tête HTTP Accept-Language était à l'origine uniquement destiné à spécifier la langue de l'utilisateur. Cependant, étant donné que de nombreuses applications doivent connaître les paramètres régionaux de l'utilisateur, une pratique courante est d’utiliser Accept-Language pour déterminer cette information. Il n'est pas judicieux d'utiliser UNIQUEMENT l'en-tête HTTP Accept-Language pour déterminer les paramètres régionaux de l'utilisateur. Si vous utilisez Accept-Language exclusivement, vous pouvez confiner l'utilisateur dans un ensemble de choix qui ne lui conviennent pas ».

Comme le rappelle McKenzie, l’entête HTTP Accept-Language permet à un utilisateur d’énumérer les langues qu’il est capable de comprendre/dans lesquelles il est capable de s’exprimer et de préciser son degré de préférence. À ce propos, la W3C indique que « Chaque plage de langue PEUT être dotée d'une valeur de qualité associée qui représente une estimation de la préférence de l'utilisateur pour les langues spécifiées par cette plage. La valeur de qualité par défaut est "q = 1". Par exemple, Accept-Language: da, en-gb; q = 0.8, en; q = 0.7 Signifierait : "Je préfère le danois, mais accepterais l'anglais britannique et d'autres types d'anglais" ».

Dès lors, McKenzie propose déjà une amélioration de l’interface utilisateur pour marquer ces préférences.


« Puisque la connaissance et la préférence sont conceptuellement distinctes (vous pourriez connaître deux langues au même degré, mais en préférer une), on pourrait élaborer cette interface en demandant à l'utilisateur de choisir d'abord ses langues préférées, puis vous pouvez affiner les valeurs “q” basées sur cette commande. Une autre option serait de demander à l'utilisateur de choisir une langue favorite s'il prétendait être “nativement/excellent” dans plusieurs langues », propose McKenzie.
.
Mais quel problème voit-il avec le fait de se baser sur l’adresse IP pour définir la langue affichée ? « Dans un proche avenir, non seulement les migrations internationales devraient augmenter, mais en plus, dans de nombreuses régions, il existe une langue locale, une langue nationale et une langue internationale (exemple : gujarati, hindi et anglais pour les 60 millions de personnes du Gujarat, en Inde) », affirme-t-il.

« Dans d'autres endroits, comme le métro de New York, au moins 192 langues différentes sont parlées à la maison. À Los Angeles, 54 % des foyers utilisent des langues autres que l'anglais. Ces chiffres continueront d'augmenter. C'est pourquoi emmener les utilisateurs à indiquer leurs préférences est important », a-t-il continué.

Source : billet McKenzie, W3C (Accept-Language pour les paramètres régionaux), W3C