Plan de site — Navigation
Blog & Blues Techniques et Standards de la Qualité Web

Accueil > weblog

- Lire le billet précédent - Lire le billet suivant -

Internationalisation: Spécifier la ou les langues d'un document Web

Par Laurent Denis, le 20 octobre 2004.

Le groupe de travail du W3C sur l'internationalisation (I18N) poursuit sa récente entreprise pédagogique (que complète la Quality Assurance Activity et sa collaboration avec le WASP) avec un projet de document sur un de ces thèmes apparemment évidents, mais qui vous réservent quelques suprises : Authoring Techniques for XHTML & HTML Internationalization: Specifying the language of content.

Quels en sont les points essentiels ?

Langue primaire et langue de traitement

La distinction entre deux problématiques distinctes liées aux langues d'une page est sans doute le point-clé de ce document :

  • la ou les langues de traitement d'une page Web doit être indiquée pour toutes les applications susceptibles d'en manipuler le contenu : navigateurs vocaux (Opera 7.60, EmacSpeak) et lecteurs d'écrans (Jaws, IBM Home Page Reader, etc.) ayant à déterminer dans quelle langue le synthétiseur vocal doit travailler, correcteurs orthographiques ayant à déterminer quel dictionnaire utiliser, traducteurs au besoin similaire, ou simple navigateur graphique ayant à donner une présentation spécifique d'un contenu selon sa langue (voir à ce propos Styling using the lang attribute) ;
  • la ou les langue(s) primaire(s) d'un document est une métadonnée renseignant sur le document pris comme un tout. Cette information n'est pas destinée au traitement du contenu, mais à celui de la page en tant que ressource Web, lorsqu'il s'agit par exemple d'adresser une version linguistique à l'utilisateur en fonction de ses préférences, ou d'indexer une URI selon une langue de référence, etc. La langue primaire du document désigne finalement la langue du public visé.

Cette distinction peut paraître déroutante. Risquons quelques exemples pour bien en percevoir la nature :

  • Je publie un même article à travers 2 documents Web distincts, l'un en français et l'autre en anglais. Mon article cite sans le traduire un auteur espagnol : mes deux pages Web ne se différencient aux yeux d'un moteur de recherche que par leur langue primaire, le français ou l'anglais. L'indication de celle-ci devra permettre à Google de n'indiquer que la page pertinente dans ses résultats lorsque l'utilisateur a coché l'option Rechercher les pages en français. Le fait que ma page comporte des citations en espagnol n'a ici aucune importance ;
  • Je décide de transformer ma page d'accueil en page bilingue, chaque post étant désormais titré et résumé en anglais et en français : la page d'accueil de Blog & Blues a deux langues primaires, l'anglais et le français. Elle devient pertinente aux yeux d'un moteur de recherche aussi bien pour un utilisateur francophone qu'anglophone ;
  • Dans un article de ce blog, je fais d'abondantes citations de sources anglo-saxonnes sans les traduire : la langue primaire de mon article reste le français, tandis qu'il admettra deux langues de traitement au fil de son contenu (l'anglais et le français). Si un lecteur anglo-saxon fait appel à un traducteur automatique, seules les sections en français devront être prises en compte et traitées par celui-ci ;

Il reste à spécifier ces informations de manière appropriée.

Spécifier la langue de traitement d'un contenu

La langue de traitement d'un contenu est unique pour le contenu concerné, même si un seul document peut comporter des sections successives qui diffèrent par leur langue de traitement :

  • L'élément html étant l'élément racine de tout document HTML, tout ce qu'il contient hérite par défaut de la valeur de ses attributs lang et/ou xml:lang. Tout le contenu de la page (title et autres meta compris) sera donc réputé être dans la langue ainsi indiquée, sauf précision contraire. On écrira donc :
    • En HTML (type mime text/html) : 
      <html lang="fr">
    • En XHTML traité en tant que HTML (type mime text/html) : 
      <html lang="fr" xml:lang="fr" ...>
    • En XHTML traité en tant que XML (type mime application/xhtml+xml) : 
      <html xml:lang="fr" ... >
  • Si une section quelconque du contenu a une langue différente, il suffit de l'indiquer dans les propres attributs lang et xml:lang de son élément conteneur. Par exemple, pour une citation en anglais dans un document dont l'élément html a un attribut lang="fr" et/ou xml:lang="fr" :
    • En HTML (type mime text/html) : 
      <q lang="en">...</q>
    • En XHTML traité en tant que HTML (type mime text/html) : 
      <q lang="en" xml:lang="en">...</q>
    • En XHTML traité en tant que XML (type mime application/xhtml+xml) : 
      <q xml:lang="en">...</q>

    Rappelons que l'attribut xml:lang est l'équivalent XML de l'attribut HTML lang. Pour des raisons de compatibilité, la spécification XHTML conseille d'utiliser simultanéement les deux attributs lorsqu'on tire profit de la nature hybride du XHTML1.0 (à la fois HTML et XML) pour le servir sous le type mime text/html.

    Les attributs lang et xml:lang peuvent être utilisés pour tous les éléments HTML, à l'exception de : applet, base, basefont, br, frame, frameset, iframe, param et script.

    En l'absence d'un balisage spécifique et/ou d'attribut lang-xml:lang valide pour le conteneur, les éléments génériques div et span permettent de préciser un changement de langue.

Spécifier la ou les langues primaires d'un document

La langue primaire d'un document est une métadonnée. Elle est donc logiquement indiquée par un élément meta qui peut prendre des formes diverses selon qu'on se réfère à l'un ou l'autre des standards proposés :

  • Au plus simple, la traditionnelle <meta http-equiv="Content-Language" content="fr" /> ;
  • Plus spécifique, le Dublin Core qui définit la <meta name="DC.Language" scheme="RFC3066" content="fr" />.

Ceci garantit la permanence de l'information, que le document soit consulté en ligne ou après enregistrement local.

L'entête HTTP Content-Language doit reproduire cette information : Content-Language: fr.

Quel standard adopter pour la désignation des langues ?

La spécification HTML4.01 fait actuellement référence à la norme RFC1766 pour la désignation des langues. Celle-ci a cependant été actualisée dans la norme RFC3066 qui doit donc être prise comme référence.

Concrètement, on utilisera :

  • Un code de langue ISO639, du type en (anglais). Lorsqu'ISO639 propose simultanéement des codes à 2 et à 3 caractères, on choisira le code à deux caractères : fr (français) plutôt que fre, conformément à la règle d'usage fixée par la norme RFC3066 pour garantir l'unicité du code de langue et maintenir la validité des documents antérieurs à ISO639-2 ;
  • Ce code de langue peut être éventuellement suivi d'un ou plusieurs codes secondaires de pays (ISO3166), de région ou de dialecte, séparés par un tiret, du type en-US (anglais - Etats-Unis). Voir à ce sujet Specifying language attribute values.

Ces codes sont indifférents à la casse.

Signalons enfin quelques codes de langue génériques dont l'usage demande à être précisé :

  • art : Autres langues artificielles ;
  • mis : Diverses langues ;

Les codes mul (Multilingue) et und (Langue indéterminée) n'ont pas lieu d'être utilisés en (X)HTML : RFC3066 précise en effet que :

  • mul ne doit pas être utilisé lorsque le protocole concerné autorise l'utilisation d'une série de codes linguistiques, ce qui est le cas de l'en-tête HTTP Content-Language (les valeurs doivent alors être séparées par des virgules) ;
  • und ne doit pas être utilisé lorsqu'il est possible d'omettre la mention de la langue, ce qui est le cas en (X)HTML. Notons à ce propos qu'en XHTML traité en tant que XML, un attribut vide xml:lang="" signifie qu'aucune langue n'est attribuable à l'élément concerné, annulant de ce fait la langue spécifiée à un niveau supérieur.

Quelques cas spécifiques

Par défaut, la langue d'un attribut XHTML est celle de son élément. Il n'est pas possible, en l'état actuel de la technique, de préciser que la langue du contenu d'un attribut est différente de celle de l'élément concerné. Ceci concerne concrètement par exemple :

<q lang="en" title="Information supplémentaire en français">Some english text</q>

La gestion des formats de date/heure est également problématique :

<p lang="fr">Publié le 02/03/04...</p>

... ne permet pas de dissiper l'ambiguïté sur le format de date utilisé, qui reste susceptible d'être lu :

  • "4 mars 2002" selon le format usuel au Japon ;
  • "2 mars 2004" selon le format usuel français ;
  • "3 février 2004" selon le format usuel nord-américain.

Pour éviter ces ambiguïtés, voir les éléments de réponse apportés par How do I prepare my web pages to display varying international date formats?, ainsi que par Dates and Time.

En revanche, le format de date de l'attribut datetime des éléments ins et del est apparemment clairement défini indépendamment de la langue par la spécification HTML4.01 : il s'agit de l'un des formats disponibles dans le profil DATETIME, c'est à dire typiquement :

<ins datetime="2003-03-02">...</ins>

Qui doit être interprété comme le 2 mars 2003 (format AAAA-MM-JJ).

Citons enfin une remarque concernant l'usage de l'attribut hreflang pour indiquer la langue des documents-cibles des liens :

Si vous recourez aux CSS pour générer un marqueur linguistique [visuel] à partir de l'attribut hreflang, n'utilisez pas des icônes de drapeaux pour indiquer la langue.

Les drapeaux représentent des pays, et non des langages. De nombreux pays partagent la même langue, et de nombreux autres pays ont plus d'une langue officielle.

Une bien meilleur démarche consiste à générer du texte [...]

Trackbacks

1. Le 06 décembre 2004 à 13:15, de Empyrée

Internationalisation du Web

Comme à son habitude, Laurent Denis se fend d?un excellent article sur le codage de haute qualité (n?ayons pas peur des mots), cette fois-ci sur l?internationalisation des pages. Voici les points qui me¹ paraissent importants : Deux ou trois...

Les trackbacks pour ce billet sont temporairement fermés en raison d'une série d'attaques de spam.

Commentaires

Olivier G., le 20 octobre 2004

je ne comprends pas dans le passage suivant :
'En XHTML traité en tant que HTML (type mime text/html) :

<q lang="en" xml:lang="fr">...</q>'
la différence de valeur entre lang et xml:lang

Laurent Denis, le 20 octobre 2004

Une simple coquille smiley clin d'oeil Merci.

David Cédric Latapie, le 20 octobre 2004

Aucune. Le lang est pour un parseur html, le xml:lang pour un parseur xml. Comme le XHTML 1.0 est par essence un langage de transition, on met les deux. Ne mettre que l'un des deux est correct mais pas dans l'esprit de transition.


Sinon Laurent, je te conseilles de lire cet article sur les hreflang.
annevankesteren.nl/archiv...

Laurent Denis, le 20 octobre 2004

Aurais-je recommandé quoi que ce soit en matière d'hreflang à l'insu de mon plein gré ? smiley clin d'oeil

Voici en tout cas le peu que j'avais à en dire aujourd'hui sur le Webmaster-Hub :

Enfin, pour en revenir au sujet de ce fil, j'ai été en fait assez surpris par cette remarque de détail sur les drapeaux et hreflang dans ce document du W3C : hreflang pose en fait d'autres problèmes bien plus importants dans le contexte d'un site "internationalisé", et l'employer dans un lien vers un tel site n'est pas si évident:

  • il suppose que vous vérifiez régulièrement le site en question, pour vous assurer qu'il ne se met pas à pratiquer le content-negociation sur la langue de préférence de ses visiteurs... auquel cas, un site avec un hreflang="en" pourra très bien se retrouver du jour au lendemain à adresser une page en français à ses visiteurs.
  • Quid d'une page dont la langue primaire est en français, mais dont le contenu est essentiellement composé de citations dans l'autres langues ?
  • Inversement, comment faire l'hreflang d'un site ayant plusieurs langues primaires ?

[...]

Un navigateur vraiment intelligent (comme nous en aurons dans quelques années, je crois), ajoutera lui-même au survol d'un lien (ou lors d'une autre fonction sur un lien tel que la carte des liens externe d'une page / d'un site) le signalement de la langue, sous la forme choisie par l'utilisateur selon ses préférences (un p'tit drapeau, un code ISO langue, un nom de langue explicite, etc).

De même, un moteur de recherche intelligent (si, si, il y en aura un jour ) pourra exploiter l'attribut herflang des liens en rapport avec la pertinence d'un lien dans une requête faite à partir d'une langue donnée vers une autre langue donnée.

Une machine traductrice pourra anticiper l'éventuelle demande de l'utilisateur de consulter la cible d'un lien dans une version traduite, dès lors que l'attribut hreflang du lien sera explicité. Et à la manière de la navigation rapide dans Opera, il aura préparé cette traduction avant que l'utilisateur ne clique.

Mais encore faut-il pour cela que l'attribut en question soit spécifié, lorsque c'est possible. Donc, oui, hreflang doit figurer dans le code.

Peut-on s'en abstenir pour les liens dans la langue de la page elle-même ? Par paresse, oui. Mais rien n'obligerait un des outils ci-dessous à extrapoler la langue cible d'un lien à partir de la langue primaire de la page d'origine... Disons que c'est un pas de plus à franchir aujourd'hui, si on le souhaite.

Expliciter via CSS cet attribut pour renseigner immédiatement l'utilisateur sur la langue du document-cible ? C'est actuellement la seule application pratique de cet attribut. Pourquoi s'en priver ?

Bobe, le 25 octobre 2004

Je ne pense pas qu'il y ait d'ambiguité concernant le format du contenu de l'attribut datetime. Ce format est indiqué dans la recommandation:
www.la-grange.net/w3c/htm...

Laurent Denis, le 25 octobre 2004

Autant pour moi sur le format de datetime. Merci smiley clin d'oeil

David Latapie, le 06 novembre 2004

Mais encore faut-il pour cela que l'attribut en question soit spécifié, lorsque c'est possible. Donc, oui, hreflang doit figurer dans le code.>

Je suis d'accord (et enthousiaste) avec ce qu'en dit le webmaster-hub, mais je ne comprends plus du coup l'utilité du hreflang. Le navigateur devrait pré-charger les entêtes http des pages liées et signaler les langues supportées à ce moment-là. Et du coup le hreflang ne serait d'aucune utilité…

Aurais-je mal compris quelque chose ?

Laurent Denis, le 06 novembre 2004

Je me suis mal exprimé, David, comme à mon habitude : la présence d'un hreflang dispenserait le navigateur d'interroger les en-têtes HTTP des liens présent dans le document. On voit immédiatement la limite de cette technique : si le contenu de la cible ou son mode de language negociation ont changés, l'information n'est plus pertinente. L'interrogation de l'en-tête HTTP est déjà plus fiable... à condition que celui-ci soit lui-même correctement renseigné smiley clin d'oeil

David Latapie, le 06 novembre 2004

Comme à mon habitude aussi, ma réponse qui devait d'abord être dans le commentaire va être un billet entier (que je signalerais ultérieurement, par un trackback). Cependant, je vais te poser deux questions supplémentaires (et oui) ici même.

- Y a-t-il un moyen d'être notifié des réponses aux commentaires (comme dans Dotclear) ? Pour le moment, je crée un répertoire "vérifier les commentaires" avec des URI à l'intérieur. C'est un peu lourd smiley sourire

- À propos des codes de langue ISO639 et de la primauté au 639-1 sur le 639-2 : pourquoi et quelle est ta source?

Au plaisir de te relire

Laurent Denis, le 06 novembre 2004

@David> Hum... il y a un feed RSS des commentaires pour chaque billet. Mais je n'ai pas le temps en ce moment de faire évoluer le CMS DotClear de ce blog, qui en aurait bien besoin d'ailleurs.

Pour les ISO639, j'avoue que quelque-chose m'échappe dans la question ?

Laurent Denis, le 07 novembre 2004

@David> Je devais être un peu endormi hier, à propos du choix ISO639-1 v. ISO639-2 :

RFC 3066 ( www.ietf.org/rfc/rfc3066.... ) dit clairement que: "When a language has both an ISO 639-1 2-character code and an ISO 639-2 3-character code, you MUST use the tag derived from the ISO 639-1 2-character code."
C'est d'ailleurs un des points de la FAQ i18n du W3C : www.w3.org/International/... Cette règle permet de s'assurer qu'un code unique est utilisé pour une langue, et que les documents antérieurs à ISO 639-2 n'auront pas à être modifiés.

David Latapie, le 11 novembre 2004

Merci pour l'info Laurent. Je met ça dans un coin.

Vincent Arnaud, le 03 janvier 2005

Bonjour à tous,

Tout d'abord, bravo pour ce contenu et ce contenant intelligents...

Concernant les attributs hreflang="" et lang="", à votre avis, lequel de ces deux attributs obtiendra un rôle déterminant lorsque le SSML sera parvenu à maturité ? Plus précisément, en terme de synthèse vocale, est-il suffisant de spécifier la langue ou est-il recommandé de spécifier précisément la variété "régionale" ou "dialectale" utilisable pour la lecture avec un TTS (Text-to-Speech) ?

Par exemple, une page contenant un lexique spécifiquement québécois, doit-elle être spécifiée avec la valeur "fr" ? Existe-t-il une valeur "fr-qc" comme il existe des valeurs distinctes pour l'anglais de Grande-Bretagne et l'anglo-américain ? Autre exemple, un site touristique traitant de la région de Marseille, doit-il pouvoir être lu avec une voix de synthèse neutralisée ou avec une voix présentant un accent méridional ? Concernant le français, des normes régionales sont-elles codifiées ?

En linguistique, pendant des années la variation n'a pas eu sa place (je rappelle au passage que les jugements de valeur du type "c'est à Paris, qu'on parle le plus beau français !" ou "les québécois ont un accent pourri" sont encore d'actualité). Quant aux entreprises commerciales en synthèse de la parole, elles sont encore peu sensibles aux variations régionales (mis à part pour l'anglais et le français québécois avec Scansoft).

Alors pensez-vous que le monde des développeurs anomymes puissent par l'intermédiaire d'un attribut linguistique faire bouger les choses en faveur de la diversité...

Si cette courte lettre ouverte est en dehors de vos préoccupations, je vous prie de m'en excuser.

Vincent

David Latapie, le 03 janvier 2005

fr-fr
fr-qc
fr-be
fr-ch
…

Tous basés sur l'ISO 639

On peut même aller plus loin
de-ch-be
Pour l'allemand parlé à Berne (en Suisse). Mais là, ce n'est plus vraiment standard.
www.barebones.com/images/...

Vincent Arnaud, le 04 janvier 2005

Merci pour cet éclairage.

D'après le document suivant, (www.w3.org/International/...

"Subtags can be added to indicate geographic, dialectal, script, or other refinements to the primary (language) tag. Any number of subtags can follow the primary tag, although it is unusual to see more than one. RFC 3066 specifies that any 2-letter tags in the second subtag must be ISO 3166 country codes. There are no rules for any third and subsequent subtags that are used."

Donc si théoriquement la variation régionale ou dialectale peut être définie, dans les faits, le premier couple de lettres compris dans l'attribut xml:lang="" stipule la langue et le second couple indique généralement l'usage qui est fait de la langue dans un pays donné (cf. les codes des pays ISO 3166) et non des variations locales ou régionales.

A ce propos, le document précédent stipule également qu'il s'agit de l'une des limitations des codes linguistiques RFC3066 :
"They don't cover the needs to express general regions; for example, there is still no tag for the generalized Latin-American Spanish that many organizations use to create Spanish content."

Par conséquent, si mon interprétation est correcte (?) le code "xml:lang="fr-qc" n'existe pas. Il faudrait donc utiliser les codes "xml-lang="fr-CA" ou peut-être "xml-lang="fr-CA-qc". Par contre, le code PF correspondant à la Polynésie Française existe (www.iso.org/iso/en/prods-... il serait donc possible de coder "xml-lang="fr-PF"...

Tout cela me parait très bizarre, suis-je "à côté de mes pompes", qu'en pensez-vous ?

David Latapie, le 05 janvier 2005

Intéressante analyse, qui mérite d'être signalé à part entiière. J'attends d'éventuelles réactions avant de bloguer dessus.

La troisième (ou plus) sous-balise peut servir :
- dans un Intranet
- pour des documents qui doivent être moulinés par une application faite pour.

Par exemple, justement, un générateur de CSS Audio pour un présentoir touristique
fr-fr pour vendre le bouzin à un office de tourisme français
fr-qc pour la Belle Province
fr-fr-ma, Pour l'automate d'accueil de la mairie de Marseille (ou de l'OM), peuchère!

Laurent Denis, le 05 janvier 2005

le code "fr-qc" n'existe pas, en effet ("QC" n'existe pas dans les normes utilisées ici), et le code approprié est "fr-CA".

Pour revenir à la question originale: " Plus précisément, en terme de synthèse vocale, est-il suffisant de spécifier la langue ou est-il recommandé de spécifier précisément la variété "régionale" ou "dialectale" utilisable pour la lecture avec un TTS (Text-to-Speech) ?"

Les variantes régionales du type "français de Marseille" ne sont pas actuellement précisables. Leur enregistrement peut cependant être proposé à l'IANA (voir les ajouts listés dans www.iana.org/assignments/... , et la section 3 de www.ietf.org/rfc/rfc3066.... pour leur procédure de soumission).

L'automate d'accueil de la mairie de Marseille pourrait se voir attribuer son accent via CSS speech smiley clin d'oeil

Vincent Arnaud, le 05 janvier 2005

Bonjour à tous et surtout un grand merci de vos réactions.

Laurent, pour rebondir sur ta remarque précédente, si les variantes régionales ou dialectales ne sont pas NORMALISEES au niveau international, il n'en reste pas moins que des voix de synthèse sont déjà disponibles ou sont (et seront de plus en plus) en cours de développement pour de nombreuses variétés de français et de nombreuses autres variétés de langues (je pense, par exemple à l'arabe dont les caractéristiques phonétiques et lexicales diffèrent entre le maghreb et le moyen-orient). Il existe même un projet de reconstruction vocale du latin classique (voir les liens ci-dessous) !

Alors si, au sein des standards internationaux, une langue comme l'esperanto est enregistrée, les webmestres ne doivent-ils pas faire pression, en utilisant des codes linguistiques non-standard, afin la voix sur le web ne soit pas seulement le reflet des choix commerciaux ?
A titre d'exemple, je rappelle que si Opera 7.60 preview intègre un module de synthèse vocale, ce module s'appuie sur les voix développées par Microsoft et donc sur les choix linguistiques faits par cette entreprise !

Quelques liens :
Un début de synthèse prometteur du français méridionnal
194.57.187.30/~hirst/BDph...

Une voix commerciale de synthèse du français canadien (ou québécois ?)
www.scansoft.com/realspea...

Une voix de synthèse librement utilisable en français québécois (encore en phase développement)
www.smithware.ca/qcmbrola...

La reconstruction d'une voix de synthèse en latin classique
www2.unil.ch/imm/docs/LAI...

Merci encore de votre ouverture d'esprit et de vos remarques constructives

PS : dans mon message précédent, les liens indiqués ne sont pas accessibles directement pour cause de paranthèses, désolé.

Laurent Denis, le 05 janvier 2005

Si j'en crois la FAQ ISO639.2 ( www.loc.gov/standards/iso... ):
"A dialect of a language is usually represented by the same language code as that used for the language. If the language is assigned to a collective language code, the dialect is assigned to the same collective language code."

De fait, www.loc.gov/marc/language... qui précise les dialectes regroupés dans les codes de langue collectif, indique les correspondances suivantes:
French [fre] Also collective code for:
- Allevard French
- Morvan French
- Poitevin French
- Saintongeais French

Une variante méridionale trouverait donc en fait sa place dans ce code fre...

Ce qui ne remet pas en cause la possibilité d'associer un rendu vocal spécifique à un texte en français "méridional" via une voice-family (à créer) et un mécanisme de classe CSS3.

Sinon, deux précision :
- le moteur vocal embarqué par Opera est l'oeuvre d'IBM (et non de Microsoft), et effectivement tributaire des choix commerciaux de celui-ci smiley clin d'oeil
- en revanche, voir dans les standards de l'IANA et dans les normes ISO uniquement le reflet de choix commerciaux me semble plutôt réducteur smiley clin d'oeil

David Latapie, le 05 janvier 2005

Quelle différence entre CSS audio et CSS speech ? Lequel est supporté par Opera 7.6/8 ?

Une entreprise toulousaine propose aussi avec Speechissimo une voix très impressionnante, que vous pouvez tester :
blog.empyree.org/?2003/12...

Philippe Worontzoff, le 12 mars 2005

Je me pose une question concernant la langue de traitement : dans le cas d'un mot d'une autre langue communément admit (au point de figurer dans le dictionnaire) quel langue choisi-t-on ?
Par exemple, en admetant que la langue de traitement soit "fr" : "<span lang="la">idem</span>" ou "idem", "<span lang="en">break</span" ou "break" ?

Laurent Denis, le 12 mars 2005

<span lang="en">break</span> pour les lecteurs d'écran, qui auront à passer d'une langue à une autre...

Philippe Worontzoff, le 12 mars 2005

Et pour "Idem" ?

Je suppose à lire ta réponce que ce n'est que pour la prononciation que l'on utilise l'atribut lang dans le cas ou le mot est communément admit.

Lo, le 16 mars 2006

La norme ne fait elle pas mention de mettre des majuscules pour la composante 'pays', par exemple fr-BE et non fr-be.

Les commentaires pour ce billet sont temporairement fermés en raison d'une série d'attaques de spam.