langue + région de l'attribut HTML5 lang
Je travaille sur un site Web qui proposera un contenu localisé suivant l'approche _language+region_ décrite dans cette page W3.org (par exemple, _fr-CA_ pour le contenu en français canadien, et _fr-FR_ pour le contenu "français français"). Étant donné que nous considérons que le contenu de chaque _language+region_ est unique, il est essentiel pour nous que les moteurs de recherche identifient et servent correctement le contenu en conséquence.
En cherchant sur Internet (par exemple cette question ), il apparaît que la plupart des gens recommandent l'utilisation d'un code de langue ISO639 dans l'attribut HTML lang à décrire la langue du contenu. Suite à cette recommandation, nous utiliserions _<html lang="fr">_ qui ne permettrait pas de différencier les combinaisons _language+region_ susmentionnées.
Lors de l'examen de spécification HTML4 , il semble qu'utiliser _language+region_ comme code de langue serait parfaitement correct, car l'exemple _en-US_ est donné comme une valeur possible. Cependant, je n'ai trouvé aucune confirmation de cela dans le spécification HTML5 , qui ne semble pas fournir d'exemple quant aux valeurs autorisées possibles.
A partir de là, j'ai essayé d'obtenir une réponse de facto en regardant ce que font les géants du Web. J'ai regardé ce que font Facebook: ils proposent des versions en français canadien et en français français de leurs sites Web avec un contenu (légèrement) différent, tandis que la valeur HTML lang reste la même:
fr-CA
URL: http://fr-ca.facebook.com
Attribut HTML lang: _<html lang="fr">_
traduction du mot 'email': courriel
fr-FR
URL: http://fr-fr.facebook.com/
Attribut HTML lang: _<html lang="fr">_
traduction du mot 'email': _Adresse électronique_
Quelle est la manière recommandée/standard de décrire le contenu localisé à l'aide de l'approche _language+region_ en HTML5?
Le W3C fournit ce très long guide sur le choix des étiquettes de langue/sous-étiquettes.
Les bits importants:
La syntaxe d'étiquette de langue est définie par le point BCP 47 de l'IETF. Dans le passé, il était nécessaire de consulter des listes de codes dans diverses normes ISO pour trouver les bons sous-tags , mais il suffit maintenant de regarder dans le registre de sous-étiquettes de langues IANA. Nous allons décrire le nouveau registre ci-dessous.
Cet article fournit des conseils sur la manière de choisir les composants d'une balise de langue. Pour une vue d'ensemble des concepts définis dans le BCP 47, voir Balises de langage en HTML et XML .
...
Il existe des outils disponibles qui fournissent une aide supplémentaire lors de la recherche dans le registre, tels que outil de recherche de sous-étiquettes de langues de Richard Ishida.
...
Assurez-vous d'avoir la bonne langue. Parfois, il est utile de vérifier quelques alternatives. Mark Davis, co-auteur de BCP47, écrit: "Il est souvent difficile de savoir quel identificateur de langue utiliser. Par exemple, ce que la plupart des gens appellent Punjabi au Pakistan porte en fait le code" lah "et le nom officiel" Lahnda ". autres cas où le même nom est utilisé pour différentes langues ou où le nom recherché par les personnes ne figure pas dans le registre IANA. "
Vous pouvez rechercher des informations sur la langue dans SIL Ethnologue et comparer ces informations avec Wikipedia . Ethnologue utilise les mêmes codes à trois lettres que BCP47, mais vous devrez convertir les codes à deux lettres BCP47 en leurs équivalents ISO 639- pour rechercher une langue par code. ( outil de Richard Ishida le fait pour vous.)
Il existe un petit nombre de cas où différents codes de langue sont disponibles pour ce que beaucoup de gens considèrent comme la même langue, par exemple. Philippin et tagalog, ou twi et akan. Il n'y a aucune indication dans le registre sur laquelle vous devriez utiliser, mais vous devriez essayer de vous assurer que dans une application ou un contexte unique, vous êtes cohérent.
(Souligné par moi.)
Il convient de noter que registre de sous-étiquettes de langues IANA est un peu difficile à utiliser. À l'exception des balises bénéficiant de droits acquis (comme en-GB-oed), vous devez rechercher la balise de la famille de langues et les sous-étiquettes region/variant séparément. Et les étiquettes/sous-étiquettes sont organisées par type plutôt que par hiérarchie. Donc, économisez du temps et des ennuis et utilisez le formidable outil de recherche de Richard Ishida .
[Ce n'est pas mon domaine le plus fort, alors je ne fais que citer de la documentation ici, mais il semble que vous ayez oublié quelque chose.]
La spécification HTML5 nécessite que la valeur lang soit valide balise BCP 47 . Dans ce document, le bit pertinent semble être dans la section 3.4:
Par exemple, une implémentation pourrait mapper les plages de langues étendues aux plages de base. Une autre possibilité consisterait pour une implémentation à renvoyer la balise correspondante en premier dans l'ordre ASCII. Si la gamme de langues était "* -CH" ("CH" représente la Suisse) et que l'ensemble des balises incluait "de-CH" (allemand utilisé en Suisse), "fr-CH" (français, Suisse) et "it -CH "(italien, Suisse), l'étiquette" de-CH "sera alors renvoyée.
... ce qui, en gros, correspond à ce que vous avez obtenu de la spécification HTML 4 citant le RFC1766, mais de manière beaucoup plus détaillée.
Utiliser <html lang="fr-FR"> et <html lang="fr-CA"> est correct, si elles correspondent au contenu réel. Mais ils sont ignorés par les moteurs de recherche, tout comme <html lang="fr">.
HTML5 ne signifie pas changer l'utilisation des codes de langue. Le système de codes, tel que défini dans le BCP 47, et ses extensions sont très élaborés et vous permettent de spécifier une variante de langue avec une précision douloureuse. L'état de l'art est à un niveau beaucoup plus simple, et fr-FR et fr-CA représentent la meilleure granularité que vous puissiez obtenir de nos jours en logiciel; assez souvent, seul le code principal (ici, fr) est important.
Rien n'indique que les moteurs de recherche prêtent réellement attention aux déclarations de code de langue, telles que les attributs lang. D'autres logiciels, tels que les césure, les correcteurs orthographiques, les synthétiseurs vocaux et les algorithmes de sélection de polices par défaut peuvent prendre en compte les attributs lang. Mais les moteurs de recherche effectuent leurs analyses heuristiques en fonction du contenu réel.
Il est difficile de les en blâmer, car cela donne de meilleurs résultats que de faire confiance aux attributs lang. Par exemple, de nombreux outils de création génèrent automatiquement lang="en" quel que soit le contenu réel, sans le dire à l'auteur.