Discussion :

[Stéphane le calme]

Les sites doivent-ils s'appuyer sur les adresses IP des internautes pour déterminer la langue à afficher
ou alors s'intéresser à d'autres éléments ?

« 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

[TiranusKBX]

Sur mes dev je me base déjà sur l'en-tête HTTP Accept-Language mais je laisse toujours ensuite la possibilité de choisir dans la liste de langage supportés

[tomlev]

Ça m'énerve les sites qui ignorent l'en-tête Accept-Language... A la rigueur, utiliser l'adresse IP si le header n'est pas présent, je veux bien, mais le header indique clairement la préférence de l'utilisateur et devrait être utilisé en priorité.

D'ailleurs j'aimerais bien pouvoir définir mes préférences de langue différemment selon les sites... Quand c'est des sites français, je veux les voir en français, mais je veux pas voir de version française d'un site anglophone.

[e101mk2]

Alors je vais répondre simplement, un français a l'étrangers, disposants de son propre équipement (ordinateurs, smartphone)..., qui eux sont en français (et envoie donc l'entête).
Pourquoi doivent il chercher dans la moitié des sites internets la fonction française alors qu'elles sont disponible habituellement avec le même équipements chez eux?

Donc non, l'adresse IP ne permet pas de déterminer la langue préférer de son utilisateur, le navigateur lui le peux (si il est disponible dans la langue/ou qu'il ce base sur celle de l'os) !

[TiranusKBX]

L'usage de l'ip tel qu'utilisé actuellement est plus utilisé pour la segmentation des marchés, c'est la solution qui par exemple permet de localiser le droit à l'oublis uniquement en Europe pour Google

[jopopmk]

Et si je ne comprends pas l'anglais, even slightly, je fais comment pour répondre à sa première dialogbox ?

[Excellion]

Bon courage à ceux qui utilisent Tor... 😂

[miaous]

Et si je ne comprends pas l'anglais, even slightly, je fais comment pour répondre à sa première dialogbox ?

je pense que l'exemple est un boite de dialogue d'un navigateur (donc elle sera dans ta langue ).
sinon si tu vois "English" avec un petit triangle tu peux penser à un menu et si tu changes la langue , tout le texte est traduit automatiquement.
au pire tu rajoute un drapeau à coté de "English".

[LSMetag]

L'user-agent du navigateur serait suffisant voire préférable. Les Français à l'étranger n'auraient plus le problème de langue. Et puis c'est moins intrusif niveau vie privée. Après ceux qui changent cet User-Agent assument. Ils peuvent aussi en profiter pour s'exercer à des langues étrangères par ce biais et garder la langue qu'ils souhaitent malgré un VPN étranger.

Sans oublier que l'adresse IP est plus compliquée à capturer côté client (il faut utiliser un service tiers ce qui peut provoquer une faille de sécurité) et que côté serveur c'est une porte ouverte à leur interception. L'user-agent peut être facilement capturé côté client, et fourni en paramètre avec moins de risque sur une requête Ajax ou WebSocket. Au pire on apprends que tu utilises tel navigateur, de telle version, avec telle langue, mais on a aucune information sur l'identité de l'utilisateur.

Je réserve l'utilisation d'adresse IP seulement pour le bannissement de personnes indélicates, ou pour du métier pour certains types d'applications.

[CoderInTheDark]

J'en profite pour ramener ma fraise sur l'accessibilité.
Ce n'est pas exactement le sujet, mais c'est important.

N'oubliez pas de préciser la langue du contenu avec
<html lang="fr">

Si ce n'est pas fait, le lecteur d'écran peut essayer de lire le document en anglais, et c'est super lourd de comprendre du français prononcé avec un accent anglais

En règle général je veux me caller sur la langue d'origine du site.
Mais je ne vais pas souvent à l'étranger avec mon ordinateur, alors je n'ai pass assez de recul

[Doksuri]

je pense que l'ip doit etre un complement

ip + entete + navigator.language

navigator.languages (array)

perso, l'ip serait la priorite la plus basse

[Kdence]

J'ai envie de dire non... Je vis en Suisse et on a pas moins de 4 langues nationales. Du coup je me retrouve souvent sur des site qui s'affichent en allemand, langue que je ne parle absolument pas malgré que ce soit l'une des langues de mon pays...

Outre l'en-tête HTTP et l'objet "navigator" en JS, je pense que le plus simple est encore de proposer à l'utilisateur la possibilité de changer de langue de manière claire, parce que des fois on doit scroller toute une page et si reprendre à 10 fois avant de réussir à "taper" un minuscule lien en bas de page... Et puis bon les redirection non souhaitées pour changer automatiquement la langue je m'en passerais bien... Parce que quand l'équipe de dév ne sait pas faire son boulot et qu'ils te redirige vers la langue qu'ils ont jugé bon de te faire subir à chaque fois que tu remet ta langue favorite (coucou Origin)...