Utiliser la touche d'accès n pour naviguer au sein de la page. Sauter au début du contenu.

Ce document est une traduction. En cas de divergences ou d'erreurs, la dernière version originale en anglais fait autorité. Comme indiqué ci-dessous, les droits d'auteur reviennent au W3C.

Traducteur: François Yergeau

s_gotoW3cHome Internationalisation
 

Quand faut-il utiliser la négociation de langue ?

Public visé : webmasters, server administrators, and anyone who wants to better understand language-based content negotiation.

Question

Quand est-ce une bonne idée (ou non) d'utiliser la négociation de langue ?

Contexte

La négociation de langue est une fonction du protocole HTTP qui permet à un serveur de choisir parmi plusieurs versions linguistiques d'une page, en se basant sur l'URL et sur des préférences exprimées par le fureteur (précisément dans l'en-tête Accept-Language). On la distingue d'un choix de page fondé sur l'adresse IP du fureteur ou encore d'un choix manuel par le visiteur dans une page de sélection de langue. S'il n'y a pas de correspondance entre les préférences exprimées par le fureteur et les langues disponibles sur le serveur, soit une page de sélection de langue est montrée, soit une langue par défaut est choisie.

Dans bien des cas, le réglage initial du fureteur est adéquat. Une version japonaise d'un fureteur, par exemple, supposera que vous préférez le japonais et communiquera cette préférence au serveur. Tel que mentionné dans l'article Ajuster les préférences linguistiques d'un fureteur, les fureteurs grand public permettent d'ajuster ce réglage.

Cette FAQ aborde la question de savoir quand il faut (ou non) implanter la négociation de langue.

Réponse

Réponse courte : toujours.

Réponse un peu plus longue : presque toujours, mais pas toute seule.

La négociation de langue ne donne pas toujours le résultat escompté; il y a moyen de pallier les imperfections; il importe aussi de fournir de l'adhérence dans la navigation.

Imperfections de la négociation de langue

La négociation de langue est clairement une chose utile, mais avant de l'implanter partout il convient de bien comprendre ses limites. Pour les illustrer, nous prendrons l'exemple du site www.exemple.be, qui offre son contenu en flamand, en français et en allemand, qui implante la négociation de langue et qui choisit de servir les pages en flamand par défaut. Notre visiteuse, Sylvia, parle italien mais se débrouille en allemand. Plusieurs cas peuvent se présenter :

  1. Le fureteur de Sylvia est bien configuré, exprimant ses préférences pour l'italien suivi de l'allemand. L'italien n'est pas disponible sur www.exemple.be, les pages apparaissent en allemand, Sylvia est plutôt contente, tout va bien. C'est à ça que sert la négociation de langue !
  2. Sylvia n'est pas une personne technique, elle n'a jamais entendu parler de négociation de langue ni senti le besoin de tripoter les réglages de son fureteur. Celui-ci est une version italienne qui est implicitement réglé pour exprimer une préférence pour l'italien (comme il se doit). En arrivant sur www.exemple.be, l'italien n'est pas disponible et le flamand (langue par défaut du site) est rendu, même si l'allemand est disponible. Mauvais.
  3. Sylvia n'utilise pas son propre fureteur, elle navigue depuis un café internet à Moscou. Le fureteur est configuré pour demander du russe. Sylvia obtient encore du flamand. Mauvais.

Conclusion : la négociation de langue ne donne pas toujours le résultat escompté.

De plus, la négociation de langue n'est même pas pertinente quand les pages ne sont pas équivalentes, c'est à dire quand elles n'ont pas essentiellement le même contenu en des langues différentes. On pourra consulter l'article Les sites web unilingues et multilingues à ce sujet, notamment les sous-sections « Multilingue, même contenu » et « Multilingue, contenu changé ». Notons toutefois qu'une certaine mesure d'adaptation culturelle (changer la devise par ex.) ne rend pas nécessairement les pages non-équivalentes ; ce cas se présente vraiment lorsqu'un site est adapté de façon à ce que les pages en différentes langues ne correspondent plus.

Pallier les imperfections

Malgré ses limites, la négociation de langue est une fonction utile et il est souhaitable de l'implanter dans les sites multilingues. Mais il faut pallier les imperfections. En bref, il faut permettre au visiteur de prévaloir sur le choix automatique de langue, lorsque ce dernier est erroné. Pour ce faire, on incluera dans la page des éléments de navigation (qu'on appellera contrôles de langue ici) menant aux autres langues. Ces contrôles doivent être bien visibles et de plus compréhensibles par un visiteur qui ne connaît pas la langue de la page présentement affichée.

Une question se pose : est-ce qu'on doit implanter la négociation automatique et fournir des contrôles de langue dans toutes les pages, ou seulement la page d'accueil ? La meilleure réponse est « toutes les pages », sauf celles qui ne sont pas suffisamment equivalentes. La négociation de langue est utile parce que, si Jaap envoie un lien pointant dans www.exemple.be à Pierre, Pierre sera content de voir la page en français, même si Jaap a lu la version flamande. Les contrôles de langues doivent aussi être implantés, même si la négociation de langue ne l'est pas. Sans négociation, Pierre aura besoin d'un contrôle pour atteindre la version française du lien de Jaap ; même avec négociation, Sylvia devra passer manuellement à l'allemand dans les cas 2 et 3 ci-dessus.

En passant, certains sites présentent une page spéciale de choix de langue quand il n'y a pas correspondance entre les préférences du visiteur et les langues disponibles (ce que pourrait faire www.exemple.be au lieu de rendre la page en flamand). Une telle page a l'avantage de rendre la situation claire et de ne pas donner préséance à une langue plutôt qu'une autre, ce qui peut être politiquement délicat. Malheureusement, certains sites présentent toujours une telle page (pour la page d'accueil), au lieu d'implanter la négociation de langue. On force ainsi tout le monde à toujours transiter par cette page, sans avantage apparent. Mauvaise ergonomie.

Navigation

Sylvia visite www.example.be and obtient du flamand (cas 2 ou 3). Elle clique alors sur le contrôle « allemand » et continue à lire, pas de grand malheur. Mais elle suit alors un lien vers une page qui l'intéresse dans le site : oups ! encore du flamand ! Le contrôle « allemand » est toujours là, mais après quelques uns de ces détours inutiles, la frustration s'installe. Est-ce que www.exemple.be ne pourrait pas se rappeler qu'elle ne lit pas le flamand, nom d'une pipe ? Ce qu'il faut ici, c'est un peu d'adhérence de son choix explicite de langue.

www.example.be peut fournir cette adhérence de deux ou trois manières. Le bon choix dépend de la technologie disponible sur le serveur et de l'effort qu'on veut y mettre.

Si le site implante un mécanisme de session (par exemple en utilisant des témoins), il est assez simple de s'arranger pour que le choix de langue fasse partie de l'état de la session. Quand Sylvia clique sur le contrôle « allemand », ce choix est stocké (soit dans le témoin lui-même, soit dans le serveur, en correspondance avec un numéro de session stocké dans le témoin) et par la suite elle obtient de l'allemand en naviguant dans le site. Le témoin peut même être rendu persistant (mais attention aux problèmes de vie privée), auquel cas Sylvia verra de l'allemand automatiquement lors de sa prochaine visite à www.exemple.be. Les sites qui ont un mécanisme d'enregistrement (login) peuvent aussi stocker des préférences de langue dans le profil de chaque utilisateur et présenter les pages en conséquence. La négociation de langue n'est alors utilisée que pour les visiteurs qui ne sont pas encore identifiés.

Un autre moyen d'éviter la frustration est de rendre tous les liens à l'intérieur d'un site spécifiques à la langue. Dans la page d'accueil en allemand, tous les liens seraient de la forme href="compagnie/a_propos.de.html" (au lieu de compagnie/a_propos.html, qui serait la version générique)*. La navigation est alors restreinte à l'allemand, sauf bien sûr les contrôles de langue. Cette méthode a toutefois quelques désavantages. D'une part, tous les liens internes deviennent matière à traduction, ce qui augmente le coût de la traduction et les occasions d'erreurs. D'autre part, si Jaap envoie un lien à Pierre, l'URL (pris dans la barre d'adresse du fureteur) sera spécifique à la langue ; Pierre verra alors la page en flamand. Ces désavantages sont réels mais nullement catastrophiques. Il convient donc d'utiliser des liens spécifiques si l'adhérence ne peut être implantée par un mécanisme de sessions ou de profil.

* Les formes particulières des URL spécifiques et génériques montrés ici (compagnie/a_propos.de.html vs compagnie/a_propos.html) dépendent de la technologie utilisée sur le serveur pour implanter la négociation de langue. Avec Multiviews sur Apache, on verrait plutôt compagnie/a_propos.html.de et compagnie/a_propos.html ou encore, en se débarrassant de l'extension .html, compagnie/a_propos.de et compagnie/a_propos.

En passant

L'en-tête HTTP Accept-Language n'est pas la seule source d'information sur la langue du visiteur. Tous les fureteurs envoient aussi un en-tête User-Agent qui renseigne sur la marque du fureteur, sa version et parfois sa langue. On peut s'en servir pour deviner la langue du visiteur si l'en-tête Accept-Language n'est pas présent, mais il est moins fiable et plus limité (une seule langue) que ce dernier. À manipuler avec grand soin.

La négociation de langue n'est qu'une des facettes de la négociation de contenu HTTP. Les autres facettes pouvant faire l'objet de négociation automatique sont le type de média (c. à d. le format : HTML, PDF ou texte brut par exemple), le codage des caractères et le codage de transfert (chiffré, compressé, etc.). La négociation de langue est la plus utile et la plus utilisée.

Donnez-nous votre avis (en anglais).

Abonnez-vous au flux RSS.

Nouvelles publications

Les nouvelles de la page d'accueil

Twitter (Les nouvelles de la page d'accueil)

‎@webi18n

Pour approfondir

Par : François Yergeau. Traducteur : François Yergeau.

XHTML 1.0 valide !
CSS valide !
Codé en UTF-8 !

Traduit d’un contenu en anglais daté du 2004-02-26. Dernière modification de cette traduction le 2006-11-18 19:09 GMT.

Pour un résumé des changements importants, recherchez qa-when-lang-neg dans le blog i18n.