1633 sujets

Formats, encodage, internationalisation, XML

Indication de langue pour un document multilingue

Bonjour,

Suite à une question de Arsene dans un autre sujet :

a écrit :
Je suis en train de terminer un site 100% bilingue où pour éviter la prééminence d'une langue sur l'autre, tous les éléments (entêtes, menus, textes) sont dans des <div> qu'un script PHP affiche de façon aléatoire et où l'on passe d'une langue à l'autre (ça fait partie du "concept" du site) par CSS (=> question aux experts en passant : comment gérer l'attribut lang ???)

...

Comment renseigner :

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr">

et :

<meta http-equiv="content-language" content="fr" />

dans un site parfaitement bilingue...



En résumé :

Je reprends la nomenclature développée dans l'Article d'Open Web sur ce sujet (cité plus bas) et qui définis :

- Une langue de traitement unique, attaché à un contenu.
- Une ou des langues primaires attachées à la "ressource web" et qui réfèrent au "public" visé.

Pour la ou les langues primaires :

L'en-tête Http "content language" et son équivalent : la métadonnée <meta http-equiv="Content-Language">, permettent d'indiquer plusieurs langues primaires.

Le but est d'indiquer la ou les langues qui correspondent au(x) public(s) visé(s) par l'Auteur.

Il n'est donc pas nécessaire d'indiquer toutes les langues utilisées mais bien celles qui réfèrent le public visé.

Par exemple un cours d'anglais, destiné à un public français, devra faire référence au code de langue "fr", quelque soit l'importance du contenu anglais du document.

A contrario une édition bilingue destinée à un public français et anglais devra référer les deux codes de langue en les séparant par une virgule :

<meta http-equiv="Content-Language" content="fr, en"


Pour les indications de la langue de traitement :

Ces indications sont destinées aux dispositifs logiciels qui doivent traiter le contenu, ce sont donc des indications techniques qu'il ne faut pas confondre avec les "langues primaires" qui concernent les publics visés (l'audience).

La valeur utilisée est toujours unique et adresse un contenu spécifique, elle se déclare directement au niveau de l'élément conteneur par l'attribut lang et/ou l'attribut xml:lang selon le doctype :


<span lang="en">...</span>
...
<q lang="fr" xml:lang="fr">...</q>


Pour l'élément Html :

html lang="fr" xml:lang="fr"


Enfin, on peut utiliser le code de régionalisation, quand il existe, pour distinguer des langues dérivées, locales ou des dialectes :


lang="fr-CA"
Indique la version de nos cousins Canadiens...


Ceci posé, comment traiter la déclaration de la langue de traitement d'un document parfaitement bilingue, pour l'élément html (et lui seul) ?.

Réponse relativement simple : il n'y à pas de raison valable de faire cela en regard de l'objectif assigné à cet attribut ... Smiley smile .

Ce sujet reviens de manière récurrente, la dernière "poussée de fièvre" à eut pour origine les commentaires sur WCAG 2.0

Discussions pas extraordinaire d'ailleurs certains trouvant anormal de ne pas pouvoir le faire et en voulant pas en démordre, ce à quoi on ne peut que répondre qu'on ne peux pas considérer d'un point de vue technique, qu'un document est "à la fois" d'une langue et d'une autre.

Il faut donc chercher d'autres pistes, l'une d'entre-elle est de considérer les métadonnées : si elles privilégient une langue, par exemple un document dont le corps est multilingue français-anglais mais dont les métadonnées sont en français, il faut prendre cette référence et indiquer lang=fr.

Mais là c'est un cas simple : ce n'est pas un document "parfaitement multilingue"... Smiley cligne

Pour un document parfaitement multilingue :

La direction qui est prise par le W3C est, dans le cas d'un document multilingue du point de vue des langues de traitement et de l'audience, de laisser la possibilité de ne pas déclarer la langue de traitement au niveau de l'élément html :

a écrit :

Where a document contains content aimed at speakers of more than one language, decide whether you want to declare one text-processing language in the html tag, or leave the text-processing languages undefined until later.


Ce qui reviens à dire qu'en réalité vous avez le choix : Déclarer une langue de traitement initiale au niveau de l'élément Html ou décidez de le faire d'une autre manière dans le document lui-même.

Par exemple, la note de travail du W3C présente la structure d'un document où rien n'est déclarée dans l'élément Html et où les indications des langues de traitement sont reportées dans le document au moyen d'une structuration par des divs.

Ce document de "bonnes pratiques" est très récent (21Juillet 2006) et encore en version de travail mais il représente une position constante du W3C à ce sujet.

Pour en savoir plus :

Open Web - Spécifier la langue d'un document (X)HTML (De l'homme qui murmurait des prières aux oreilles des spécifications...)

W3C - Internationalization Best Practices: Specifying Language in XHTML & HTML Content (en)

Jean pierre
Modifié par jpv (27 Sep 2006 - 03:23)
Salut,

Très intéressant cette petite explication, j'ai cependant une petite interrogation :

a écrit :
La valeur utilisée est toujours unique et adresse un contenu spécifique, elle se déclare directement au niveau de l'élément conteneur par l'attribut lang et/ou l'attribut xml:lang selon le doctype :
<span lang="en">...</span>
...
<q lang="fr" xml:lang="fr">...</q>


Le lang="en" ne suffit-il pas ? Dans quel(s) cas faut-il ajouter l'attribut xml:lang ? Lorsqu'il faut le mettre, faut-il nécessairement le respécifier à chaque changement de langue ?
Bonjour,

Dés lors que l'on travaille avec Xhtml :

Type de contenu text/html :
L'attribut html dédié est lang, il est conseillé d'utiliser les deux formes.

 <span lang="fr" xml:lang="fr">


Type de contenu application/xhtml+xml :
Seule forme "xml" s'utilise.

 <span xml:lang="fr">


Jean-pierre
Modifié par jpv (27 Sep 2006 - 11:30)
Je reviens un peu tard, n'ayant pas bcp de temps ces derniers jours. Merci d'avoir déplacé le post et créé un nouveau topic, et merci aussi pour ces explications éclairantes. Je m'étais effectivement lancé dans un 

<meta http-equiv="Content-Language" content="fr, de">


puisqu'en l'occurence c'est d'allemand dont il s'agit. Ton lien W3C est intéressant, il précise :

a écrit :
Discussion: See the definition of the intended language of the audience. Documents containing content aimed at an audience in more than one language are rare. A document is not aimed at a multilingual audience if it contains small amounts of text in another language. We are talking here about the languages the intended audience speaks.


L'idée est précisément qu'à aucun moment le visiteur ne puisse dire s'il est sur un site français "germanisé" ou sur un site allemand "francisé". Il s'agit d'un projet transfrontalier sur financement Interreg où tout est bilingue (acteurs, réunions de travail, lieux de réunions, productions, etc.). Si les textes sont globalement séparés (div "fr" et "de" distinctes) en revanche les menus sont parfaitement bilingues. J'ai poussé la logique du bilinguisme jusqu'à générer aléatoirement le positionnement du français ou de l'allemand en premier dans le menu, item par item, ce qui fait que, additionné au title de la page lui aussi bilingue dans un ordre aléatoire, n'importe quelle page présente au total 144 versions différentes Smiley biggol

D'un strict point de vue d'accessibilité, avoir ces jeux de langues incertains n'est pas exceptionnel puisque cela requiert une attention plus soutenue du visiteur, mais c'est complètement dans la logique du projet... et du financement. Disons que l'idée n'est pas d'avoir du français d'un côté et de l'allemand de l'autre, mais de mélanger les langues dans la limite du soutenable... sinon il aurait été plus simple de créer un système où le visiteur choisit sa langue dès l'accueil (voire même mettre en place un script de détection pour la choisir à sa place). C'est en ça que le site est "parfaitement" bilingue, et c'est vrai que ça pose quelques problèmes intéressants. Et encore, là ça va, c'est le même charset... j'ose pas imaginer la même chose en cyrillique, arabe ou japonais Smiley smile

Reste la question du <html lang=?>

W3C suggère de ne pas déterminer d'attribut lang dans ce cas, apparemment ?
Bonjour,

a écrit :
W3C suggère de ne pas déterminer d'attribut lang dans ce cas, apparemment ?


C'est ça...
A la condition, evidemment, je le précise pour les lecteurs distraits, qu'un autre mécanisme soit mis en place, sur la structure et les éléments, pour gérer les indications de langue de traitement.

Jean-pierre
Merci JP

Donc, si je résume, on a soit :


<html xml:lang="fr" lang="fr">
...
<div id="page-1" lang="fr">
<div id="page-2" lang="de">

(métadonnées en FR)

soit :


<html>
...
<div id="page" lang="fr">
<div id="seite" lang="de">

(métadonnées bilingues)


Si les deux solutions sont peu ou prou équivalentes je préfère la 1ère, d'abord parce que je parle mal allemand, ensuite parce que mes scripts d'affichage aléatoires utilisent foo-1 et foo-2 sur tout le site, que ce soit pour les entêtes, les menus ou les pages...
Bonjour,

Lorsque je parlais des métadonnées, il s'agissait de celles déclarées en propriété du document dans la section head.

La valeur d'un id est indifférent à la langue, ce ne sont que des chaines de caractères d'identification.

Donc tu à un choix à faire :

Déclarer la langue de traitement sur l'élément html, si quelque chose le justifie, par exemple les métadonnées déclarées en en-tête sont en français.

Ne pas déclarer la langue de traitement sur l'élément html si le site est parfaitement bilingue (*) et reporter ces déclarations en t'appuyant sur la structure et les éléments

Mais pour les valeurs d'id, de class ect, peut importe la langue.

(*) : Ce qui implique que toutes les métadonnées de propriété du document, par exemple description sont écrites dans les deux versions :


<meta name="description" content="" lang="fr" />
<meta name="description" content="" lang="de" />


En revanche, il ny à pas de solutions pour certains éléments qui doivent être uniques, par exemple le titre de la page :


<title>Titre en français - Titre en allemand</title>


Jean-pierre
Bonjour

oui, très instructif tout ça... 2 points encore :

a écrit :
La valeur d'un id est indifférent à la langue, ce ne sont que des chaines de caractères d'identification.


exact mais il est possible qu'à terme ça devienne un genre de métadonnée (voir micro-formats...) et donc que ça se mette à avoir "un certain sens", donc autant ne pas l'ignorer, tant qu'à faire... Ceci dit c'est vrai que "page" ou "seite" n'ont pas de potentiel particulier en terme de pertinence et d'utilisation mais bon, on verra.

a écrit :
En revanche, il ny à pas de solutions pour certains éléments qui doivent être uniques, par exemple le titre de la page : <title>Titre en français - Titre en allemand</title>


pourquoi pas, j'ai même pensé à faire ça Smiley smile :


<?php
$titrepage1 ='en FR | en DE';
$titrepage2 ='en DE | en FR';
$titrepage = rand(1,2);
if ($titrepage == 1) { $titrepage = $titrepage1; }
if ($titrepage == 2) { $titrepage = $titrepage2; }
?> 
...
<title><?php echo $titrepage ?></title>


a+
Bonjour,

Juste un mot rapide : je ne suis pas du tout fasciné, en termes d'accessibilité, par ces choix aléatoires d'ordre dans le menu de navigation, ou de titres de pages.

"dans les limites du soutenable" disais-tu : elles sont dépassées lorsque les repères élémentaires sur le contenu et l'organisation d'un document se mettent à jouer au yoyo Smiley cligne
Je suis du même avis que Laurent, et en tant qu'utilisateur, j'ai à peu près rien à faire de savoir si le site est allemand, français ou à la frontière entre les deux, tant que je trouve l'information que j'y suis venu chercher.
Quand à l'idée de mélanger aléatoirement les textes allemands et français, je pense qu'il est bon d'avoir le français d'un coté, et le texte allemand de l'autre, bien disctinct, que chacun puisse lire dans la langue choisie sans parasitage d'une autre langue.
Bonjour

Attendez, du calme, on n'est pas dans un yoyo permanent non plus... même si, comme je l'ai dit avant :
a écrit :
D'un strict point de vue d'accessibilité, avoir ces jeux de langues incertains n'est pas exceptionnel puisque cela requiert une attention plus soutenue du visiteur, mais c'est complètement dans la logique du projet... et du financement.


Je ne suis pas du tout non plus fasciné par ces solutions qui répondent à la commande. D'un autre côté on peut se poser aussi la question de la pertinence d'un système de gestion de langue sur un autre. A partir du moment où les deux langues sont présentes et accessibles (c-à-d consultables quelle que soit la configuration) ça n'est qu'une question d'affichage... Laquelle afficher prioritairement ? aucune.

Que les deux soient présentes sur la même page (FR d'un côté, DE de l'autre -> Mikachu) est à mon avis peut-être plus problématique en terme de clarté et de confort de lecture (recours + fréquent au scroll, prob liés à l'agrandissement des polices, etc.) qu'arriver sur une page où d'un simple click on affiche la langue de son choix si ça n'est pas la bonne... L'autre option (choix de consultation en FR ou DE dès l'accueil) est contraire au projet que le site présente.
Entre deux maux lequel choisir ?

Quant aux menus (-> Laurent) la différence entre afficher tantôt
Projet | Projekt
et tantôt
Projekt | Projet
de façon aléatoire me paraissait rester dans la limite du soutenable.... et ni le contenu ni l'organisation du document ne sont affectés.

Indépendamment de ce projet en cours, la question de la gestion des langues nécessite probablement une réflexion et quelques expérimentations (même malheureuses Smiley bawling ) avant de trouver sa solution. Est-il possible d'envisager cette question autrement qu'en double version à choisir, dès l'accueil et/ou page par page ? Comment faire face au "multiliguisme simultané" s'il est au cœur même du contenu qu'on a en charge de porter sur le web ?
Nos amis suisses, belges ou canadiens pourraient nous faire part de leurs expériences...
a écrit :
Que les deux soient présentes sur la même page (FR d'un côté, DE de l'autre -> Mikachu) est à mon avis peut-être plus problématique en terme de clarté et de confort de lecture

C'est contre ça que je ne suis pas d'accord, en tant qu'utilisateur, quand j'arrive sur un site, j'accepte d'avoir à choisir en un clic de changer la langue, mais je souhaite ensuite ne plus rien avoir à lire de la langue originale ou de quelques autres langues alternatives. Je suis français et je veux lire dans ma langue natale (sauf dans certains cas ou les traductions sont faites aux traducteurs en lignes et non remaniées).
Je suis de l'avis d'avoir chaque langue bien disctinctes.

Quand au menu en deux langues, quel intérêt pour l'internaute ?
Prenons un internaute français : une fois qu'il a choisi le français (par quelque moyen que ce soit), il ne va pas avoir besoin du menu en allemand.
Le fait d'avoir les deux langues dans le menu signifie que ce menu concerne aussi bien les francophones que les germanophones. Donc s'ils cliquent, vu que le site ne va pas s'afficher vierge de tout texte dans l'attente de savoir quelle langue il va devoir afficher, il y'aura forcément un texte, dans une langue ou dans une autre. Le lien de l'autre langue mènera donc à quoi ? A la page dans la langue initialement présentée, ou dans l'autre langue ??
A moins que chaque lien soit réellement double, le mot allemand amenant à la page en allemand, et idem pour le mot français ? Un peu lourd à lire malgré tout, ca prend de la place dans l'écran, et que ce passera-t-il si un jour ce site doit être traduit en anglais, on ajoute un troisième lien ?
Sinon il reste toujours le recours à la détection de localisation, qui permettrait d'afficher directement la langue concernée. Mais certains habitants frontaliers n'habitent pas toujours dans leur pays respectifs.

Je comprends l'idée que le projet soit autant issu d'une nation/langue que d'une autre, mais il n'en reste pas moins qu'à un moment donné il faut malgré tout faire un choix. On dit franco-allemand et non germano-français, le choix a été fait ainsi, je ne pense pas que nos amis outre rhin s'en offusquent plus qu'autre chose, et il ne me dérangerait pas non plus de dire germano-français si cela avait été établi (même si c'est moins heureux à l'oreille). Je pense donc que le débat de pas donner de priorité à une nation plus qu'une autre est un faux débat, une collaboration signifie toujours des compromis de chaque côté, et vouloir toujours défendre l'égalité stricte quelle que soit la situation me semble juste un peu innoportun, quand les gens qui travaillent ensemble sont de bonne volonté.
C'est un point de vue, effectivement.
Pour clôre (provisoirement) la question, disons que dans le volet culturel du projet il y a des pièces de théâtre "parfaitement bilingue" (certains acteurs parlent en FR et d'autres en DE dans la même pièce), que le site reflète donc en partie leur travail, et que pour le moment les rares retours "extérieurs" sur la maquette en développement sont assez positifs (5 pour, 1 contre...). C'est sûr que c'est une expérience un peu déroutante mais ça semble toutefois assez bien perçu.
Mon appel lancé aux webmasters de Belgique, Suisse ou Canada reste d'actualité.
Merci à tous.
On s'éloigne de la remarque pertinente de Laurent avec ce débat sur l'opportunité ou non de faire coexister les deux langues sur un même document.

Pour finir sur ce point, je dirais juste que c'est un système intéressant. Je suppose que la mairie d'une ville à la fois francophone et germanophone se devrait de proposer les deux langues, et de ne pas parasiter l'information dans une langue par son double dans l'autre langue. Mais là, il s'agirait de fournir des informations très pratiques (sur les services de la mairie, sur la ville, etc.).
Tous les projets n'ont pas ce genre d'objectif de communication. Ici, l'objectif est justement de mettre en avant la coexistence et la confrontation des deux langues. Ce n'est pas un dédoublement du contenu, mais une caractérisitique de ce contenu. Je ne vois rien de choquant là-dedans. Dans le cas d'un projet artistique ou littéraire, je trouve même que c'est un choix tout à fait valable.

Restons en là sur ce point.

Par contre, la remarque de Laurent n'a rien à voir avec cette polémique. Elle porte sur la variation aléatoire des éléments structurant le site : titre de page, autres titres de section, éléments de menu. Le problème est que cela peut représenter une gêne très importante pour le lecteur.

Cas-type : un lecteur valide, sans déficit visuel ou cognitif, utilisant un navigateur graphique moderne sur un ordinateur portable ou de bureau.
Ce visiteur-là remarquera sans doute les effets de permutation aléatoire, mais cela ne le gênera que partiellement. Pour bien comprendre la structure du site et le statut des divers éléments, il pourra se référer à la mise en page : tel titre sera toujours en gros, centré et en rouge, que son contenu soit Français/Allemand ou Allemand/Français ; tel item de menu sera toujours sur fond bleu, dans une colonne à gauche avec d'autres items de menu, avec le même effet de survol au passage de la souris, que son contenu soit Allemand/Français ou Français/Allemand.
On introduit donc un facteur perturbant, mais qui est facilement surmontable.

Maintenant, on peut rajouter des facteurs :
- un déficit cognitif = facteur perturbant démultiplié ;
- un déficit visuel = les outils d'aide proposeront un contenu linéaire, dans lequel le menu de navigation, par exemple, ne sera pas forcément reconnaissable... si son contenu est modifié à chaque page, comprendre la structure du site risque d'être très difficile. De plus, alors que la lecture visuelle permet d'englober d'un seul regard le groupe « Français/Allemand » et l'identifier facilement à un groupe « Allemand/Français » équivaleent, la lecture linéaire imposée par un lecteur d'écran n'offre pas les mêmes facilités cognitives ;
- un navigateur non graphique = même problème de reconnaissance du statut des éléments (bien que moins fort) ;
- etc.

La solution la plus raisonnable consisterait, il me semble, à ne pas faire de renversements d'une langue à l'autre dans les titres et autres intitulés pour un visiteur donné. On pourra, pourquoi pas, ne pas favoriser arbitrairement une langue, mais se baser sur les préférences de l'utilisateur, pour savoir quelle langue doit figurer en premier.
Bonjour Mpop

a écrit :
les outils d'aide proposeront un contenu linéaire, dans lequel le menu de navigation, par exemple, ne sera pas forcément reconnaissable... si son contenu est modifié à chaque page, comprendre la structure du site risque d'être très difficile.


L'ordre aléatoire du menu est généré à partir d'un menu "stable" via JS. Celui-ci absent, le menu se présente dans l'ordre FR-DE. D'autre part il ne s'agit que de 6 items, soit 12 mots au total. Testé sous Jaws 5 ça ne m'a pas semblé insurmontable dans la mesure où sur ces 12 liens seuls 6 sont compréhensibles au non-bilingue... ça ne me semblait pas trop invalidant.

D'autre part l'accès (auditif ou autre) au contenu texte spécifique à une page peut aussi s'effectuer à l'aide d'un lien d'évitement "aller au contenu", id en DE. Là aussi il n'y a pas trop d'ambiguité.

Sur le fond, je comprends très bien vos réticences et je les partage. Je suis entièrement conscient des difficultés supplémentaires imposées à certains utilisateurs, mais comme tu l'as compris cela reflète la philosophie du projet (la commande était très claire à ce sujet) dans un contexte transfrontalier particulier, plutôt "expérimental". L'idée de retraduire cette expérimentation par une "expérience web" de l'utilisateur la moins invalidante possible est un pari intéressant, qui ne va effectivement pas sans questions ni compromis.
Sujet clos
Aller à