Valéry-Xavier Lentz.eu

To content | To menu | To search

Tag - multilinguisme

Entries feed - Comments feed

Sunday 14 March 2010

Un domaine par langue pour un site SPIP

Ce billet rassemble quelques notes sur les manipulations que j'ai mis en oeuvre pour permettre l'utilisation de plusieurs domaines sur le site du webzine Le Taurillon, construit en SPIP. N'hésitez pas à faire part en commentaire de vos observations sur la méthode retenue.

SPIP propose tout ce qu'il faut pour construire un site web éditorial de type magazine. C'est même ce qu'il fait le mieux. De même il dispose de nombreuses possibilités pour la construction d'un site multilingue.

Le Taurillon, conçu initialement en français, rapidement pendant l'été 2005, est un site désormais publié en quatre langues. Chaque langue correspond en réalité à une publication différente car, même si de nombreux articles sont traduits, les équipes éditoriales sont distinctes.

  • Le Taurillon est publié par JEF-France, en français, utilise taurillon.org ;
  • The New Federalist est édité par JEF-Europe en anglais, a pour domaine thenewfederalist.eu ;
  • Eurobull est publié par JEF-Italie, en italien, avec eurobull.it ;
  • Treffpunkt Europa, enfin, est publié par JEF-Allemagne, en allemand, donc, avec treffpunkteuropa.de.
Le site est organisé à l'aide d'un secteur par langue. Chaque secteur (rubrique de premier niveau) ne contiens donc que des articles dans la même langue.
Les articles et rubriques ayant une langue, il est possible au sein de la boucle ARTICLE, ou RUBRIQUE, d'utiliser la balise #LANG pour récupérer la langue du contexte. Pour le reste du site il faut utiliser un paramètre de langue dans l'URL : &lang=fr que l'on récupère à l'aide de #ENV{lang}. Le critère {lang} permet ensuite dans les boucles l'acceptant de filtrer le contenu par langue. Pour en savoir plus lire la rubrique "Multilinguisme" sur site "Programmer avec SPIP 2.0".
C'est ainsi le cas de la page d'accueil. Ainsi, http://www.taurillon.org/?lang=fr affiche la page d'accueil du Taurillon, mais http://www.taurillon.org/?lang=de affichera la page d'accueil... de Treffpunkt Europa.

Un domaine par langue

La première étape a été de demande aux propriétaires des domaines de les configurer avec les NS de OVH, l'hébergeur du site. Chez ce dernier, j'ai pu faire pointer tous les domaines vers le même répertoire, celui où est installé le site, à l'aide d'enregistrements DNS de type A.
Par défaut, c'est la page francophone (langue par défaut du site) qui s'affiche. Pour que chaque domaine retrouve la page d'accueil correspondante c'est le fichier .htaccess qui est appelé à l'aide :
RewriteCond %{HTTP_HOST}  ^www.thenewfederalist\.eu$
RewriteRule (.*) spip.php?lang=en [QSA,L]
Jusqu'à la page d'accueil, tout vas bien, donc. Le problème est qu'un clic vers un article dans une autre langue conserve le nom de domaine actif. On se retrouve donc avec des articles en français ou en allemand sous le domaine anglophone.
Et c'est mal.
Pour parer à cette situation j'ai mis en place deux systèmes :
1) Indiquer l'URL canonique de la page : afin de ne pas troubler les robots (c'est fragile ces engins), j'ai ajouté dans le head une ligne indiquant l'URL canonique de la page, c'est à dire l'URL que je leur demande de prendre en compte pour chaque page. Un article en allemand aura donc dans le code de la page une ligne du type : 
<link rel="canonical" href="http://www.treffpunkteuropa.de/Chronik-eines-angekundigten-Todes" />
2) Pour les humains, et les robots malcomprenants, je modifie les #URL_ARTICLE et #URL_RUBRIQUE, qui génèrent un lien relatif, pour proposer un lien absolu avec le domaine.
Pour ce faire j'avais envisagé d'utiliser le plugin "Multidomaines". Celui-ci permet, à l'aide d'un champ Extra (oui il faut installer aussi ce plugin), d'associer un domaine à une rubrique. Je ne l'ai pas utilisé pour trois raisons : je n'ai pas besoin de toutes ses fonctions, je n'aime pas (plus) installer trop de plugins (impact sur lesperformances, complique la maintenance et l'évolutivité du site), enfin, quand je l'ai activé j'ai eu un message d'erreur et je n'ai pas insisté.
J'ai utilisé les chaines de langue de SPIP : j'ai créé une chaine <:domaine:> et indiqué dans chaque fichier de langue le domaine correspondant. Je peux donc utiliser cette chaine partout où j'ai besoin du domaine, car je dispose de la langue dans le contexte partout, soit dans la boucle, soit dans l'URL (paramètre lang).  Par exemple dans une boucle ARTICLES, j'indique comme lien href="<:domaine:>/#URL_ARTICLE". 

Les limites de l'approche retenue

Naturellement, cette méthode a des limites.
  • elle implique de modifier tous les squelettes. C'est également le cas avec le plugin qui propose ses propres balises. Pour l'instant je n'ai traité que les squelettes essentiels. J'adopterai l'approche systématiquement lors d'une refonte, et au fur et à mesure d'ici là.
  • elle ne peut avoir d'effet pour une boucle affichant des contenus en plusieurs langues (une boucle FORUM par exemple, celle-ci n'acceptant pas le critère lang) : les URL utilisent alors le domaine en cours.
  • les statistiques de fréquentation sont en partie faussées, chaque URL étant comptabilisée comme un site référent tiers. Il faut que j'étudie les configurations possibles dans Google analytics 

Méthodes alternatives

Plusieurs autres méthodes sont à étudier.
  • le mutualisé : plusieurs sites SPIP (dans des répertoires différents) qui pourraient partager une même base de données (pour permettre la gestion des liens de traduction ou des auteurs communs). À vérifier: cette solution permet-elle de partager un même jeu de squelettes ?). 
  • Utilisation du htaccess pour réécrire l'URL en fonction du paramètre lang pour y placer le bon domaine : je ne suis pas sur que ce soit possible, il faut que j'étudie plus la syntaxe pour RewriteCond
Un billet à mettre à jour donc, si je découvre une meilleure méthode. Mais pour l'instant l'essentiel semble fonctionner.

Mise à jour

31/03/2010 : Le carnet-SPIP propose différentes méthode, notamment à base de php. Cf. http://www.spip-contrib.net/MultilinguismeExemple6

Tuesday 13 October 2009

La recherche par langue sur Twitter

Depuis combien de temps cette fonction est-elle là ? Je ne l'observe qu'aujourd'hui en tombant par hasard sur cette page de résultat. Twitter propose désormais un filtre de langue dans les résultats de recherche sur http://search.twitter.com/ Cette fonctionnalités n'est toutefois pas présente dans les résultats de http://www.twitter.com

Il se présente dans la colonne de droite sous la forme d'un menu déroulant proposant 19 langues. Le nom de chaque langue est affiché en anglais suivi du nom dans la langue et l'alphabet d'origine, entre parenthèses. Je m'étonnais de voir ce double affichage mais compte tenu des usages de Tweeter comme outil de veille ceci a du sens : ainsi on peut consulter les messages en farsi pour se faire une idée de l'activité des internautes iraniens sans pour autant savoir distinguer le farsi de l'arabe dans un menu de langue...

19 langues seulement : en effet il semble que la détection de la langue d'un Tweet de fasse non pas sur la base d'une déclaration de sn auteur - il n'existe pas d'interface pour le préciser, mais sur une détection automatique, sans doute dès la création du Tweet car ceux ci se voient attribués une class "fr" ou "en" selon qu'ils sont en  français ou en anglais. Il faut donc un mécanisme de détection qui n'est pas semble-t-il disponible dans plus de langues.

Regrettons au passage que puisque Twitter ajoute une class, il n'en profite pas pour ajouter un attribut lang sur le span.

Ce mécanisme de détection automatique (plutôt qu'une déclaration utilisateur) limite donc le nombre de langues disponibles pour le filtre mais génère également des erreurs. En effet, 140 charactères, dont souvent des tags et des URL, ne donne guère de mots pour procéder à une analyse fine du texte d'autant plus qu'il est parfois en style télégraphique. Ceci est un problème à la fois pour le filtre de langue et pour la traduction automatique également proposée.

Voici par exemple deux Tweets sur #parisweb qui seraient rédigés en islandais... ou pas.

Une fonctionnalité donc imparfaite mais tout simplement indispensable pour un service comme Twitter.

Notons au passage que Twitter a annoncé le 8 octobre la localisation de l'interface du site [en] en allemand, espagnol, français et italien en plus de l'anglais et du japonais.

Pour aller plus loin :

  • En attendant le Poisson de Babel : la présentation de Stéphanie Booth à Paris Web 2007 abordait le multilinguisme sur le web et comportait quelques écrans sur un Twitter jusqu'ici indifférent.

Sunday 21 September 2008

Le Parlement européen lance sa webTV

Alors que la télévision française prouve sa médiocrité en ne couvrant pas à sa juste mesure les travaux pourtant souvent essentiels des eurodéputés, on ne peut que se réjouir du lancement de la télévision web du Parlement européen (via e-toile).

Un bon moyen de se tenir au courant de l’actualité européenne et des travaux des eurodéputés, donc, même si je préfère pour ma part parcourir les excellentes synthèses sur site europarl.europa.eu que de regardfer des vidéos. La densité d’information est toujours plus forte à l’écrit. Toutefois il est plutôt agréable d’entre les eurodéputés qui s’expriment dans ces vidéos.

Le Parlement européen assure donc un travail d’information et de communication essentiel sur le web et produit des sites assez agréables à utiliser avec surtout une attention très forte à la qualité du contenu qui tranche avec la plupart des sites institutionnels.

Quelques regrets cependant :

  • comme sur europarl, europarltv ne propose pas de fil RSS. Alors que tous les navigateurs modernes intègrent désormais cette technique, une telle absence est incompéhensible. Le site devrait proposer non seulement du RSS mais aussi beaucoup de RSS : un par rubrique ou par thème, pour que tous ceux qui souhaitent suivre l’actualité du Parlement européen puissent le faire sans avoir à se connecter sur le site pour autant.
  • le menu de langue et la recherche sont placés au dessus de la fenêtredu navigateur, sur toute sa largeur et sur fond gris, ce qui fait que l’on ne les aperçoit pas forcément facilement, car ils se confondent visuellement avec l’interface du navigateur. On n’a de plus pas de principe de navigation commun entre les différents sites du Parlement européen où ces élements sont situés plus proches du menu principal de navigation.

  • Plus grave, les vidéos sont proposées par défaut au format Window media player…

  • Il faut donc pour pouvoir les lires dans de bonnes conditions si l’on utilise pas Explorer, découvrir un discret menu de configuration sous la vidéo qui permet de choisir un format flash. Le site devrait proposer par défaut le format flash. Il s’agit aussi d’un format propriétaire mais au moins il est multiplateforme. Bon point : on peut choisir la langue des sous-titres indépendamment de celle de l’interface.

  • Enfin, le lien “code imbriqué” ne propose pas du tout le code pour imbriquer la vidéo sur un autre site mais indique seulement l’URL de la vidéo. Dommage pour la diffusion de ces reportages. Compter sur la disponibilité d’un player sur le site distant en ne fournissant qu’une URL est insuffisant. J’espère que le Parlement les placera aussi sur Youtube ou Dailymotion. Compte tenu des investissements dans la production de contenu, autant qu’un maximum de citoyens européens puissent y avoir accès même s’ils n’ont pas le réflexe de se connecter sur ce site.
Pour finir et pour se faire plaisir : voir par ici la vidéo sur Altiero Spinelli qui inaugure une série “Européens célèbres”.

Thursday 11 September 2008

De la page d'accueil d'un site multilingue

Ce billet constitue le second d'une hypothétique série sur le multilinguisme dans les sites internets. Il fait suite au précédent intitulé "Représenter les langues d'un site web" qui abordait la navigation entre différentes versions linguistiques.

La page d'accueil demeure la page la plus visité de la plupart des sites internets, même si sur la plupart des sites une très large majorité des visiteurs entrent via une page de contenu référencée sur un moteur de recherche.

Dès lors que le site est multilingue, deux questions se posent :

  1. Dans quelle langue doivent être rédigés son interface et son contenu ?
  2. Comment faire comprendre au visiteur qu'il a la possibilité de changer de langue ?
Autant le dire tout de suite, il n'existe pas de bonne solution, ou en tout cas

La pré-page d'accueil

La solution de facilité mais aussi la plus simple, notamment dans le cas d'un site massivement multilingue, et de proposer une page proposant la liste des langues disponibles dès la connexion de l'internaute. Ce dernier est dès lors contraint de sélectionner une langue avant de visualiser le contenu du site.

Notons que c'est sans doute là un des rares cas d'utilisation d'une pré-page d'accueil qui puisse être considéré comme tolérable. En règle générale tout obstacle entre le visiteur et l'information qu'il recherche est à bannir : ça agace.


La page d'accueil du Parlement européen : 21 liens et une faute de goût : une phrase en anglais inutile


Le site du premier ministre de Belgique (détail) : c'est déjà plus simple, mais qu'est devenu l'allemand, si je ne m'abuse également langue officielle au niveau fédéral.

Une langue par défaut

Une autre solution consiste à proposer une page d'accueil en anglais dans une langue par défaut dont on estime qu'elle est comprise par la majorité des visiteurs. On s'efforce alors de mettre en évidence la possibilité de changer de langue si nécessaire.

Ainsi une multinationale pourra proposer sa page d'accueil en anglais et un menu pour passer vers des traductions du site. J'élude délibérément le cas de figure de la famille de sites de filiales avec des noms de domaines différents. Le multilinguisme ainsi évacué finit par revenir par la porte de derrière (et il n'est pas content) dès lors que l'on veut utiliser un .be ou un .ch par exemple.

Un site espagnol pourra afficher son contenu en castillan avec des liens vers les versions catalane, basque ou gallicienne.

Un site belge va chercher une autre solution ou courir au devant de gros ennuis.


Le site portail de l'administration suisse propose une page d'accueil... en anglais !

Une langue par défaut avec détection automatique

La solution la plus sophistiquée consiste à chercher à deviner identifier la langue préférée de l'utilisateur. Il existe toute une série d'indices parmi les informations que votre navigateur internet envoie au serveur du site lorsqu'il se connecte, à commencer par l'emplacement géographique de votre ordinateur, déduit de manière plus ou moins fiable de son adresse IP (une série de numéros plus ou moins unique vous identifiant sur le réseau) et surtout par la ou les langues par défaut du navigateur.

Si votre navigateur dispose d'une interface en français, la langue par défaut d'un tel site sera le français, s'il est disponible. Le webmaster belge est sauvé, il ne devra pas subir l'ire flamande, il pourra proposer une page d'accueil en néerlandais à ses internautes Anversois.

La page d'accueil tour de babel

Oui, mais non... Extrêmement rare : les articles des différentes langues sont mêlées sur la page d'accueil.

La solution peut être appropriée lorsque l'on s'adresse à un public dont on sait qu'il maitrise effectivement les langues concernées. L'avantage principal est que si l'intégalité du site n'est pas traduit, cela permet de continuer à proposer l'ensemble des contenus disponibles.

Les inconvénients de la solution sont évidents : il devient beaucoup plus difficile de parcourir rapidement les titres de la page, d'autant plus que l'on ne comprend pas toutes les langues.

Il n'est pas certain que Google apprécie non plus. Il faut en toute hypothèse pouvoir bien identifier dans le code chaque bloc de contenu à l'aide du code de langue correspondant.

Enfin, pour le politiquement correct : l'interface de navigation ne peut être que dans une seule langue sauf à n'utiliser que des images. Il y a donc toujours un privilégié.


Le site spip-contrib propose des extensions pour SPIP. La page d'accueil mélange ici articles français et espagnols.

I will be back

Le Graal d'un site internet est le visiteur récurrent. Il n'est pas nécessaire le tester sa patience en lui imposant de sélectionner sa langue à chaque visite.

Bien sur, on peut espérer qu'il inscrive dans ses favoris l'adresse de la page d'accueil dans sa langue. Nous avons là le visiteur parfait. Il est sinon possible de conserver une trace du choix réalisé lors de la première visite, soit par l'utilisation d'un cookie, soit dans le meilleur des cas, si votre site le proposer et que le visiteur crée un compte utilisateur, par la conservation de ce choix dans son profil.

Conseils pour votre cahier des charges

La gestion du multilinguisme est un facteur de complexité supplémentaire dans un projet web. Il est essentiel qu'elle soit prévue dès la conception du site sous peine d'entrainer coûts et délais supplémentaires par la suite.

Le multilinguisme conditionne par exemple le choix de l'outil de gestion de contenu, des modes de navigation et de l'organisation de la page d'accueil. Il implique potentiellement la mise en place  de codes particuliers dans les gabarits du site.

Il faut donc préciser dès le cahier des charges un maximum de détails :
  • si le site doit être disponibles en plusieurs langues ou s'il faut le prévoir dès à présent pour une version future
  • le nombre de langues est-il définitif ou faut-il prévoir l'ajout de langues supplémentaires ?
  • l'intégralité du site est-il traduit ou bien seulement quelques pages ?
  • l'arborescence du site sera-t-elle identique ou non selon les langues ?
  • les langues doivent-elles être traitées sur un pied d'égalité ou bien existe-t-il une langue principale sur le site ?
  • faut-il prévoir une optimisation pour le référencement dans toutes les langues ? et une démarche de référencement correspondante ?
Et vous ? Quelle formule vous semble la plus appropriée ?

Saturday 30 August 2008

Représenter les langues d'un site web

Comment représenter les langues sur un site web ?

Le multilinguisme est l'une des principales difficultés dans la conception de sites internet.

Il implique des difficultés à la fois :

  • techniques : pour représenter correctement les caractères accentués ou les différents alphabets, notamment pour la communication entre des applications utilisant des systèmes différents ;
  • ergonomiques : afin de permettre la navigation entre différentes versions linguistiques d'un site ou entre un contenu et ses traductions ;
  • relatives à l'architecture de l'information : à défaut de pouvoir traduire intégralement un contenu les arborescences sont souvent différentes selon les langues. Comment par exemple référencer un contenu dans une langue qui n'est disponible que dans d'autres langues ?
  • en terme de communication : comment communiquer auprès de tous en sachant que l'on ne peut traduire les contenus dans toutes les langues du public ciblé ?
  • politiques : la question de la langue est toujours sensible. Les commentaires négatifs en tardent pas si un contenu visant un public international n'est pas disponible dans la bonne langue.

Lors de la construction d'une page web la langue est prise en compte à plusieurs moments. On la spécifie pour la page entière, ou pour une partie du contenu, voire sur un lien pour signale que la page de destination est dans une autre langue. Cf. Spécifier la langue d’un document (X)HTML sur Openweb.

Je voulais aujourd'hui m'attacher à la question de la représentation des langues sur un site web. Il n'existe que deux méthodes : du texte ou des images.

Le texte est le plus simple : une série de liens voire un menu déroulant permettent de préciser explicitement la langue de destination. Encore faut-il se demander si on doit écrire le nom de la langue dans la langue en question ou dans la langue de la page courante. La logique veut que l'on conserve la version originale dans ce cas puisque l'on s'adresse à un public supposé la parler.

C'est le choix qu'a fait le Taurillon par exemple, qui posera problème si jamais on ajoute une ou deux langues de plus :

Café Babel propose également du texte, mais dans un menu déroulant ce qui rend l'option de langue très discrète. Il est vrai que le ste propose les même contenus dans toutes les langues et qu'il n'est donc pas nécessaire de mettre cette fonction en avant. 

Pour le Taurillon, chaque version linguistique dispose de contenus distincts et d'un comité de rédaction différent : il est donc important pour ce site de mettre en avant de manière évidente les différentes langues disponibles. Notons que dans ce cas l'anglais correspond en fait à une édition internationale. Un problème se poserait si les britanniques souhaitait leur propre édition du magazine, distincte de l'édition internationale. 

Dans le cas où l'on dispose d'un plus grand nombre de langues ou que l'on souhaite mettre en avant visuellement celles-ci à l'aide d'images, que faire ?

L'Union européenne, championne du multilinguisme, utilise les codes ISO-639-1, une norme listant les langues à l'aide d'abréviations de deux lettres. Par exemple :

  • FR = français
  • EN = anglais
  • IT =italien
  • DE = allemand
Notons qu'il existe ausi une norme ISO-639-2 avec des codes à trois lettres (deux lettres ne peuvent représenter en théorie que 676 langues alors qu'il en existe des milliers).

Sur le portail de l'Union européenne et la plupart des sites officiels les codes sont représentés par des pictogrammes sur la pré-home (une page intermédiaire avant la page d'accueil dont l'utilisation est un autre débat...).



Les pages intérieures reprennent le système de menu déroulant, plus à même d'économiser l'espace à l'écran, ce qui est d'autant plus important que le nombre de langues est important (l'Union compte 21 langues officielles) et que ce menu a vocation à être présent à un emplacement clé de la page web. Ces icônes sont documentées ici [en].

Notons que la langue du site de destination est affichée à l'aide du même picto :



L'usage des codes ISO fonctionne bien car il est associé à un texte dans la langue en question.

En revanche on peut se demander s'ils peuvent remplacer les petits drapeaux que l'on trouve parfois, comme ici sur le site www.pourdesvoituresmoinspolluantes.org :





L'intérêt de cette formule est que les drapeaux sont reconnus par les utilisateurs, qu'ils prennent moins de place qu'un texte tout en évitant d'imposer la manipulation d'un menu déroulant.

Les drapeaux fonctionnent sur ce site car ils n'indiquent pas seulement la langue mais aussi le pays concerné : chaque drapeau lie à une page dont le contenu est spécifique à chaque pays.

En revanche leur usage est à déconseiller lorsqu'il s'agit seulement d'indiquer la langue. Il est très peu politiquement correct de proposer à un américain ou encore moins un irlandais de cliquer sur l'Union Jack pour afficher une page en anglais ou ne laisser aux Belges que le choix entre un drapeau français ou néerlandais (sans compter les Belges germanophones). Je ne dénoncerais pas ici de site qui se rendent coupable de cette mauvaise pratique. Cf. Jakob Nielsen : Flag problem [en].

La seule alternative graphique semble donc la reprise des fameux codes ISO, ce qui suppose que les internautes connaisse le code de leur langue et identifient une série de codes comme étant un menu de langues. L'idéal serait un standard graphique qui s'impose de facto ou de jure comme cela s'est fait pour le RSS [en].

On trouve par exemple sur Wikipedia une série d'icones (sous licence libre bien sur) utilisables à cette fin :

Le problème de ces icônes est qu'elles sont très laides d'une part et que personne ne les utilise d'autre part. En revanche on doit pouvoir adapter la couleur à l'environnement du site.

Et vous ? quelle interface préférez-vous pour les sites multilingues ?