Lisez-moi S.V.P. 

[ table des matières ]

W3C

Pratiques exemplaires pour l'internationalisation de XML

Note de groupe de travail du W3C du 13 février 2008

Cette version :
http://www.w3.org/TR/2008/NOTE-xml-i18n-bp-20080213/
Dernière version :
http://www.w3.org/TR/xml-i18n-bp/
Version précédente :
http://www.w3.org/TR/2007/WD-xml-i18n-bp-20071031/
Rédacteurs :
Yves Savourel, ENLASO Corporation
Jirka Kosek, expert invité
Richard Ishida, W3C

Ce document est également disponible dans les formats non normatifs suivants : version PDF et balisage Diff XHTML par rapport à la publication du 31 octobre 2007.


Résumé

Ce document présente un ensemble de directives pour développer des documents et schémas XML correctement internationalisés. L'observation des pratiques exemplaires décrites ici permet au développeur d'applications XML comme à l'auteur de contenus XML de créer de la matière (material) dans des langues différentes.

Statut de ce document

Cette section décrit le statut de ce document à sa publication. D'autres documents peuvent venir le remplacer. On peut trouver une liste des publications courantes du W3C et la dernière révision de ce rapport technique dans l'index des rapports techniques du W3C à http://www.w3.org/TR/.

Il s'agit d'une note de groupe de travail du W3C de pratiques exemplaires pour l'internationalisation de XML. Ce document a été développé par le groupe de travail Internationalization Tag Set (ITS), sous l'égide de l'activité Internationalization du W3C.

Les commentaires à propos de ce document sont les bienvenus. Veuillez les envoyer à www-i18n-comments@w3.org. Inscrivez « [Comment on xml-i18n-bp WD] » puis, succinctement, l'objet de votre message dans la ligne du sujet. Les archives de cette liste sont accessibles au public.

La publication en tant que note de groupe de travail n'implique pas l'approbation des membres du W3C. Ce document est une ébauche qui peut être mise à jour, remplacée ou rendue obsolète à tout instant par d'autres documents. Il n'est pas approprié de citer ce document sinon comme d'un travail en cours.

Ce document a été produit par un groupe agissant sous couvert de la politique de brevets du W3C du 5 février 2004. Le W3C tient une liste publique des divulgations de brevets effectuées en rapport avec les produits livrables du groupe ; cette page contient également des instructions pour divulguer un brevet. Quiconque a connaissance véritable d'un brevet qu'il estime contenir des revendications essentielles doit divulguer cette information conformément à la section 6 de la politique de brevets du W3C.

Table des matières

Annexes


Vers la table des matières. 1 Introduction

Ce document complète la recommandation du Jeu de balises d'internationalisation (ITS) version 1.0 [ITS] du W3C. Toutefois le balisage décrit dans ITS ne peut pas résoudre tous les problèmes liés à l'internationalisation. Les pratiques exemplaires (best practices) dans ce document dépassent donc l'application du balisage ITS pour s'intéresser à plusieurs problèmes que l'on peut éviter en concevant correctement le format XML et en suivant quelques conseils supplémentaires lors du développement du contenu.

Ce document et le Jeu de balises d'internationalisation (ITS) version 1.0 [ITS] mettent en œuvre les exigences formulées dans les Exigences du balisage d'internationalisation et de localisation [ITS REQ].

Cet ensemble de pratiques exemplaires ne couvre pas tous les sujets concernant l'internationalisation de XML. D'autres documents de référence utiles comprennent la spécification Modèle de caractères pour le Web 1.0 — Fondamentaux [CharMod] et la note Unicode dans XML et les autres langages de balisage [Unicode in XML].

Vers la table des matières. 1.1 À qui s'adresse ce document

Ce document se divise en deux parties principales :

  • la première est destinée aux concepteurs et développeurs d'applications XML (également désignées ici comme étant des « schémas » ou des « formats ») ;

  • la deuxième est destinée aux créateurs de contenu XML. Sont inclus les utilisateurs qui modifient le contenu original tels que les traducteurs.

Vers la table des matières. 1.2 Comment utiliser ce document

Vers la table des matières. 1.2.1 Concepteurs et développeurs d'applications XML

La section 2 Lors de la conception d'une application XML dresse une liste de quelques décisions de conception importantes à prendre pour s'assurer de l'internationalisation de son format.

La section 4 Techniques génériques donne des techniques génériques supplémentaires telles que l'écriture des règles ITS ou l'ajout d'un attribut à un schéma. Ces techniques s'appliquent à beaucoup de pratiques exemplaires.

La section ITS appliqué aux formats existants fournit un ensemble d'exemples concrets sur la façon d'appliquer ITS aux formats existants fondés sur XML. Cette section illustre plusieurs directives dans ce document.

Vers la table des matières. 1.2.2 Utilisateurs et créateurs de contenus XML

La section 3 Lors de la création d'un contenu XML donne de nombreux conseils sur la façon de créer du contenu en gardant le souci de l'internationalisation à l'esprit. Beaucoup de ces pratiques exemplaires sont pertinentes indépendamment du format XML, que celui-ci ait été développé spécialement pour l'internationalisation ou non.

La section 4.1 Écriture des règles ITS donne des conseils pratiques pour écrire des règles ITS. Ces techniques peuvent être utiles pour appliquer des pratiques exemplaires plus avancées pour la création.

Vers la table des matières. 2 Lors de la conception d'une application XML

Les concepteurs et développeurs d'applications XML devraient tenir compte des pratiques exemplaires suivantes :

Pratique exemplaireMise en œuvre en tant que nouvelle fonctionTraitement du balisage existant
Définir un balisage pour indiquer la langue S'assurer que l'attribut xml:lang est défini pour l'élément racine du document et pour tout élément où la langue peut changer. Fournir un document de règles ITS où on se sert de l'élément its:langRule pour définir quel attribut ou élément est utilisé à la place de xml:lang.
Définir un balisage pour indiquer la direction du texte S'assurer que l'attribut its:dir est défini pour l'élément racine du document et pour tout élément contenant du texte. Fournir un document de règles ITS où on se sert de l'élément its:dirRule pour associer les différents indicateurs de directionnalité à leurs équivalents dans ITS.
Éviter les valeurs d'attribut traduisibles S'assurer de réserver tout le texte traduisible dans le contenu de l'élément, non dans les valeurs d'attributs. Fournir un document de règles ITS où on se sert de l'élément its:translateRule pour indiquer quels attributs sont traduisibles.
Indiquer quels éléments et attributs traduire Fournir un document de règles ITS où on se sert de l'élément its:translateRule pour indiquer quels éléments ont un contenu non traduisible.
Définir un balisage pour écraser l'information de traduction
  • S'assurer que l'attribut its:translate est défini pour l'élément racine du document et pour tout élément qui contient du texte ;

  • Il est également recommandé de définir dans son schéma l'élément its:rules, par exemple dans un en-tête s'il y en a un, et d'y placer l'élément its:translateRule. Les créateurs de contenus peuvent utiliser ces éléments pour changer globalement les règles de traduction par défaut d'éléments et attributs spécifiques.

Fournir un document de règles ITS où on se sert de l'élément its:translateRule pour associer ce mécanisme à la catégorie de données ITS Traduire.
Fournir des informations liées à la segmentation du texte Fournir un document de règles ITS où on se sert d'éléments its:withinTextRule pour indiquer quels éléments traiter soit dans le cadre de (as part of) leurs parents, soit comme une longueur de texte (run of text) imbriquée mais indépendante. Par défaut, les frontières (boundaries) des éléments sont censées correspondre aux frontières de la segmentation.
Définir un balisage pour le texte ruby S'assurer que l'élément its:ruby et ses sous-éléments sont définis pour tous les éléments contenant du texte. Fournir un document de règles ITS où on se sert de l'élément its:rubyRule pour associer le balisage ruby à son équivalent dans ITS.
Définir un balisage pour les notes aux traducteurs
  • S'assurer que les attributs its:locNote, its:locNoteType et its:locNoteRef sont définis dans le schéma. Ce balisage permet aux créateurs de contenus de fournir des notes pour la localisation en valeurs des attributs its:locNote, ou de pointer vers l'emplacement du texte de la note pertinente avec its:locNoteRef ;

  • Il est également recommandé de définir dans son schéma l'élément its:rules, par exemple dans un en-tête s'il y en a un, et d'y placer l'élément its:locNoteRule et le balisage en rapport. Les créateurs de contenus peuvent utiliser ce balisage pour laisser des notes touchant la localisation. Au sein de l'élément its:locNoteRule, les notes peuvent être stockées dans l'élément its:locNote.

Fournir un document de règles ITS où on se sert de l'élément its:locNoteRule pour associer le balisage des notes avec son équivalent dans ITS.
Définir un balisage pour les identificateurs uniques S'assurer que les éléments avec un contenu traduisible puissent être associés à un identificateur unique.
Identifier les éléments terminologiques Fournir un document de règles ITS où on se sert d'éléments its:termRule pour indiquer quels éléments sont des termes et lesquels des informations qui s'y rattachent (par exemple des définitions).
Définir un balisage pour spécifier ou écraser des informations terminologiques
  • S'assurer que les attributs its:term et its:termInfoRef sont définis pour tout élément contenant du texte ;

  • Il est également recommandé de définir dans le schéma l'élément its:rules, par exemple dans un en-tête s'il y en a un. L'élément its:rules fournit un accès à l'élément its:termRule qui peut servir à écraser (override) globalement les informations terminologiques.

Travailler avec des documents multilingues Pour les documents qui ont besoin de passer par des tâches de localisation, toujours stocker la version localisée du texte dans un document séparé.
Nommer les éléments et les attributs
  • S'assurer que les noms des éléments et attributs du schéma réflètent leurs fonctions plutôt qu'une interprétation (rendering) possible de leurs contenus ;

  • Si possible, éviter également les noms d'élément qui ne suivent pas un schéma de nommage fixé (par exemple, des noms d'élément qui servent aussi d'identificateurs).

Néant
Définir un élément de type span S'assurer de définir un élément de type span (span-like element) dans le schéma, qui permet aux créateurs d'associer un contenu arbitraire aux propriétés telles que la directionnalité, l'information de langue, etc. Si le schéma ne contient pas déjà un élément de type span, on peut utiliser its:span.
Documenter les fonctions d'internationalisation et de localisation de son schéma S'assurer de documenter les aspects d'internationalisation et de localisation de son schéma en fournissant un ensemble de règles ITS pertinentes en un seul document de règles ITS autonome (standalone).

La mention « Comment le mettre en œuvre en tant que nouvelle fonction » dans cette section décrit comment créer de nouveaux schémas ou ajouter de nouvelles fonctions (features) à des schémas existants. Lorsqu'on le fait, on doit tenir compte des points suivants :

Remarque : Les observations ci-dessus ne représentent qu'une partie de ce qu'on doit prendre en compte. La modularisation des schémas demande beaucoup d'autres connaissances.

Fournissez aux auteurs un moyen d'indiquer la langue du contenu avec du balisage ITS, ou documentez le balisage existant équivalent dans un document de règles ITS.

L'attribut xml:lang de l'espace de noms XML et l'élément its:langRule de la catégorie de données Information de langue ITS répondent à cette exigence.

Comment le mettre en œuvre en tant que nouvelle fonction

Assurez-vous que l'attribut xml:lang soit défini pour l'élément racine du document et pour tout élément où la langue peut changer.

Pour des exemples sur la façon d'ajouter des attributs à vos schémas existants, cf. la section 4.2 Exemple d'ajout d'un attribut à un schéma existant.

Certains documents XML peuvent être conçus pour stocker des données sans contenu dans une langue. Auquel cas, l'attribut xml:lang n'est pas nécessaire.

L'attribut xml:lang porte sur les attributs et le contenu de l'élément où il apparaît ; on ne peut donc pas indiquer des langues différentes pour un attribut et le contenu de l'élément. ITS n'offre aucun remède à cela. De préférence, il est recommandé d'éviter les attributs traduisibles.

Assurez-vous que la définition de l'attribut xml:lang autorise des valeurs vides. À savoir :

  • Dans une définition DTD, n'utilisez pas le type de données NMTOKEN mais plutôt le type CDATA ;

  • Dans XML Schema, le type de données natif (built-in) language n'admet pas les valeurs vides. Au contraire, la déclaration de xml:lang dans le document XML Schema de l'espace de noms XML à http://www.w3.org/2001/xml.xsd autorise les valeurs vides et on peut donc l'utiliser.

Il N'EST PAS RECOMMANDÉ d'utiliser son propre attribut ou élément pour indiquer la langue du contenu. L'attribut xml:lang est reconnu par diverses technologies XML telles que XPath et XSLT (par exemple, la fonction lang()). Utiliser autre chose nuirait à l'interopérabilité de vos documents et réduirait vos possibilités de tirer profit de certaines applications XML.

Remarque : Si vous avez besoin d'indiquer la langue comme une donnée ou une métadonnée à propos d'une chose extérieure au document, faites-le avec un autre attribut que xml:lang. Pour plus de renseignements, cf. l'article xml:lang dans les schémas de documents XML.

Exemple 1 : Information de langue non applicable au contenu de l'élément où elle est utilisée.

Dans XHTML, la langue d'un fichier relié avec l'élément a est indiquée par l'attribut hreflang ; elle ne concerne pas le contenu de l'élément a.

<a xml:lang="en" href="german.html" hreflang="de">Click here for German</a>

Si les valeurs d'attributs et le contenu d'un élément ont des langues différentes, envisagez si possible d'imbriquer les éléments. Cf. le Traitement des valeurs d'attributs et du contenu des éléments dans des langues différentes.

Traitement du balisage hors de l'espace de noms ITS

Si vous travaillez avec un schéma existant dans lequel il existe une autre méthode pour définir la langue du contenu que l'attribut xml:lang (mais utilisant la même valeur que xml:lang), vous devriez fournir un document de règles ITS dans lequel vous utiliserez l'élément its:langRule pour indiquer quel attribut ou élément est employé à la place de xml:lang.

Exemple 2 : Traiter avec une méthode non standard de déclarer l'information de langue.

Dans ce document, on utilise l'élément langcode pour indiquer la langue de l'élément text. L'élément langcode n'a pas un comportement d'héritage équivalent à celui de xml:lang.

Remarque : Voici un exemple de document multilingue qui a ses propres problèmes (cf. Pratique exemplaire 12 — Travailler avec des documents multilingues).

<myRes>
 <messages>
  <msg id="1">
   <langcode>en</langcode>
   <text>Cannot find file.</text>
  </msg>
  <msg id="2">
   <langcode>fr</langcode>
   <text>Fichier non trouvé.</text>
  </msg>
 </messages>
</myRes>

[Code source de l'exemple]

Le document de règles ITS correspondant contient un élément its:langRule indiquant que l'élément langcode reçoit les mêmes valeurs que l'attribut xml:lang et s'applique à l'élément text.

<its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
 <its:langRule selector="//text[../langcode]" langPointer="../langcode"/>
</its:rules>

[Code source de l'exemple]

Pourquoi le faire

L'information à propos de la langue du contenu peut être très importante pour l'interprétation ou le stylage corrects du texte dans certaines écritures, l'application d'une correction orthographique lors de la création du contenu, la bonne sélection de la voix des synthétiseurs texte-parole (text-to-speech systems), le traitement d'après l'écriture, et bien d'autres raisons. Vous devez fournir une méthode standard pour indiquer la langue du document entier mais aussi pour les parties du document où la langue change.

Ressources :

Documentation de base

Liens de références

Fournissez aux auteurs un moyen d'indiquer la direction du texte avec du balisage ITS, ou documentez le balisage existant équivalent dans un document de règles ITS.

Dans des écritures telles que l'arabe et l'hébreu, les caractères peuvent avancer de gauche à droite et de droite à gauche à l'affichage. Un balisage directionnel permet de gérer le flux des caractères. Pour un exemple de la façon d'utiliser le balisage directionnel, cf. l'article Créer des pages (X)HTML en arabe et en hébreu.

La catégorie de données Directionnalité ITS fournit l'attribut its:dir et l'élément its:dirRule pour répondre à cette exigence.

Comment le mettre en œuvre en tant que nouvelle fonction

Assurez-vous que l'attribut its:dir soit défini pour l'élément racine du document et pour tout élément contenant du texte.

Pour des exemples sur la façon d'ajouter des attributs à vos schémas existants, cf. la section 4.2 Exemple d'ajout d'un attribut à un schéma existant.

Traitement du balisage hors de l'espace de noms ITS

Si vous travaillez avec un schéma existant dans lequel il existe une autre méthode pour indiquer la directionnalité du texte que l'attribut its:dir vous devriez fournir un document de règles ITS dans lequel vous utiliserez l'élément its:dirRule pour associer les indicateurs de directionnalité différents à leurs équivalents dans ITS.

Exemple 3 : Indiquer la directionnalité du texte où un balisage non-ITS a été utilisé.

Dans ce document, l'attribut textdir sert à indiquer la directionnalité d'une longueur de texte.

<text xml:lang="en">
 <body>
  <par>In Hebrew, the title
     <quote xml:lang="he" textdir="r2l">פעילות הבינאום, W3C</quote>
     means <quote>Internationalization Activity, W3C</quote>.</par>
 </body>
</text>

Remarque : Cette exemple montre correctement la directionnalité du texte source pour bien comprendre les concepts décrits. Pour un tel affichage, il faut un éditeur sophistiqué qui résolve correctement la directionnalité du texte source. Beaucoup d'éditeurs n'ont pas ce degré de sophistication. Cf. l'explication liée à propos des Problèmes avec le texte source bidirectionnel dans [Bidi in X/HTML].

[Code source de l'exemple]

Le document de règles ITS correspondant contient un ensemble d'éléments its:dirRule qui définissent les relations entre l'attribut textdir et la catégorie de données Directionnalité ITS.

<its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
 <its:dirRule selector="//*[@textdir='l2r']" dir="ltr"/>
 <its:dirRule selector="//*[@textdir='r2l']" dir="rtl"/>
 <its:dirRule selector="//*[@textdir='lro']" dir="lro"/>
 <its:dirRule selector="//*[@textdir='rlo']" dir="rlo"/>
</its:rules>

[Code source de l'exemple]

Pourquoi le faire

L'algorithme bidirectionnel Unicode (Unicode bidirectional algorithm) produira généralement le rangement correct d'un texte à bidirectionnalité mélangée dans des écritures telles que l'arabe et l'hébreu. Quoiqu'il en soit, une assistance supplémentaire est parfois nécessaire. Par exemple, dans la phrase de l'exemple 4, le « W3C » et la virgule devraient apparaître à gauche de la citation. On ne peut pas y parvenir en utilisant seulement l'algorithme bidirectionnel.

Exemple 4 : Phrase où un balisage directionnel est nécessaire pour un affichage correct.

La phrase suivante ne s'affichera pas correctement car aucun balisage directionnel n'a été utilisé :

Le titre en hébreu dit « פעילות הבינאום, W3C ».

Le mot « W3C » et la virgule devrait apparaître à gauche du texte hébreu cité. Si votre navigateur est capable d'un affichage bidirectionnel, la phrase suivante devrait s'afficher correctement car on a ajouté un balisage directionnel à l'élément englobant la citation :

Le titre en hébreu dit « פעילות הבינאום, W3C ».

On peut obtenir l'effet voulu en utilisant des caractères de contrôle Unicode, mais ce n'est pas recommandé (cf. Unicode dans XML et les autres langages de balisage [Unicode in XML]). Un balisage est nécessaire pour établir la directionnalité par défaut du document et pour la changer là où c'est approprié en créant des niveaux d'incorporation imbriqués (nested embedding levels).

Un balisage est également nécessaire à l'occasion pour annuler les effets de l'algorithme bidirectionnel sur une longueur de texte donnée.

Ressources :

Documentation de base

Liens de références

Ne définissez pas de valeurs d'attributs qui auront du contenu lisible par l'utilisateur ; utilisez des éléments pour de tels contenus.

Comment le mettre en œuvre en tant que nouvelle fonction

Assurez-vous de stocker tout le texte traduisible comme contenu d'un élément, non comme valeurs d'attributs.

Exemple 5 : Éviter les valeurs d'attribut traduisibles.

C'est une mauvaise idée de stocker le texte descriptif de remplacement de l'élément image dans l'attribut desc, comme dans cet exemple.

<image src="elephants.png" desc="Elephants bathing in the Zambezi River."/>

Définissez plutôt l'élément image même pour contenir le texte nécessaire. De cette manière, il n'y a pas de texte traduisible dans un attribut.

<image src="elephants.png">Elephants bathing in the Zambezi River.</image>

Remarque : Dans beaucoup de cas, utiliser un contenu d'élément traduisible au lieu d'attributs traduisibles se traduira par une seule phrase incorporée au sein d'une autre. Ainsi, dans l'exemple 5, la description de l'image se nichera dans le texte du paragraphe qui la contient. Auquel cas, n'oubliez pas de déclarer l'élément concerné (ici image) comme étant « imbriqué », ainsi que décrit dans la Pratique exemplaire 6 — Fournir des informations pour la segmentation du texte.

Traitement du balisage hors de l'espace de noms ITS

Si vous travaillez avec un schéma existant dans lequel il y a des attributs avec des valeurs traduisibles, vous devriez fournir un document de règles ITS dans lequel vous utiliserez l'élément its:translateRule pour indiquer quels attributs sont traduisibles. Cf. la Pratique exemplaire 4 — Indiquer quels éléments et attributs traduire pour plus de renseignements sur la façon de le faire.

Pourquoi le faire

Le stockage de texte traduisible en valeurs des attributs crée plusieurs problèmes. En voici quelques uns :

  • Le mécanisme d'identification de la langue (c'est-à-dire xml:lang) s'applique à la fois au contenu et aux valeurs d'attributs de l'élément où on le déclare. Si le texte d'un attribut est dans une langue différente de celle du texte contenu dans l'élément, on ne peut pas fixer correctement la langue des deux ;

  • Il peut être nécessaire d'appliquer des propriétés de langue, telles que la directionnalité et l'identification de la langue, seulement à une partie du texte dans une valeur d'attribut. Cela oblige à utiliser un élément de type span, mais on ne peut pas utiliser d'éléments dans une valeur d'attribut ;

  • Il est difficile d'appliquer des méta-informations, telles que des drapeaux ne pas traduire (no-translate flags), des notes du créateur, etc., au texte d'une valeur d'attribut ;

  • La difficulté de rattacher des identificateurs uniques au texte des attributs traduisibles rend l'utilisation des outils de déploiement (leveraging tools) fondés sur des ID plus compliquée ;

  • Il peut se révéler problématique de préparer des attributs traduisibles pour une localisation, parce qu'ils apparaissent dans le contenu d'un élément traduisible, en l'interrompant en parties différentes et en modifiant éventuellement la structure de la phrase.

Tous ces problèmes potentiels sont moins susceptibles de se produire lorsque le texte est le contenu d'un élément plutôt que la valeur d'un attribut.

Ressources :

Documentation de base

Liens de références

Documentez dans un document de règles ITS quels éléments et attributs traduire et lesquels ne pas traduire, lorsque cela diffère des valeurs par défault ITS.

La catégorie de données Traduire ITS fournit l'élément its:translateRule pour répondre à cette exigence.

Comment le faire

Fournir un document de règles ITS dans lequel on se sert d'éléments its:translateRule pour indiquer quels éléments ont un contenu non traduisible.

Si vous travaillez avec un schéma dans lequel il y a des attributs traduisibles (ce qui n'est pas recommandé), vous devriez aussi utiliser its:translateRule pour indiquer lesdits attributs traduisibles.

Remarque : Lorsque la langue du contenu est donnée par xml:lang="zxx", où zxx indique un contenu qui n'est pas une langue, l'élément en question ne doit probablement pas être traduit. Vous devriez fournir une règle pour ça.

Exemple 6 : Document où les règles Traduire ITS par défaut ne s'appliquent pas.

Dans le document suivant, le contenu de l'élément head ne devrait pas être traduit et la valeur de l'attribut alt devrait l'être. De plus, le contenu de l'élément del ne devrait pas être traduit.

<myDoc xml:lang='en'>
 <head>
  <id xml:lang="zxx">H4-A3-F8-A1</id>
  <author>Robert Griphook</author>
  <rev>v13 2007-10-27</rev>
 </head>
 <par>To start click <ins>the <ui>Start</ui>
  button</ins><del>green icon</del>
  and fill the form labeled by the following icon:
  <ref file="vat.png" alt="Value Added Tax Form"/></par>
</myDoc>

[Code source de l'exemple]

Les règles suivantes définissent les exceptions par rapport au comportement ITS par défaut de documents tels que le précédent.

<its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
 <its:translateRule selector="/myDoc/head" translate="no"/>
 <its:translateRule selector="//*/@alt" translate="yes"/> 
 <its:translateRule selector="//del" translate="no" />
 <its:translateRule selector="//@*[ancestor::del]" translate="no"/>
 <its:translateRule selector="//*[lang('zxx')] | //@*[lang('zxx')]" translate="no"/>
</its:rules>
  • Premier translateRule : le contenu de l'élément head dans myDoc n'est pas traduisible. Par héritage, les sous-éléments de head sont réputés non traduisibles également ;

  • Deuxième translateRule : tous les attributs alt sont traduisibles ;

  • Troisième translateRule : le contenu de l'élément del n'est pas traduisible ;

  • Quatrième translateRule : la non-traductibilité de del s'applique également à tout attribut qui aurait pu être défini comme traduisible par une règle précédente (c'est-à-dire la deuxième règle) ;

  • Cinquième translateRule : aucun élément ou attribut dont la langue est "zxx" n'est traduisible.

[Code source de l'exemple]

Pourquoi le faire

Par défaut, ITS suppose que tous les éléments ont un contenu traduisible et que tous les attributs ont des valeurs non traduisibles. Si le type de votre document ne correspond pas à cette présomption (default assumption), il est important d'indiquer quelles sont les exceptions. Ce faisant, on peut améliorer significativement le rendement de la traduction.

Fournissez aux auteurs un moyen d'écraser les règles de traduction par défaut, en utilisant du balisage ITS, ou documentez le balisage existant équivalent dans un document de règles ITS.

La catégorie de données Traduire ITS fournit l'attribut its:translate et l'élément its:translateRule pour répondre à cette exigence.

Comment le mettre en œuvre en tant que nouvelle fonction

Assurez-vous que l'attribut its:translate soit défini pour l'élément racine du document et pour tout élément contenant du texte.

Pour des exemples sur la façon d'ajouter des attributs à vos schémas existants, cf. la section 4.2 Exemple d'ajout d'un attribut à un schéma existant.

Il est également recommandé de définir dans son schéma l'élément its:rules, par exemple dans un en-tête s'il y en a un, et d'y placer les éléments its:translateRule. Les créateurs de contenus peuvent ensuite utiliser ces éléments pour changer globalement les règles de traduction par défaut d'éléments et attributs spécifiques.

Traitement du balisage hors de l'espace de noms ITS

Si vous travaillez avec un schéma dans lequel il existe une autre méthode pour écraser l'information de traduction que l'attribut its:translate, les créateurs des documents devrait l'utiliser. En outre, vous devriez fournir un document de règles ITS dans lequel vous utiliserez l'élément its:translateRule pour associer ce mécanisme à la catégorie de données Traduire ITS.

Par exemple, DITA offre un attribut translate et Glade un attribut translatable. Les deux ont la même sémantique que l'attribut its:translate, à savoir que l'information de traduction s'applique au contenu de l'élément, y compris les sous-éléments, à l'exclusion des valeurs d'attributs.

Exemple 7 : Information de traduction DITA.

Les règles suivantes indiquent comment associer l'attribut translate DITA à la catégorie de données Traduire ITS. L'ordre d'apparition des règles compte :

  • Premier translateRule : indique que le contenu d'un élément avec un attribut translate valant "no" n'est pas traduisible ;

  • Deuxième translateRule : indique qu'une valeur d'attribut d'un élément avec un attribut translate valant "no" n'est pas traduisible. C'est nécessaire car certains attributs sont traduisibles en DITA et nous devons nous assurer qu'ils ne seront pas traduits si translate="no" est utilisé sur les éléments dans lesquels ils se trouvent ;

  • Troisième translateRule : indique que le contenu d'un élément avec un attribut translate valant "yes" est traduisible. On tient ainsi compte des cas où translate="yes" est utilisé pour écraser un translate="no" précédent.

<its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
 <its:translateRule selector="//*[@translate='no']" translate="no"/>
 <its:translateRule selector="//*[@translate='no']/descendant-or-self::*/@*"
  translate="no"/>
 <its:translateRule selector="//*[@translate='yes']" translate="yes"/>
</its:rules>

[Code source de l'exemple]

On peut trouver un exemple plus complet sur la façon d'associer du balisage DITA à ITS à la section 5.4.2 Associer le balisage DITA existant à ITS.

Pourquoi le faire

Dans certains cas, le créateur d'un document peut avoir besoin de changer la propriété de traductibilité sur des parties du contenu, en écrasant le comportement ITS par défaut ou les règles générales du schéma défini lors de l'application de la Pratique exemplaire 4 — Indiquer quels éléments et attributs traduire.

Documentez dans un document de règles ITS comment traiter les éléments en rapport à la segmentation.

La segmentation désigne la façon dont le texte est scindé, d'un point de vue linguistique, en unités manipulables par des processus tels que la traduction.

La catégorie de données Éléments dans du texte ITS fournit l'élément its:withinTextRule pour répondre à cette exigence.

Comment le faire

Que vous créiez un nouveau schéma ou documentiez un balisage existant, fournissez un document de règles ITS dans lequel vous utiliserez des éléments its:withinTextRule pour indiquer quels éléments il faudrait traiter soit dans le cadre de leurs parents, soit comme une longueur de texte imbriquée mais indépendante. Par défaut, les frontières des éléments sont censées correspondre aux frontières de la segmentation.

Exemple 8 : Document DITA avec des éléments de formatage et de note de bas de page.

Dans le document DITA suivant :

  • les éléments term et b devraient être traités dans le cadre de leur parent ;

  • l'élément fn devrait être traité comme une longueur de texte indépendante.

<concept id="myConcept" xml:lang="en-us">
 <title>Types of horse</title>
 <conbody>
  <ol>
   <li>Palouse horse:<p><term>Palouse horses</term><fn>A palouse horse
    is the same as an <b>Appaloosa</b>.</fn> have spotted coats.
    The <term>Nez-Perce</term> Indians have been key in breeding this
    type of horse.</p></li>
  </ol>
 </conbody>
</concept>

[Code source de l'exemple]

L'élément its:withinTextRule sert à définir le comportement de trois éléments, tous les autres éléments sont présumés avoir la valeur its:withinText="no" :

  • Premier withinTextRule : les éléments term et b sont définis dans le cadre du flux de texte ;

  • Deuxième withinTextRule : l'élément fn est défini comme un morceau de contenu séparé imbriqué dans son élément parent.

<its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
 <its:withinTextRule selector="//term | //b" withinText="yes"/>
 <its:withinTextRule selector="//fn" withinText="nested"/>
</its:rules>

Ces règles appliquées au document DITA ci-dessus donneront quatre longueurs de texte distinctes :

  1. title: "Types of horse"

  2. li: "Palouse horse:"

  3. p: "{term}Palouse horses{/term}{fn/} have spotted coats. The {term}Nez-Perce{/term} Indians have been key in breeding this type of horse."

  4. fn: "A palouse horse is the same as an {b}Appaloosa{/b}."

[Code source de l'exemple]

Pourquoi le faire

Beaucoup d'applications qui traitent du contenu pour des tâches en rapport avec la linguistique ont besoin de réaliser une segmentation de base du contenu textuel. Elles doivent pouvoir le faire sans connaître la sémantique des éléments.

Bien qu'il soit souvent possible de détecter automatiquement un contenu composé, il existe des situations où la structure d'un élément empêche les outils de déterminer à coup sûr où tombent les frontières de segmentation appropriées. Par exemple, les frontières de certains éléments dans le texte (inline elements), tels que l'emphase, ne correspondent généralement pas aux frontières de segmentation ; au contraire, certains éléments dans le texte incorporés dans un élément parent, tels que les notes de bas de page ou les citations, peuvent définir des segments qui devraient être traités séparément du texte dans lequel ils sont incorporés.

Une segmentation intelligente est particulièrement importante en traduction pour comparer avec succès un texte source par rapport à des mémoires de traduction (translation-memory databases).

Fournissez aux créateurs un moyen de marquer le texte ruby en utilisant du balisage ITS, ou documentez le balisage existant équivalent dans un document de règles ITS

Le texte ruby est utilisé pour fournir une courte annotation d'un texte de base associé. On l'utilise le plus souvent pour donner un guide de lecture (prononciation).

La catégorie de données Ruby ITS fournit les éléments its:ruby et its:rubyRule, et leurs sous-éléments, pour répondre à cette exigence. La définition de cette catégorie de données est conforme à la spécification du ruby dans [Ruby Annotation].

Comment le mettre en œuvre en tant que nouvelle fonction

Assurez-vous que l'élément its:ruby et ses sous-éléments soient définis pour tous les éléments contenant du texte.

Traitement du balisage hors de l'espace de noms ITS

Si vous travaillez avec un schéma existant dans lequel il existe une méthode pour définir le texte ruby avec la même sémantique que celle de la catégorie de données Ruby ITS (par exemple, celle de l'annotation ruby [Ruby Annotation]), vous devriez fournir un document de règles ITS dans lequel vous utiliserez l'élément its:rubyRule pour associer votre balisage ruby à son équivalent dans ITS.

Exemple 9 : Document avec des éléments pareil au ruby.

Dans ce document, l'élément rubyBlock a la même fonctionnalité que l'élément its:ruby, l'élément rBase que its:rb, l'élément rParen que its:rp et l'élément rText que its:rt.

<text>
 <para>この本は <rubyBlock>
  <rBase>慶応義塾大学</rBase>
  <rParen>(</rParen>
  <rText>けいおうぎじゅくだいがく</rText>
  <rParen>)</rParen>
 </rubyBlock>の歴史を説明するものです。</para>
</text>

[Code source de l'exemple]

Cet élément its:rubyRule indique que l'élément rBase a la même fonctionnalité que l'élément its:rb, les éléments its:ruby, its:rt et its:rt ayant également leurs équivalents.

<its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
 <its:rubyRule selector="//rBase" rubyPointer=".."
  rpPointer="../rParen" rtPointer="../rText" />
</its:rules>

[Code source de l'exemple]

Pourquoi le faire

Le ruby est un type d'annotation du texte. On peut l'utiliser avec n'importe quelle langue, mais il est très souvent employé dans les écritures d'Asie orientale pour fournir les transcriptions de caractères probablement inconnus du lecteur. Par exemple, son emploi est très répandu dans les documents éducatifs et les textes pour enfants. On le rencontre à l'occasion pour communiquer des informations à propos du sens.

Comme on peut avoir besoin d'annotations ruby pour une localisation en japonais ou en chinois, c'est une bonne idée de les prévoir dans son schéma, même si on développe les documents originaux dans une langue qui n'emploie pas un tel balisage.

Fournir aux créateurs un moyen de signaler des notes aux traducteurs en utilisant du balisage ITS, ou documenter le balisage existant équivalent dans un document de règles ITS.

La catégorie de données Note de localisation ITS fournit les attributs its:locNote, its:locNoteType et its:locNoteRef, ainsi que l'élément its:locNoteRule pour répondre à cette exigence.

Comment le mettre en œuvre en tant que nouvelle fonction

Assurez-vous que les attributs its:locNote, its:locNoteType et its:locNoteRef soient définis dans votre schéma. Ce balisage permet aux créateurs de contenus de fournir des notes de localisation comme valeurs d'attributs its:locNote, ou de pointer vers l'emplacement de la note appropriée avec l'attribut its:locNoteRef.

Pour des exemples sur la façon d'ajouter des attributs à vos schémas existants, cf. la section 4.2 Exemple d'ajout d'un attribut à un schéma existant.

Exemple 10 : Illustration de la façon dont un créateur pointerait vers des notes de localisation avec its:locNoteRef

L'élément its:locNote indique que le message d'identificateur NotFound a une note d'explication correspondante dans un fichier HTML externe. L'adresse URI de l'emplacement exact de la note est stockée dans l'attribut its:locNoteRef.

<myRes>
 <head>
  <its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
   <its:locNoteRule locNoteType="description"
    selector="//msg[@id='NotFound']"
    locNoteRef="EX-devlocnotes-4.html#NotFound" />
  </its:rules>
 </head>
 <body>
  <msg id="NotFound">Cannot find {0} on {1}.</msg>
 </body>
</myRes>

[Code source de l'exemple]

Le fichier HTML contenant les notes de localisation est un document simple avec des éléments d'ancrage correspondant aux identificateurs dans le document XML appelant.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> 
 <head>
  <meta http-equiv="Content-Language" content="en-us">
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 
  <title>Localization Notes</title>
 </head> 
 <body lang="en">
 <p><a name="NotFound"></a>{0} is a filename<br />
  {1} is a directory name</p>
 </body>
</html> 

[Code source de l'exemple]

Il est également recommandé de définir dans son schéma l'élément its:rules, par exemple dans un en-tête s'il y en a un, et d'y placer l'élément its:locNoteRule et le balisage en rapport. Les créateurs de contenus peuvent utiliser ce balisage pour signaler des notes en rapport à la localisation. Les notes peuvent être stockées dans l'élément its:locNote au sein de l'élément its:locNoteRule.

L'élément its:locNoteRule permet également de définir des notes dans le document XML courant via l'attribut locNotePointer, ou de fournir une référence existante vers les notes via l'attribut locNoteRefPointer.

Exemple 11 : Illustration de la façon dont un créateur stockerait des notes de localisation dans l'élément its:locNoteRule

L'élément its:locNoteRule associe le contenu de l'élément its:locNote au message avec l'identificateur DisableInfo et le marque comme étant important. Cela fonctionne également si la règle se trouve dans un fichier externe, en permettant aux créateurs de contenus de fournir des notes sans modifier le document source.

<myDoc>
 <head>
  <its:rules xmlns:its="http://www.w3.org/2005/11/its"
   version="1.0" its:translate="no">
   <its:locNoteRule locNoteType="alert" selector="//msg[@id='DisableInfo']">
   <its:locNote>The variable {0} has three possible values: 'printer',
    'stacker' and 'stapler options'.</its:locNote>
   </its:locNoteRule>
  </its:rules>
 </head>
 <body>
  <msg id="DisableInfo">The {0} has been disabled.</msg>
 </body>
</myDoc>

[Code source de l'exemple]

Remarque : L'exemple comprend la déclaration its:translate="no" dans la balise its:rules, pour empêcher la traduction des notes elles-mêmes par les traducteurs.

Le stockage des notes comme contenus d'éléments a des avantages sur le stockage des notes comme valeurs d'attributs its:locNote : on peut associer le balisage de notions telles que la langue et la directionnalité au texte du contenu d'un élément, ou à des parties du texte, si on dispose également d'un élément de type span, ce qu'on ne peut pas faire avec le texte des attributs.

Le stockage des notes dans un élément its:locNote peut donc offrir ces avantages à condition qu'il y ait un mécanisme pour associer les notes au contenu approprié. Au contraire, il est plus facile parfois de parcourir les documents si le texte de la note est stocké dans des éléments ou des attributs parallèlement au contenu auquel il se rapporte.

Bien que le langage ITS fournisse l'attribut its:locNote pour stocker le texte des notes, en offrant la possibilité d'une assoication étroite de la note au contenu approprié, il est difficile avec cette approche d'annoter les notes elles-mêmes à propos de la langue, de la directionnalité, etc.

On peut arguer du fait que les notes, s'agissant de métadonnées, ont des exigences différentes vis-à-vis du contenu même. Les développeurs de schémas devraient évaluer soigneusement l'approche à utiliser. Si toutes les notes doivent être écrites par des développeurs de contenus anglophones, on peut envisager d'utiliser des valeurs d'attributs, mais si elles doivent être écrites par des développeurs arabophones ou hébrophones, ceux-ci voudront très certainement utiliser du balisage directionnel et des éléments span dans les notes mêmes, et une approche fondée sur des éléments serait sans doute préférable.

Traitement du balisage hors de l'espace de noms ITS

Si vous travaillez avec un schéma existant dans lequel il existe une méthode pour fournir des notes aux traducteurs, non mise en œuvre en utilisant ITS, vous devriez fournir un document de règles ITS dans lequel vous utiliserez l'élément its:locNoteRule pour associer le balisage des notes à son équivalent dans ITS.

Exemple 12 : Document avec notes de localisation personnalisées.

Dans ce document, l'élément comment est une note pour son élément text frère (sibling).

<messages>
 <msg id="ERR_NOFILE">
  <text>The file '{0}' could not be found.</text>
  <comment>The variable {0} is the name of a file.</comment> 
 </msg>
</messages>

[Code source de l'exemple]

L'élément its:locNoteRule indique que les éléments text ont une description de localisation associée dans leurs éléments comment frères.

<its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
 <its:locNoteRule selector="//msg/text" locNoteType="description"
  locNotePointer="../comment"/>
</its:rules>

[Code source de l'exemple]

Pourquoi le faire

Pour aider le traducteur à réaliser une traduction correcte, les créateurs peuvent avoir besoin de fournir des informations à propos du texte qu'ils ont écrits. Par exemple, le créateur voudra peut être faire les choses suivantes :

  • Dire au traducteur comment traduire une partie du contenu (par exemple « Laisser le texte en majuscules ») ;

  • S'étendre sur la signification ou le contexte d'utilisation d'un élément particulier comme indiquer à quoi se rapporte une variable ou comment utiliser une chaîne dans l'interface d'utilisateur ;

  • Lever une ambiguïté et montrer suffisamment les relations entre les éléments pour permettre une traduction exacte (par exemple, dans beaucoup de langues, il est impossible de traduire isolément l'adjectif « activé » (enabled) sans connaître le genre, le nombre et le cas de la chose qualifiée) ;

  • Expliquer pourquoi il ne faut pas traduire le texte, pointer vers une réutilisation du texte, ou décrire l'utilisation d'un texte conditionnel ;

  • Indiquer pourquoi un bout de texte est mis en exergue (importance, sarcasme, etc.)

Fournir aux créateurs un moyen d'affecter des identificateurs uniques aux éléments localisables.

Comment le faire

Assurez-vous que les éléments à contenu traduisible puissent être associés à un identificateur unique.

Il est fortement recommandé de définir de tels identificateurs comme attributs de type ID, en suivant les règles décrites dans la spécification xml:id version 1.0 [xml:id]. Cela permet aux applications XML de tirer avantage des processus intégrés associés à ce type de données, telle la validation.

Il est également recommandé de nommer ces attributs xml:id pour accroître l'interopérabilité.

Remarque : L'utilité des identificateurs uniques est la plus grande lorsque leurs valeurs sont uniques globalement (c'est-à-dire uniques à travers les documents) et persistantes (c'est-à-dire qui ne changent pas dans le temps).

Pourquoi le faire

Pour optimiser la réutilisation du texte traduit là où le contenu est réutilisé (par exemple, à travers des mises à jour), il est nécessaire d'avoir un identificateur unique et persistant associé à l'élément.

Cet identificateur permet aux outils de traduction de suivre (track) correctement un élément d'une version à la suivante, ou d'un emplacement au suivant. Après s'être assuré qu'il s'agit du même élément, on peut rechercher les changements dans le contenu ; si aucun changement n'a eu lieu, le potentiel de réutilisation de la traduction précédente est très élevé.

L'analyse des changements de ce type constitue un outil de productivité extrêmement puissant pour la traduction, en comparaison des techniques habituelles d'appariement des sources (source matching), autrement dit les mémoires de traduction. Ces techniques recherchent simplement un texte source similaire dans une base de données multilingue sans pouvoir dire, la plupart du temps, si son contexte d'utilisation est le même.

Les identificateurs peuvent également être utiles pour remonter (track back) du texte affiché jusqu'à sa source sous-jacente. Par exemple, lorsque qu'on revoit une interface d'utilisateur traduite, on peut se servir des identificateurs comme préfixes temporaires au texte pour y corriger efficacement les chaînes appropriées.

Documentez dans un document de règles ITS quels éléments se rapportent à des termes et lesquels aux informations qui s'y rattachent.

La catégorie de données Terminologie ITS fournit l'élément its:termRule pour répondre à cette exigence.

Comment le faire

Fournir un document de règles ITS dans lequel on se sert d'éléments its:termRule pour indiquer quels éléments sont des termes et lesquels sont des informations qui s'y rattachent (par exemple, des définitions).

Remarque : L'information identifiée au travers de l'attribut its:termInfoRef peut être de n'importe quel type (à savoir, intelligible à un humain ou interprétable par une machine). La distinction appartient à l'application de traitement des données.

Exemple 13 : Document avec des éléments terminologiques.

Dans ce document, les éléments term et dt, ainsi que tout élément avec un attribut syn, dénotent des termes. Des informations peuvent en outre leur être associées.

<myDoc>
 <body>
  <p>A <term def="d001" syn="#alterego">doppelgänger</term>
  is basically <def xml:id="d001">the counterpart of a 
  person</def>. It is almost the same as an 
  <emph syn="#alterego">alter ego</emph>, but with a more sinister
  connotation. Sometimes the word <emph syn="#alterego">fetch</emph>
  is also used.</p>
 </body>
 <definitions>
  <entry xml:id="alterego">
   <dt>alter ego</dt>
   <dd>A second self. Figurative sense: trusted friend.</dd>
   <origin>Latin, literally: "second I"</origin>
  </entry>
 </definitions>
</myDoc>

[Code source de l'exemple]

L'ensemble des règles ITS suivantes signifient :

  • Premier termRule : l'élément term est un terme et l'information qui lui est associée est accessible au nœud dont l'identificateur correspond à la valeur de son attribut def ;

  • Deuxième termRule : tout élément avec un attribut syn est vu comme un terme ; l'attribut syn contient l'adresse URI d'un emplacement où trouver l'information associée ;

  • Troisième termRule : l'élément dt est un terme et l'information qui lui est associée se trouve dans son élément dd frère.

<its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
 <its:termRule selector="//term" term="yes" termInfoPointer="id(@def)"/>
 <its:termRule selector="//*[@syn]" term="yes" termInfoRefPointer="@syn"/>
 <its:termRule selector="//dt[../dd]" term="yes" termInfoPointer="../dd"/>
</its:rules>

[Code source de l'exemple]

Pourquoi le faire

La possibilité de définir des termes au sein du contenu source est importante pour la gestion terminologique et avantageuse pour la qualité de la traduction et de la localisation. Par exemple, l'identification des termes facilite la création de glossaires et permet la validation d'un usage terminologique dans le document source et le document traduit.

L'identification des termes est également utile pour la gestion des changements et pour assurer la qualité linguistique de la source.

Les termes peuvent nécessiter des informations associées variées, concernant la parole, le genre, le nombre, les types terminologiques, les définitions, les notes d'utilesation, etc. Pour éviter la répétition des informations associées à travers le document, il devrait être possible de lier les termes identifiés à des données descriptives (attribute data) externes, dans des glossaires (glossary documents) ou une base de données terminologique.

Ressources :

Documentation de base

Liens de références

Fournir aux créateurs un moyen de définir ou d'écraser l'information terminologique avec du balisage ITS, ou documentez le balisage existant équivalent dans un document de règles ITS.

La catégorie de données Terminologie ITS fournit les attributs its:term et its:termInfoRef, ainsi que l'élément its:termRule, pour répondre à cette exigence.

Comment le faire

Assurez-vous que les attributs its:term et its:termInfoRef soient définis pour tout élément contenant du texte.

Pour des exemples sur la façon d'ajouter des attributs à vos schémas existants, cf. la section 4.2 Exemple d'ajout d'un attribut à un schéma existant.

Il est également recommandé de définir dans son schéma l'élément its:rules, par exemple dans un en-tête s'il y en a un. L'élément its:rules fournit un accès à l'élément its:termRule lequel peut servir à écraser globalement l'information terminologique.

Pourquoi le faire

Parfois, le créateur d'un document peut avoir besoin de modifier l'information indiquant ce qu'est un terme ou comment pointer vers l'information terminologique, en écrasant les règles générales du schéma indiqué en application de la Pratique exemplaire 10 — Identifier les éléments terminologiques.

Ressources :

Documentation de base

Liens de références

Éviter les formats de document qui stockent plusieurs versions localisées dans le même document.

Cette pratique exemplaire concerne spécifiquement les situations où des copies du même contenu sont stockées en plusieurs langues dans un seul document. Sinon il est parfaitement acceptable d'avoir du texte multilingue dans un document.

Comment le faire

Pour les documents qui doivent passer à travers des tâches de localisation, stockez toujours la version localisée du texte dans un document séparé.

Exemple 14 : Éviter les documents multilingues.

Voici un exemple de mauvaise conception. Il montre un document seul contenant plusieurs traductions du même contenu :

<messages>
 <msg xml:id='fileNotFound'>
  <text xml:lang="en">File not found.</text>
  <text xml:lang="fr">Fichier non trouvé.</text>
 </msg>
</messages>

[Code source de l'exemple]

À la place, utilisez un seul document par langue. En voici un en anglais et l'autre en français. D'autres langues seraient accueillies dans des documents séparés similaires.

<messages xml:lang="en">
 <msg xml:id='fileNotFound'>
  <text>File not found.</text>
 </msg>
</messages>

[Code source de l'exemple]

<messages xml:lang="fr">
 <msg xml:id='fileNotFound'>
  <text>Fichier non trouvé.</text>
 </msg>
</messages>

[Code source de l'exemple]

Remarque : Il est admissible de stocker les copies multilingues d'un contenu dans un seul document avant l'envoi du document à la localisation, ou après que les tâches de localisation ont été effectuées. Ainsi on pourrait construire un fichier de ressource final en assemblant les différentes entrées linguistiques.

Remarque : Il est admissible de fournir au traducteur (localizer) des documents multilingues dans des formats XML qui sont conçus spécifiquement pour la localisation et sont des standards de l'industrie, tels que le format XLIFF (XML Localisation Interchange File Format) [XLIFF 1.2].

Pourquoi le faire

Il y a deux raisons principales pour éviter l'envoi de documents à la localisation si les sources originales (source material) sont placées en parallèle avec les différentes traductions dans le même document :

  1. Il est difficile de gérer des traductions concomitantes dans toutes les langues. Chaque traduction sera très probablement effectuée par un traducteur différent, dans un lieu différent. Pour plus de facilité, le document devra être scindé en plusieurs parties et reconstruit ensuite. Cela accroît le temps de traitement, augmente les coûts et multiplie les risques d'erreurs ;

  2. Selon la position dans le cycle de vie du document, un tel document peut déjà contenir des traductions, les unes qui sont à jour et les autres qui sont périmées (car les sources originales peuvent avoir changé). Afin d'identifier les parties à localiser et celles à laisser, le document doit alors également contenir des informations personnalisées à propos de l'état de la localisation, lesquelles peuvent être reconnues ou non par les outils de localisation.

Employez un schéma de nommage utile et non dynamique pour vos éléments et attributs.

Comment le faire

Assurez-vous que les noms des éléments et attributs de votre schéma réflètent leurs fonctions plutôt qu'une façon possible d'interpréter leur contenu.

Exemple 15 : Utiliser des noms utiles.

Voici un exemple de mauvaise conception. L'élément b sert à plusieurs fins.

<doc>
 <p>To run the application, click the <b>Start</b> button.</p>
 <p><b>Make sure to enter your username</b>, and then
  press <b>OK</b>.</p>
</doc>

[Code source de l'exemple]

Définissez plutôt plusieurs éléments selon leurs fonctions plutôt que selon une interprétation présumée.

<doc>
 <p>To run the application, click the <ui>Start</ui> button.</p>
 <p><emph>Make sure to enter your username</emph>, and then
  press <ui>OK</ui>.</p>
</doc>

[Code source de l'exemple]

Si possible, évitez aussi les noms d'éléments qui ne suivent pas un schéma de nommage fixe (par exemple, les noms d'éléments qui servent aussi d'identificateurs).

Exemple 16 : Éviter les noms dynamiques.

Voici un exemple de mauvaise conception. Les noms des éléments servent aussi d'identificateurs de texte.

<strings>
 <str1>Input path:</str1>
 <str2>Help</str2>
 <str3>OK</str3>
 <str4>Cancel</str4>
</strings>

[Code source de l'exemple]

Utilisez plutôt des noms d'éléments qui suivent un schéma de nommage fixe et utilisez xml:id pour les identificateurs.

<strings>
 <str xml:id="str1">Input path:</str>
 <str xml:id="str2">Help</str>
 <str xml:id="str3">OK</str>
 <str xml:id="str4">Cancel</str>
</strings>

[Code source de l'exemple]

Pourquoi le faire

Le nom d'un élément devrait indiquer quelle est sa fonction, non comment son contenu sera présenté, parce que la présentation peut varier en fonction de différents facteurs tels que la langue, l'écriture, le médium ou l'accessibilité.

Utiliser des documents dans lesquels les éléments ou attributs ne suivent pas un modèle de nommage prévisible peut entraîner des problèmes lorsqu'on utilise des processus dirigés par XSLT. Cela peut aussi poser un problème aux outils de traduction. C'est particulièrement vrai si toutes les parties du document doivent être traduites, puisqu'il serait difficile de définir des règles pour distinguer les nœuds traduisibles de ceux qui ne le sont pas.

Fournissez aux créateurs un moyen d'annoter un contenu arbitraire en utilisant its:span ou un balisage équivalent.

Un élément de type span (span-like element) est un élément pouvant être utilisé pour marquer un contenu arbitraire et l'associer à diverses propriétés telles que la directionnalité ou l'information de langue. Les exemples d'un tel élément comprennent l'élément span dans XHTML ou l'élément phrase dans DocBook.

Comment le faire

Assurez-vous de définir un élément de type span dans votre schéma qui permette aux créateurs d'associer un contenu arbitraire à des propriétés telles que la directionnalité, l'information de langue, etc.

Si votre schéma ne fournit pas déjà un tel élément, vous pourriez utiliser l'élément its:span.

La définition de l'élément its:span dans la spécification ITS liste le jeu d'attributs ITS que devrait admettre un élément de type span.

Pourquoi le faire

Certaines propriétés du contenu s'appliquent à l'aide d'attributs. La directionnalité, la terminologie, les notes de localisation, l'information de traduction et l'identification de la langue sont des exemples de telles propriétés. Il est besoin d'un élément neutre pour délimiter la longueur de texte à laquelle appliquer ces attributs, puisque les frontières appropriées ne sont parfois pas délimitées par un autre balisage présent ou ces attributs ne sont peut-être pas permis sur l'autre balisage présent.

Ressources :

Liens de références

Fournissez un document de règles ITS contenant toutes les règles ITS nécessaires pour interpréter le balisage existant et identifiez les informations de traduction, de terminologie et de segmentation du texte dans votre format.

Comment le faire

Assurez-vous de documenter les aspects d'internationalisation et de localisation de votre schéma en fournissant un ensemble de règles ITS pertinentes dans un seul document de règles ITS autonome.

Votre document de règles ITS devrait inclure les renseignements suivants, à appliquer selon le cas :

On trouvera quelques exemples de documents de règles ITS pour des formats XML existants à la section ITS appliqué aux formats existants.

Pourquoi le faire

Quoique certains vocabulaires XML soient faciles à comprendre ou traiter, il est souvent utile ou nécessaire de fournir des informations explicites à propos d'un vocabulaire donné. Si on doit utiliser un tel vocabulaire dans un contexte multilingue, les informations fournies sont primordiales, par exemple quels éléments ont un contenu traduisible, car l'information générale concernant la raison, la structure générale et les types des nœuds est très souvent insuffisante. En un sens, ce besoin d'information explicite s'apparente à la pratique exemplaire générale consistant à documenter le code source.

En XML, on utilisera naturellement un format bien défini et structuré pour saisir ces informations. Quant aux informations concernant l'internationalisation et la traduction, les documents de règles ITS constituent un bon choix pour les raisons suivantes :

  • Ils sont prévus pour tenir compte de plusieurs aspects importants de l'internationalisation et la traduction ;

  • Ils saisissent précisément les informations (par exemple, les sélecteurs identifient à quels nœuds se rapporte une catégorie de données) ;

  • Ils sont interprétables par les applications compatibles avec ITS ;

  • Ils se combinent facilement à une information structurée supplémentaire (par exemple, liée au contrôle de version, comme illustré dans l'exemple ci-dessous).

    Exemple 17 : Règles ITS incorporées dans un fichier d'information personnalisé.

    Un processeur ITS devrait toujours pouvoir traiter un fichier tel qu'un fichier de règles ITS externe si le format du fichier contient vos propres informations personnalisées, en plus des règles ITS. En voici un exemple :

    <myFormatInfo xmlns:its="http://www.w3.org/2005/11/its">
     <desc>ITS rules used by the Open University</desc>
     <hostVoc>http://www.example.com/ns/myFormat</hostVoc>
     <rulesId>98ECED99DF63D511B1250008C784EFB1</rulesId>
     <rulesVersion>v 1.81 2006/03/28 07:43:21</rulesVersion>
     <its:rules version="1.0">
      <its:translateRule selector="//header" translate="no"/>
      <its:translateRule selector="//term" translate="no"/>
      <its:termRule selector="//term" term="yes"/>
      <its:withinTextRule withinText="yes" selector="//term|//b"/>
     </its:rules>
    </myFormatInfo>
    
    

    [Code source de l'exemple]

Ressources :

Liens de références

Vers la table des matières. 3 Lors de la création d'un contenu XML

Les créateurs de contenus XML devraient appliquer les pratiques exemplaires suivantes :

Pratique exemplaireRésumé
Indiquer la langue du contenu Utilisez l'attribut xml:lang (ou l'équivalent dans votre schéma) sur l'élément racine du document et sur chaque élément où la langue du contenu change.
Indiquer la directionnalité du texte Par défaut, la directionnalité du texte dans un document XML est présumée de gauche à droite. Utilisez l'attribut its:dir (ou l'équivalent dans votre schéma) sur l'élément racine d'un document où le sens prédominant du texte est de droite à gauche, et sur les éléments où l'algorithme bidirectionnel Unicode a besoin d'assistance pour obtenir l'affichage correct d'un texte bidirectionnel.
Écraser l'information de traductibilité Utilisez l'attribut its:translate (ou l'équivalent dans votre schéma) sur chaque élément dont la propriété de traductibilité est différente du comportement par défaut fixé par votre schéma.
Affecter des identificateurs uniques Utilisez des identificateurs uniques à la façon indiquée par votre schéma sur chaque élément constituant une frontière de segmentation. Si possible, utilisez des valeurs uniques globalement et persistantes comme valeurs des identificateurs.
Éviter les sections de type CDATA Ne mettez pas de contenus qui seront traduits en sections CDATA.
Fournir des notes aux traducteurs Utilisez les attributs its:locNote, its:locNoteType et its:locNoteRef (ou leurs équivalents dans votre schéma) pour fournir des notes au traducteur.
Travailler avec du texte inséré Utilisez du texte inséré seulement lorsque le texte est autonome (self-contained) et n'affecte pas le contenu environnant (surrounding context). Par exemple, les titres et les citations sont du texte inséré qui ne pose normalement pas de problèmes. Évitez d'utiliser du texte inséré qui dépend du contexte où il s'insère.
Identifier les termes Utilisez les attributs its:term et its:termInfoRef (ou leurs équivalents dans votre schéma) pour marquer les termes et fournir une information terminologique.
Stocker le balisage d'un autre format Si possible, utilisez le mécanisme d'espace de noms XML pour stocker des vocabulaires différents dans un seul document XML.

Nombre de ces pratiques ne peuvent être observées que lorsque l'application XML a été correctement internationalisée selon les conseils de conception de la section 2 À la conception d'une application XML.

Indiquez la langue de votre contenu en utilisant l'attribut xml:lang, ou un mécanisme équivalent de votre format de document.

Votre schéma devrait fournir l'attribut xml:lang (ou un mécanisme équivalent) pour définir la langue du contenu. Cf. la Pratique exemplaire 1 — Définir un balisage pour indiquer la langue pour plus de renseignements.

Comment le faire

Utilisez l'attribut xml:lang (ou l'équivalent dans votre schéma) sur l'élément racine du document et sur chaque élément où la langue du contenu change. Les éléments sans ces déclarations héritent de l'information de langue de leurs parents. Les valeurs d'attributs sont présumées dans la même langue que l'élément où ils sont déclarés.

Assurez-vous que les valeurs de l'attribut xml:lang soient conformes aux Étiquettes d'identification des langues [BCP 47]. Pour une brève introduction à la formation des valeurs de langue selon le BCP 47, cf. l'article Étiquettes de langue en HTML et XML.

Exemple 18 : Déclarer l'information de langue avec xml:lang

Dans cette exemple, le contenu principal du document est en anglais, et une courte citation dans l'élément q est identifiée comme étant en français avec une valeur xml:lang de "fr".

<document xml:lang="en">
 <para>The motto of Québec is the short phrase:
  <q xml:lang="fr">Je me souviens</q>. It is chiseled on 
  the front of the Parliament Building.</para>
</document>

[Code source de l'exemple]

Si le schéma utilisé ne fournit pas d'attribut xml:lang, utilisez un attribut équivalent.

Exemple 19 : Déclarer l'information de langue avec un mécanisme non standard.

Dans cet exemple, le schéma de ce type de document utilise une méthode non normalisée pour définir la langue : un attribut code. Les créateurs devraient utiliser ce mécanisme et non xml:lang, parce que le développeur du type de document stringList devrait fournir, en même temps que le schéma, un document de règles ITS (visible ci-dessous) déclarant code équivalent à xml:lang lorsqu'on l'utilise avec l'élément lang.

<stringList>
 <msg id="connected">
  <lang code="cs">Jste připojeni k Internetu.</lang>
  <lang code="de">Sie sind an das Netz angeschlossen.</lang>
  <lang code="fr">Vouz êtes connecté à la Toile.</lang>
  <lang code="it">Sei connesso al Web.</lang>
  <lang code="ja">インターネットに接続しました。</lang>
  <lang code="ko">웹에 연결되었습니다.</lang>
  <lang code="ru">Вы подключены к Интернету.</lang>
 </msg>
</stringList>

[Code source de l'exemple]

Remarque : Cet exemple est un document multilingue, avec son propre cortège de problèmes, comme décrit dans la Pratique exemplaire 12 — Travailler avec des documents multilingues.

Le développeur du type de document stringList devrait fournir un document de règles ITS conformément à la Pratique exemplaire 1 — Définir un balisage pour indiquer la langue pour les schémas existants. Ici l'élément its:langRule définit l'attribut code de l'élément lang en équivalence de xml:lang.

<its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
 <its:langRule selector="//lang[@code]" langPointer="@code" />
</its:rules>

[Code source de l'exemple]

Remarque : Un changement de langue a parfois des implications pour la traduction. Ainsi, un contenu dans une langue différente qui ne doit pas être traduit ou qui nécessite une manipulation spécifique. De telles informations devraient être fournies au traducteur par les attributs its:translate ou its:locNote (ou leurs équivalents dans votre schéma). Pour des précisions, cf. la Pratique exemplaire 18 — Écraser l'information de traductibilité et la Pratique exemplaire 21 — Fournir des notes aux traducteurs.

Pourquoi le faire

Connaître la langue du contenu est très important dans beaucoup de situations. Elles comprennent :

  • la sélection d'une fonte correcte (par exemple, pour du chinois traditionnel ou du chinois simplifié) ;

  • le traitement du texte pour la mise en page (wrapping) et la césure (hyphenation) ;

  • la correction orthographique ou la vérification grammaticale du texte ;

  • la détermination des sélections automatisées correctes du texte telles que les guillemets ou d'autres signes de ponctuation ;

  • l'utilisation du texte avec des navigateurs vocaux (voice browsers).

Ressources :

Documentation de base

Liens de références

Données de test

Utilisez un balisage dédié pour indiquer la directionnalité de votre contenu textuel.

Votre schéma devrait fournir l'attribut its:dir (ou un mécanisme équivalent) pour organiser la directionnalité. Cf. la Pratique exemplaire 2 — Définir un balisage pour indiquer la direction du texte.

Comment le faire

Par défaut, la directionnalité d'un document XML est présumée de gauche à droite. Utilisez l'attribut its:dir (ou l'équivalent dans votre schéma) sur l'élément racine d'un document dont le sens prédominant du texte est de droite à gauche, et sur les éléments où l'algorithme bidirectionnel Unicode a besoin d'une assistance pour obtenir un affichage correct du texte bidirectionnel.

Vous pouvez obtenir d'autres conseils pour quand et comment utiliser un balisage directionnel dans Pratiques exemplaires d'internationalisation — Traitement des écritures de droite à gauche dans les contenus HTML et XHTML et Ce qu'il faut savoir à propos de l'algorithme bidi et le balisage dans le texte. Quoique la première référence s'adresse aux créateurs (X)HTML, l'avis est généralement pertinent aussi pour les créateurs de la plupart des documents fondés sur XML.

Exemple 20 : Déclarer la directionnalité du texte.

Dans cet exemple, l'attribut its:dir est utilisé pour définir la directionnalité d'une longueur de texte de droite à gauche dans un document de gauche à droite par défaut.


<text
  xmlns:its="http://www.w3.org/2005/11/its"  xml:lang="en"
  its:version="1.0">
 <body>
  <par>In Hebrew, the title
     <quote xml:lang="he"
     its:dir="rtl">פעילות הבינאום, W3C</quote>
     means <quote>Internationalization Activity, W3C</quote>.</par>
 </body>
</text>

[Code source de l'exemple]

Sans le balisage, le titre en hébreu s'afficherait incorrectement. Le mot « W3C » et la virgule seraient à droite du texte cité en hébreu, au lieu d'être à gauche de celui-ci. Le balisage fournit l'information contextuelle instruisant l'agent utilisateur que la virgule et le mot « W3C » font partie du flux droite à gauche du texte.

Remarque : Cet exemple montre correctement la directionnalité du texte source, pour bien comprendre les concepts décrits. Pour un tel affichage, il faut un éditeur sophistiqué qui résolve correctement la directionnalité du texte source. Beaucoup d'éditeurs n'ont pas ce degré de sophistication. Cf. l'explication liée à propos des Problèmes avec le texte source bidirectionnel dans [Bidi in X/HTML].

Remarque : Dans les documents XML, il est plus approprié d'utiliser du balisage que d'utiliser que les commandes d'incorporation bidi Unicode. Cf. l'article Codes de formatage bidi contre balisage pour la gestion bidi pour une explication approfondie.

Il est nécessaire également d'utiliser un balisage dédié pour appliquer une information directionnelle plutôt que d'appliquer simplement des propriétés de direction CSS aux éléments ordinaires. Cf. la question CSS contre balisage pour la gestion bidi pour d'autres renseignements.

Pourquoi le faire

Les agents utilisateurs devraient utiliser l'algorithme bidirectionnel Unicode (ou bidi) et sa connaissance des propriétés directionnelles des caractères pour décider si une séquence de caractères devrait s'écouler vers la gauche ou vers la droite. L'algorithme bidi peut aussi se charger de cas simples où le texte de droite à gauche et le texte de gauche à droite se mélangent. Par contre, il y a souvent des situations où une information contextuelle est nécessaire au niveau supérieur pour obtenir la disposition (layout) voulue du texte bidirectionnel. Cette information contextuelle peut être fournie par le balisage en XML. Un tel balisage affecte également la mise en pages. Ainsi, dans un contexte de droite à gauche, les colonnes de table se rangent de droite à gauche, les puces des liste apparaissent à droite du texte, la page est alignée à droite, et ainsi de suite.

Remarque : L'information de directionnalité ne peut pas se déduire du balisage de langue :

  • Il n'y a pas forcément de relation un-à-un entre une langue donnée et la directionnalité à utiliser. Par exemple, l'azéri peut s'écrire de droite à gauche et de gauche à droite, et le code de langue az est pertinent pour les deux ;

  • Les valeurs du balisage directionnel dans le texte (inline) ne sont pas nécessairement alignées sur les valeurs du balisage à propos de la langue. Par exemple, on pourrait déclarer une partie du document comme ayant une directionnalité de droite à gauche alors qu'on ne disposerait que d'une déclaration de langue générale pour une langue à écriture de gauche à droite, telle que le français (fr) ;

  • Le balisage utilisé pour donner la directionnalité a des valeurs indiquant d'écraser la directionnalité normale ; il n'est pas possible de l'indiquer à l'aide de valeurs liées à la langue.

Ressources :

Documentation de base

Liens de références

Utilisez le balisage disponible pour définir un contenu dont l'option de traduction ou non diffère du comportement par défaut de votre schéma.

Votre schéma devrait fournir l'attribut its:translate (ou un mécanisme équivalent) afin d'écraser le comportement par défaut. Cf. la Pratique exemplaire 5 — Définir un balisage pour écraser l'information de traduction.

Le comportement par défaut ITS est que l'on traduise le contenu des éléments et non celui des attributs. Les développeurs de votre schéma devraient également avoir documenté toutes les définitions par défaut spécifiques du schéma de votre type de document lorsqu'elles diffèrent des définitions par défaut ITS.

Comment le faire

Utilisez l'attribut its:translate (ou l'équivalent dans votre schéma) sur chaque élément dont la propriété de traductibilité diffère des définitions par défaut fixées pour votre schéma.

Exemple 21 : Écraser les règles de traduction par défaut.

Dans le document suivant, bien que l'on doive normalement traduire le contenu des éléments par, il faudrait ici que le dernier par reste en anglais. Avec l'attribut its:translate, le créateur peut indiquer de ne pas traduire ce dernier par.

Notez que le créateur n'a pas besoin d'indiquer de ne pas traduire l'élément head parce que cela est défini pour tous les documents de type myDoc par le document de règles ITS fourni par le développeur du schéma myDoc (voir ci-dessous).

<myDoc xmlns:its="http://www.w3.org/2005/11/its" its:version="1.0">
<head>
  <lastRev>2007-10-23 041254Z</lastRev>
  <docID>1A454AE4-7EB8-4ed2-A58E-1EC7F75BB0D5</docID>
 </head>
 <par>To apply these terms to you library, attach the following notice.
  It is safest to attach it to the start of each source file to most 
  effectively convey the exclusion of warranty; and each file should 
  have at least the "copyright" line and a pointer to where the full 
  notice is found.</par>
  <par>The notice should read (preferably in English):</par>
  <par its:translate="no">This library is free software; you can 
  redistribute it and/or modify it under the terms of the GNU Lesser 
  General Public License as published by the Free Software Foundation; 
  either version 2.1 of the License, or (at your option) any later 
  version. This software is distributed as open source under LGPL.</par>
 </myDoc>

[Code source de l'exemple]

Voici le document de règles ITS créé par le développeur du type de document myDoc (en mettant en œuvre la Pratique exemplaire 4 — Indiquer quels éléments et attributs traduire). Ces règles écrasent le comportement ITS par défaut selon lequel on traduit tous les contenus d'éléments mais pas les valeurs d'attributs.

<its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
 <its:translateRule selector="/myDoc/head" translate="no"/>
 <its:translateRule selector="//img/@alt" translate="yes"/>
</its:rules>

[Code source de l'exemple]

Voici la signification des règles :

  • Premier translateRule : l'élément head et ses sous-éléments ne devraient pas être traduits ;

  • Deuxième translateRule : l'attribut alt des éléments img devrait être traduit.

Pour écraser l'information de traduction des attributs, vous devez utiliser un élément its:translateRule dans votre document.

Exemple 22 : Écraser les règles de traduction par défaut des attributs.

Ce document du même type que celui de l'exemple 21 utilise les mêmes règles ITS et on devrait donc normalement traduire l'attribut alt. Puisque dans ce document particulier les images se rapportent à une interface d'utilisateur qui ne sera pas traduite (alors que le document le sera), le créateur doit écraser la règle selon laquelle tous les attributs alt doivent être traduits. Il le fait au début du document avec l'élément its:translateRule.

<myDoc xmlns:its="http://www.w3.org/2005/11/its" its:version="1.0">
 <head>
  <lastRev>2007-11-12 234503Z</lastRev>
  <docID>D1EA7453-DC53-488a-B950-137BE0EF5253</docID>
  <its:rules>
   <its:translateRule selector="//img[@role='ui']/@alt" translate="no"/>
  </its:rules>
 </head>
 <par>Once you have selected your options, click the 
  <img xml:lang="en-us" src="runBtn.png" role="ui" alt="Run"/> button
  to start the process.</par>
</myDoc>

[Code source de l'exemple]

L'élément its:translateRule dit que le texte de remplacement des images qui se rapportent aux boutons de l'interface d'utilisateur (ui) dans ce document devrait rester non traduit.

Remarque : Les créateurs NE DEVRAIENT PAS utiliser l'attribut its:translate pour baliser (tag) des mots ou termes simples qui seront probablement pareils (à leur avis) pour une traduction dans une langue donnée, par exemple des mots d'emprunt (loan-words) à une langue. Ce type de décision intervient normalement pendant la traduction.

Les créateurs peuvent décider de ce qui est traduisible mais pas comment le traduire.

Exemple 23 : Document XML avec utilisation inappropriée de its:translate.

Voici un exemple de mauvaise conception. Dans ce document, on utilise l'attribut its:translate pour marquer un nom propre et deux mots d'emprunt pour indiquer de ne pas les traduire. On NE DEVRAIT PAS le faire.

<book xmlns:its="http://www.w3.org/2005/11/its" its:version="1.0">
 <body>
  <p>Everything started when <span its:translate="no">Zebulon</span> 
  discovered that he had a <span its:translate="no">doppelgänger</span> 
  who was a serious baseball <span its:translate="no">aficionado</span>.</p>
 </body>
</book>

[Code source de l'exemple]

En revanche, pour aider le traducteur, il peut être utile de marquer les mots d'emprunt ou les mots spéciaux dans cet exemple comme étant des termes, tel que décrit à la section Pratique exemplaire 23 — Identifier les termes.

Pourquoi le faire

Même si l'ensemble de règles ITS fourni avec le schéma est censé indiquer les exceptions aux règles de traduction ITS par défaut d'un schéma donné (cf. la Pratique exemplaire 4 — Indiquer quels éléments et attributs traduire), il y a des situations où ces règles générales doivent être écrasées pour des éléments spécifiques, dans des documents spécifiques. C'est au créateur du contenu d'indiquer ces cas à l'aide du balisage.

Affectez un identificateur unique aux éléments qui correspondent aux frontières de segmentation.

Votre schéma devrait fournir l'attribut xml:id (ou un mécanisme équivalent) afin d'affecter des identificateurs uniques aux éléments. Cf. la Pratique exemplaire 9 — Définir un balisage pour les identificateurs uniques.

La segmentation désigne la façon dont le texte est scindé, d'un point de vue linguistique, en unités stockables séparément et manipulables par des processus tels que la traduction. Le créateur du schéma devrait créer une liste de ces éléments là où ils se différencient des définitions ITS par défaut (cf. la Pratique exemplaire 6 — Fournir des informations pour la segmentation du texte).

Comment le faire

Utilisez des identificateurs uniques à la façon indiquée par votre schéma sur chaque élément constituant une frontière de segmentation.

Remarque : Les identificateurs sont souvent affectés automatiquement par les applications de création ou de gestion de contenu. Les créateurs n'ont ainsi pas à s'en soucier dans certains cas.

Si possible, utilisez des valeurs uniques globalement et persistantes comme valeurs des identificateurs.

Pourquoi le faire

Fournir des identificateurs uniques peut être très utile pour l'analyse des changements, le suivi du texte et diverses autres tâches souvent effectuées pendant la création et la localisation des documents.

Ceci est expliqué en détails dans la Pratique exemplaire 9 — Définir un balisage pour les identificateurs uniques.

Ressources :

Documentation de base

Liens de références

Évitez l'utilisation de sections de type CDATA pour le contenu qui sera traduit.

Les sections de type CDATA sont couramment utilisées pour placer du code de programmation ou d'autres vocabulaires spéciaux dans du XML avec le minimum d'effort. Il existe souvent de meilleures méthodes d'inclure de tels contenus.

Comment le faire

Ne placez pas de contenu qui sera traduit dans les sections de type CDATA.

Exemple 24 : Éviter l'utilisation de sections de type CDATA.

Voici un exemple de mauvaise conception. Dans ce document, une partie du contenu est dans une section de type CDATA. Il n'est plus possible de baliser ce contenu pour des changements de langue, de termes, de direction de texte, d'information de traduction ou de toutes les autres choses qui seraient peut-être nécessaires pour faciliter la localisation.

<myData>
 <item course="12" page="2">
  <title>Accessing the R&amp;D facilities</title>
  <body><![CDATA[The R&D facilities are located in the South wing
   of Building 12-W, in the East quarter of the section Q.
   IMPORTANT ==> These facilities are accessible only to personal with
   Class Omega-45Q1 clearance.]]></body>
 </item>
</myData>

[Code source de l'exemple]

Utilisez plutôt du XML normal pour votre contenu. Cela vous permet de baliser le contenu au besoin. Par exemple ici, le créateur a ajouté du balisage terminologique.

<myData xmlns:its="http://www.w3.org/2005/11/its" its:version="1.0">
 <item course="12" page="2">
  <title>Accessing the R&amp;D facilities</title>
  <body>The R&amp;D facilities are located in the South wing
   of Building 12-W, in the East quarter of the section Q.
   IMPORTANT ==&gt; These facilities are accessible only to personal with
   <span its:term="yes">Class Omega-45-Q1</span> clearance.</body>
 </item>
</myData>

[Code source de l'exemple]

Si la section de type CDATA englobe un grand bloc de données autonome tel qu'un script ou un exemple XML, vous pourrez remplacer la section en utilisant un mécanisme d'inclusion comme XInclude ou XLink.

Exemple 25 : Remplacer des sections de type CDATA avec XLink.

En SVG, on peut placer un script directement dans un document SVG ; auquel cas on utilise habituellement des sections de type CDATA pour ne pas devoir échapper (escape) des caractères dans le code du script.

<?xml version="1.0" encoding="utf-8"?>
<svg width="6cm" height="5cm" viewBox="0 0 600 500"
     xmlns="http://www.w3.org/2000/svg" version="1.1">
  <!-- Script is inlined and enclosed in CDATA section  -->
  <script type="text/ecmascript"> <![CDATA[
    function circle_click(evt) {
      var circle = evt.target;
      var currentRadius = circle.getAttribute("r");
      if (currentRadius < 100)
        circle.setAttribute("r", currentRadius*2);
      else
        circle.setAttribute("r", currentRadius*0.5);
    }
  ]]> </script>
  <rect x="1" y="1" width="598" height="498" fill="none" stroke="blue"/>
  <circle onclick="circle_click(evt)" cx="300" cy="225" r="10"
          fill="red"/>
  <text x="300" y="480" 
        font-family="Verdana" font-size="35" text-anchor="middle">
    Click on circle to change its size
  </text>
</svg>

[Code source de l'exemple]

Vous pourriez utiliser XLink à la place pour stocker le script dans un fichier séparé et l'appeler depuis le document SVG.

<?xml version="1.0" encoding="utf-8"?>
<svg width="6cm" height="5cm" viewBox="0 0 600 500"
     xmlns="http://www.w3.org/2000/svg" version="1.1"
     xmlns:xlink="http://www.w3.org/1999/xlink">
  <!-- Script is included from external file  -->
  <script type="text/ecmascript" xlink:href="animate.js"/>
  <rect x="1" y="1" width="598" height="498" fill="none" stroke="blue"/>
  <circle onclick="circle_click(evt)" cx="300" cy="225" r="10"
          fill="red"/>
  <text x="300" y="480" 
        font-family="Verdana" font-size="35" text-anchor="middle">
    Click on circle to change its size
  </text>
</svg>

[Code source de l'exemple]

Exemple 26 : Remplacer des sections de type CDATA avec XInclude.

On utilise couramment des sections de type CDATA pour placer des exemples de code source dans les documents XML. L'exemple suivant montre comment le faire en utilisant DocBook.

<?xml version="1.0" encoding="utf-8"?>
<example xmlns="http://docbook.org/ns/docbook">
  <title>Skeleton of XHTML page</title>
  <programlisting><![CDATA[<html xmlns="http://www.w3.org/1999/xhtml"
   xml:lang="en">
  <head>
    <title>… page title goes here …</title>
  </head>
  <body>
    … page content goes here …
  </body>
</html>]]></programlisting>
</example>

[Code source de l'exemple]

Vous pourriez utiliser XInclude à la place pour stocker le code d'exemple dans un fichier séparé et l'inclure au moment du traitement. Notez que vous devrez utiliser parse="text" pour traiter le fichier inclus comme étant du texte ordinaire (plain text) plutôt que comme du balisage.

<?xml version="1.0" encoding="utf-8"?>
<example xmlns="http://docbook.org/ns/docbook"
    xmlns:xi="http://www.w3.org/2001/XInclude">
  <title>Skeleton of XHTML page</title>
  <programlisting><xi:include href="EX-xhtml-skeleton.xhtml" 
               parse="text"
               encoding="utf-8"/></programlisting>
</example>

[Code source de l'exemple]

Si vous devez utiliser des sections de type CDATA :

  • Documentez le type du contenu (par exemple avec un attribut affecté du type MIME adéquat). Cela peut aider les outils à choisir un analyseur (parser) approprié pour traiter le contenu ;

  • Cherchez à produire du contenu bien formé. Cela permettra aux analyseurs de traiter le contenu plus aisément.

Remarque : Les sections de type CDATA sont souvent utilisées pour stocker du texte contenant des balises HTML ou XML. Ce n'est pas recommandé. Cf. la Pratique exemplaire 24 — Stocker le balisage d'un autre format pour des précisions.

Remarque : Utiliser des sections de type CDATA n'affecte pas la préservation ou non des caractères blancs (whitespace) par les processeurs XML. Pour préserver les caractères blancs, utilisez l'attribut xml:space avec la valeur preserve.

Pourquoi le faire

L'utilisation de sections de type CDATA empêche l'insertion du balisage en vue de l'internationalisation ou la localisation. Ainsi, les balises pour indiquer un changement de directionnalité, ou de langue, ou pour ajouter des notes de localisation, ne peuvent pas être utilisées pour le texte contenu dans les sections de type CDATA.

Les références de caractères numériques et les références d'entités ne sont pas gérées non plus dans les sections de type CDATA. Cela peut conduire éventuellement à une perte de données lors de la conversion du document d'un codage à un autre, ou lors de la traduction.

Mélanger le contenu dans les sections de type CDATA et le contenu en dehors dans le même document demande beaucoup de travail lors de la réalisation de tâches avec des outils ignorants le XML. Par exemple, pour rechercher la chaîne "R&D", l'utilisateur doit chercher à la fois R&D (dans les sections de type CDATA) et R&amp;D (dans le contenu normal).

Utilisez du balisage dédié pour fournir des notes dans lesquelles vous communiquerez des renseignements utiles au traducteur.

Votre schéma devrait fournir les attributs its:locNote, its:locNoteType et its:locNoteRef (ou des mécanismes équivalents) afin de communiquer avec ceux qui traduiront votre contenu. Cf. la Pratique exemplaire 8 — Définir un balisage pour les notes aux traducteurs.

Comment le faire

Utilisez les attributs its:locNote, its:locNoteType et its:locNoteRef (ou leurs équivalents dans votre schéma) pour fournir des notes au traducteur.

C'est particulièrement important pour un contenu avec du texte inséré où le traducteur aura besoin de connaître le contexte pour une traduction précise.

Exemple 27 : Annoter un document XML pour une localisation.

Dans ce document, on utilise deux attributs ITS locaux pour annoter un modèle XSLT :

  • l'attribut its:locNoteRef sert à pointer vers une explication de l'abréviation « RFID » ;

  • l'attribut its:locNote sert à indiquer à quel type de valeur correspond l'élément <xsl:value-of select="PNum"/>.

Remarque : Lorsqu'on travaille avec XSLT, on devra décider si le balisage ITS est dans la sortie ou non, et utiliser peut-être un balisage différent en conséquence. Dans cet exemple, les attributs ITS n'apparaissent pas dans la sortie.

<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
     xmlns="http://www.w3.org/1999/xhtml"
     xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
     xmlns:its="http://www.w3.org/2005/11/its"
     its:version="1.0">
 <xsl:template match="/data">
  <xsl:variable name="Lang" select="Lang"/>
  <xsl:variable name="EMail" select="EMail"/>
  <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="{$Lang}" lang="{$Lang}">
   <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
    <title>Login</title>
   </head>
   <body>
    <p>Login Into Queztal-Systems</p>
    <form method="POST">
     <table border="0" id="table2">
      <tr><td>First, place your pass card in front of the reader to scan your
       <xsl:text its:locNoteRef="http://en.wikipedia.org/wiki/RFID">RFID</xsl:text>.
       When the light turns green, enter your password in the box below, and
       click Submit.</td></tr>
      <tr><td><input type="password" name="pword" size="25"/></td></tr>
     </table>
     <p><input type="submit" value="Submit" name="go"/></p>
    </form>
    <p>If you have difficulties login in, please call
     <xsl:value-of select="PNum" its:locNote="Toll-free phone number"/>,
     or send an email to
     <a href="mailto:{$EMail}"><xsl:value-of select="EMail"/></a>.</p>
   </body>
  </html>
 </xsl:template>
</xsl:stylesheet>

[Code source de l'exemple]

Pourquoi le faire

Il y a de nombreuses raisons d'apporter des informations aux traducteurs (localizers). On peut vouloir :

  • S'étendre sur la signification ou le contexte d'utilisation d'un élément particulier comme, à quoi se rapporte une variable ou quelle sera l'utilisation d'une chaîne dans l'interface d'utilisateur ;

  • Lever une ambiguïté et montrer suffisamment les relations entre les éléments pour réaliser une traduction exacte. Par exemple, dans beaucoup de langues, il est impossible de traduire isolément l'adjectif « activé » (enabled) sans connaître le genre, le nombre et le cas de la chose qualifiée ;

  • Expliquer pourquoi il ne faut pas traduire le texte, pointer vers une réutilisation de texte ou décrire l'utilisation d'un texte conditionnel ;

  • Indiquer pourquoi un bout de texte est mis en exergue (importance, sarcasme, etc.)

Utiliser des commentaires XML à cet effet ne suffira peut-être pas car ils pourraient être supprimés ou ignorés pendant le processus de localisation.

Assurez-vous que chaque morceau de texte inséré soit grammaticalement indépendant du contenu environnant.

Le texte inséré désigne un texte qui est marqué comme un paramètre fictif (placeholder) dans le document XML source et inséré automatiquement dans le texte au traitement du document.

Les types de texte inséré comprennent :

  • Le texte passe-partout (boilerplate text) réutilisé dans des contextes différents ;

  • Les diverses parties d'une phrase composée en assemblant les morceaux de texte séparés ;

  • Les paramètres fictifs variables remplacés par leurs valeurs au traitement du document.

La mise en œuvre de ce texte peut être réalisée de plusieurs façons en XML. Voici quelques exemples d'utilisation :

  • Dans le cadre de références d'entités ;

  • Dans le cadre d'un traitement XSLT ;

  • Dans le cadre de mécanismes XInclude ;

  • Dans le cadre de mécanismes XLink ;

  • Dans le cadre d'un mécanisme personnalisé spécifique d'un format donné (par exemple l'attribut conref dans [DITA 1.0]).

Comment le faire

Utilisez du texte inséré seulement lorsque le texte est autonome et n'affecte pas le contenu environnant. Par exemple, les titres et les citations sont du texte inséré qui ne pose généralement pas de problèmes.

Évitez d'utiliser du texte inséré qui a un effet sur ou qui dépend du contexte où il s'insère.

Pour une documentation de base à propos des problèmes et des approches en rapport à l'insertion et la réutilisation de texte, cf. les articles Travailler avec des messages composites et Réutilisation des chaînes dans les contenus de scripts.

Si vous insérez du texte, utilisez les attributs its:locNote ou its:termInfoRef (ou leurs équivalents dans votre schéma) pour informer les traducteurs du contexte. Cf. la Pratique exemplaire 21 — Fournir des notes aux traducteurs et la Pratique exemplaire 23 — Identifier les termes.

Exemple 28 : Fournir le contexte des variables.

Dans cet exemple, dans le premier message, on utilise l'élément var pour insérer le nom d'une imprimante. Dans le deuxième exemple, on l'utilise pour insérer un nom de fichier. L'attribut its:locNote sert à fournir une description de ce que les variables représentent. Cela peut aider à décider comment traduire chaque message.

<strings xmlns:its="http://www.w3.org/2005/11/its"
 xml:lang="en" its:version="1.0">
 <msg id="pmAdded">The printer <var arg="0" its:locNote="Printer name"/> 
  has been added to the list.</msg>
 <msg id="fmAdded">The file <var arg="0" its:locNote="Filename"/> 
  has been added to the list.</msg>
 </strings>

[Code source de l'exemple]

Voici une traduction en français du document montré ci-dessus. Le contexte fourni a permis de lever l'ambiguïté sur la variable et de produire une traduction plus précise.

<strings xmlns:its="http://www.w3.org/2005/11/its"
 xml:lang="fr" its:version="1.0">
 <msg id="pmAdded">L'imprimante <var arg="0" its:locNote="Printer name"/> 
  a été ajoutée à la liste.</msg>
 <msg id="fmAdded"><var arg="0" its:locNote="Filename"/> 
  a été ajouté à la liste.</msg>
</strings>

[Code source de l'exemple]

Pourquoi le faire

Mal utilisé, un texte inséré peut causer des problèmes importants (voire insolubles) lors de la localisation. Examinons l'exemple suivant :

Exemple 29 : Utiliser conref dans DITA.

Voici un exemple de mauvaise conception. Dans cet exemple, le créateur, travaillant avec le format DITA [DITA 1.0], a décidé de référencer un terme dans une base terminologique (termbase) en utilisant le mécanisme conref. Ici le terme t123 dans le fichier termbase.xml a pour valeur « hydraulic lift ».

<p>Using a <term conref="termbase.xml#t123"/>, raise the vehicle from the ground.</p>

Au premier abord, l'exemple ci-dessus semble bien fonctionner en anglais. Toujours est-il qu'une telle construction présente plusieurs problèmes :

  • On ne devrait pas séparer l'article du nom. Si un autre terme devait remplacer indépendamment « hydraulic lift » dans le futur, il faudra peut-être remplacer l'article « a » par « an », ou le supprimer ;

  • La séparation de l'article et du nom pose aussi des problèmes aux traducteurs. S'ils ne peuvent pas visualiser facilement le terme réel en traduisant le paragraphe, ils seront dans l'impossibilité de décider du genre ou du nombre de l'article ;

  • S'il est utilisé au début d'une autre phrase, l'initiale du terme devra être mise en majuscule ;

  • Le terme est au singulier dans la base terminologique mais il sera peut-être au pluriel ailleurs dans le document ;

  • Dans les langues infléchies, la forme nécessitée dans le texte peut être différente de celle stockée dans la base terminologique. Par exemple, en polonais, le terme serait stocké dans sa forme nominative « dźwignia hydrauliczna » et, inséré dans ce contexte, il devrait l'être dans la forme instrumentale ainsi : « Używając dźwignię hydrauliczną podnieś pojazd z ziemi ».

Ressources :

Documentation de base

Utilisez du balisage dédié pour identifier un contenu terminologique (terminology-related content).

Ce qui constitue un terme dépend de plusieurs facteurs qui sont spécifiques de chaque organisation et projet. Les termes peuvent comprendre, par exemple, des noms de fonctions, de programmes, de services, et ainsi de suite. Ils peuvent aussi inclure des mots ou expressions spécifiques du domaine auquel le contenu se rapporte, tels que des termes techniques ou des termes juridiques, et ils peuvent simplement inclure des termes qui apparaissent souvent et qui devraient être systématiquement (consistently) traduits.

Comment le faire

Utilisez les attributs its:term et its:termInfoRef (ou leurs équivalents dans votre schéma) pour marquer les termes et fournir une information en rapport au terme.

Votre schéma devrait fournir les attributs its:term et its:termInfoRef (ou des mécanismes équivalents). Cf. la Pratique exemplaire 11 — Définir un balisage pour spécifier ou écraser l'information terminologique.

Vous devriez également écraser les règles terminologiques par défaut au besoin.

Exemple 30 : Identifier un contenu terminologique.

Dans ce document, les termes sont normalement dénoté par un élément term. Suivant la Pratique exemplaire 10 — Identifier les éléments terminologiques, le développeur du schéma a fourni un document de règles ITS qui définir cette propriété pour term.

Quoiqu'il en soit, dans ce document particulier, le créateur veut indiquer les choses suivantes :

  • le contenu d'un élément ui devrait être vu comme un terme ;

  • le texte « Vector Files » dans le titre est un terme.

Dans le premier cas, le créateur utilise un élément its:termRule dans l'en-tête du document pour indiquer que tout élément ui dans ce document est un terme. C'est plus efficace que d'ajouter un attribut à chaque instance de ui dans le corps du document.

Dans le deuxième cas, puisque le schéma n'autorise pas la présence de l'élément term dans l'élément title (un oubli du développeur), le créateur utilise un simple élément span avec les attributs its:term et its:termInfoRef pour associer « Vector Files » à l'information terminologique qui lui correspond.

<myManual xmlns:its="http://www.w3.org/2005/11/its" its:version="1.0">
 <head>
  <its:rules>
   <its:termRule selector="//ui" term="yes"/>
  </its:rules>
  <title>Generating <span its:term="yes" its:termInfoRef="#vFile">Vector 
   Files</span></title>
 </head>
 <body>
  <par>Select the command <ui>Build Output Files</ui> from the 
   <ui>Tasks</ui> menu to generate the final <term ref="vFile">vector
   files</term>.</par>
 </body>
 <extra>
  <terms>
   <termDef xml:id="vFile">A <emph>vector file</emph> is a binary document
    that contains the complete set of vectors needed to draw the background 
    layer of a map.</termDef>
  </terms>
 </extra>
</myManual>

[Code source de l'exemple]

Voici le document de règles ITS créé par le développeur du type de document myManual (en mettant en œuvre la Pratique exemplaire 10 — Identifier les éléments terminologiques). Il fournit un élément termRule indiquant que tout élément term est un terme et que l'information qui lui est associée se trouve dans un élément identifié par la valeur stockée dans l'attribut ref de l'élément term.

<its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
 <its:termRule selector="//term" term="yes" termInfoRef="id(@ref)"/>
</its:rules>

[Code source de l'exemple]

Pourquoi le faire

Si on n'indique pas quels mots sont des termes d'intérêt dans le contenu, les traducteurs ne sauront pas que ces termes doivent être traduits systématiquement. Souvent plusieurs traducteurs travaillent sur les différents fichiers d'un projet donné et le choix de traduire des mots spécifiques peut être incohérent par rapport à celui des autres traducteurs. Si on marque les termes importants dans le contenu, ils peuvent les extraire avant la traduction du contenu et les traduire au préalable pour les partager dans un dictionnaire électronique. Cela assure la cohérence de la traduction des termes importants.

Bien que le balisage dénotant les termes d'un niveau de schéma donné devrait être défini dans un ensemble de règles ITS fournies avec le schéma (cf. la Pratique exemplaire 10 — Identifier les éléments terminologiques), il y a des situations où ces règles générales doivent être écrasées ou complétées pour des éléments spécifiques, dans des documents spécifiques. C'est au créateur du contenu de fournir ce balisage de dérogation (overriding markup).

Évitez le balisage d'échappement (escaping markup) pour permettre le stockage du balisage issu d'un autre format.

Comment le faire

Si possible, utilisez le mécanisme d'espace de noms XML pour stocker des vocabulaires différents dans un seul document XML.

Exemple 31 : Comment éviter d'inclure du balisage dans une forme échappée.

Dans ce document, les éléments top et body contiennent tous les deux du balisage HTML codé comme du texte. Il n'existe pas de méthode aisée pour faire la distinction entre le balisage HTML et le contenu de texte HTML.

<pages>
 <row>
  <key>ENConvClasses</key>
  <top>&lt;span class="h1"&gt;Elibur Library&lt;/span&gt; - Conversation Groups</top>
  <body><![CDATA[<p>These small discussion groups meet <b>weekly</b> and are for
people learning English. Each group is led by a volunteer who is a native speaker 
of American English. Groups converse about books, articles, and other materials.</p>
<p>Space is limited. Ask for availability to <a href="mailto:enconv@elibur-lib.com">
enconv@elibur-lib.com</a>.</p>]]></body>
 </row>
</pages>

[Code source de l'exemple]

Utilisez plutôt le mécanisme d'espace de noms XML. Ici le contenu de top et body est maintenant un mélange de texte et d'éléments XHTML. On évite ainsi toute confusion entre le texte et les balises HTML.

<pages xmlns:h="http://www.w3.org/1999/xhtml">
 <row>
  <key>ENConvClasses</key>
  <top><h:span class="h1">Elibur Library</h:span> - Conversation Groups</top>
  <body><h:p>These small discussion groups meet <h:b>weekly</h:b> and are for
people learning English. Each group is led by a volunteer who is a native
speaker of American English. Groups converse about books, articles, and 
other materials.</h:p>
<h:p>Space is limited. Ask for availability to <h:a 
href="mailto:enconv@elibur-lib.com">enconv@elibur-lib.com</h:a>.</h:p></body>
 </row>
</pages>

[Code source de l'exemple]

Une alternative à l'utilisation du balisage en tant que texte est de stocker celui-ci à l'extérieur et de l'inclure au document à l'aide d'un mécanisme tel que XInclude ou XLink.

Si vous devez inclure du balisage contenu dans le texte :

  • Assurez-vous de documenter le type de contenu, par exemple avec un attribut affecté du type MIME adéquat. Cela peut aider les outils à choisir un analyseur plus approprié pour traiter le contenu en question ;

  • Cherchez à produire du contenu bien formé. Cela permettra aux analyseurs de traiter le contenu plus aisément.

Pourquoi le faire

Certains documents XML sont utilisés pour stocker différents types de données pour des besoins d'échange ou d'export. Parfois, ces données sont elles-mêmes des données XML. Par exemple, un contenu XHTML stocké dans une base de données peut être exporté vers un fichier conteneur XML pour une localisation puis réimporté dans la base de données.

Remarque : L'utilisation d'un échappement pour des exemples littéraux de balisage n'est pas un problème. La question se pose seulement pour un large volume de données XML/HTML contenues dans un autre document XML.

Le stockage de telles données XML au sein d'éléments XML comme contenu de texte (c'est-à-dire dont les balises sont échappées) a plusieurs inconvénients :

  • Toute manipulation d'un tel contenu est rendue difficile du fait de l'impossibilité de séparer le texte du balisage sans traitement supplémentaire ;

  • Souvent un tel contenu se place dans des sections de type CDATA, lesquels ont leur cortège de problèmes. Cf. la Pratique exemplaire 20 — Éviter les sections de type CDATA ;

  • Le balisage échappé ne peut pas être validé ;

  • S'il y a un processus qui transforme le balisage en échappement, il existe un risque de double échappement.

Vers la table des matières. 4 Techniques génériques

Cette section présente un ensemble de techniques génériques applicables à diverses directives ; par exemple, comment ajouter des attributs ITS à différents types de schémas, ou comment optimiser les expressions XPath de l'attribut selector ITS.

Vers la table des matières. 4.1 Écriture des règles ITS

Lors de l'écriture de règles ITS, qu'elles soient externes ou incorporées, on doit prendre en considération plusieurs choses :

  • Essayez de maintenir le nombre de nœuds à écraser au minimum. Cela améliore les performances. Par exemple, si la majeure partie du document ne doit pas être traduite, il vaut mieux affecter l'élément racine comme étant non traduisible plutôt que d'affecter tous les éléments. Le mécanisme d'héritage produira le même effet pour un coût de calcul bien moindre ;

  • Puisqu'une règle est prioritaire sur celles qui précèdent, vous devriez commencer par les règles plus générales et les écraser progressivement au besoin. Certaines règles peuvent être plus complexes si on doit tenir compte de tous les aspects de l'héritage.

Vers la table des matières. 4.1.1 Priorité et héritage

La spécification ITS 1.0 définit la priorité de l'information ITS des catégories de données. L'ordre de priorité de la sélection est le suivant (en commençant par la priorité la plus élevée), et on l'expliquera en utilisant la catégorie de données Traduire ITS :

  1. Les attributs ITS locaux sur un élément spécifique, par exemple l'attribut its:translate, ont la priorité la plus élevée ;

  2. Suivent les règles globales, par exemple un ensemble d'éléments its:translateRule de la catégorie de données Traduire ITS. Les règles individuelles dans un élément its:rules ont une priorité héritée qui dépend de leur position dans l'élément its:rules : les règles en bas ont une priorité plus élevée que celles en haut. De plus, les règles au sein d'un élément its:rules donné ont une priorité supérieure à celle des règles reliées via un attribut xlink:href dans ce même élément its:rules ;

  3. L'information ITS héritée constitue le troisième niveau de priorité. Le type d'héritage dépend de la catégorie de données. Par exemple, si un élément est étiqueté comme « à ne pas traduire », en utilisant l'une des méthodes décrites en 1) ou en 2), cette information est héritée par ses sous-éléments mais pas par les attributs ;

  4. L'information ITS issue des définitions par défaut d'une catégorie de données est celle de moindre priorité. Par exemple, le comportement par défaut de la catégorie de données Traduire ITS est qu'il faut traduire le contenu des éléments et pas les valeurs des attributs.

L'exemple suivant montre l'utilisation du balisage ITS local et global, et la prise en compte de la priorité décrite ci-dessus.

Exemple 32 : Priorité et héritage dans ITS.

Dans ce document, tous les sous-éléments de <text> sont affectés comme « à ne pas traduire » par le premier élément its:translateRule. Quoiqu'il en soit, le deuxième et le dernier éléments its:translateRule ont une priorité supérieure à l'élément qui les précède, et on peut donc s'en servir pour décrire une exception : tous les éléments <p> doivent toujours être traduits. Cela montre le jeu entre les différentes règles et démontre que la dernière « l'emporte ».

Une autre exception au premier élément its:translateRule est exprimée par l'attribut local its:translate sur l'élément <notes>. Il indique de traduire le contenu de cet élément. En absence de l'attribut its:translate, l'information du premier élément its:translateRule aurait été héritée et l'élément <notes> ne serait pas traduisible.

Enfin, le contenu de l'élément <documentation> au sein de l'élément <head> est également traduisible mais pas le contenu des attributs dans le document. Cela démontre le rôle des définitions par défaut de la catégorie de données Traduire ITS.

<doc xmlns:its="http://www.w3.org/2005/11/its">
 <head>
  <documentation>Some translatable text.</documentation>
  <its:rules version="1.0">
   <its:translateRule selector="//text" translate="no"/>
   <its:translateRule selector="//p" translate="yes"/>
  </its:rules>
 </head>
 <text>
  <data>Some data with <code>coded parts</code> (<notes 
its:translate="yes"> and translatable text</notes>).</data>
  <p>Some text with <b>bolded words</b>.</p>
 </text>
</doc>

[Code source de l'exemple]

Vers la table des matières. 4.1.2 Prise en compte des espaces de noms

Lors de l'écriture de règles pour des documents utilisant des espaces de noms XML, assurez-vous de déclarer les espaces de noms, et utilisez les préfixes appropriés dans les différentes expressions XPath.

Exemple 33 : Appliquer des règles ITS sur un document contenant des espaces de noms.

Le premier document utilise plusieurs vocabulaires XML différents :

  • Le format hôte n'est pas associé à un espace de noms. Ses éléments n'ont pas de préfixe ;

  • Le vocabulaire "inventory-book" est associé à l'espace de noms http://www.example.com/inventory-book. Les éléments appartenant à cet espace de noms ont pour préfixe bk ;

  • Le vocabulaire XHTML est associé à l'espace de noms http://www.w3.org/1999/xhtml. Les éléments appartenant à cet espace de noms ont pour préfixe h ;

  • Le vocabulaire XLink est associé à l'espace de noms http://www.w3.org/1999/xlink. Il y a un seul attribut dans cet espace de noms et il a pour préfixe xlink ;

  • Le vocabulaire ITS est associé à l'espace de noms http://www.w3.org/2005/11/its. Il y a un seul élément dans cet espace de noms et il a pour préfixe its.

<inventory xmlns:bk="http://www.example.com/inventory-book"
 xmlns:h="http://www.w3.org/1999/xhtml"
 xmlns:xlink="http://www.w3.org/1999/xlink"
 xmlns:its="http://www.w3.org/2005/11/its">
 <header>
  <identity>3E039D7D-B416-47e8-83B3-3F4DF9EDDB87</identity>
  <lastUpdate>2007-11-12</lastUpdate>
  <desc>Inventory made by Joan, for shelves H to K only.</desc>
  <its:rules version="1.0" xlink:href="EX-namespaces-2.xml" xlink:type="simple"/>
 </header>
 <list>
  <bk:book xml:id="item00A83">
   <bk:isbn>0312875819</bk:isbn>
   <bk:quantity>2</bk:quantity>
   <bk:type>HIST</bk:type>
   <bk:author>Bradshaw, Gillian</bk:author>
   <bk:pub>Forge Books; New Ed edition (June 2, 2001)</bk:pub>
   <bk:title>The Sand-Reckoner</bk:title>
   <bk:desc>
    <h:p>Building on a few antique facts, Bradshaw ably recreates the extraordinary 
life of Archimedes, the great mathematician and engineer who lived in Syracuse from
287 to 212 B.C. After a few years studying in Alexandria, Archimedes returns home
where his father is dying and his city at war with the Romans.
<h:img src="0312875819large.png" alt="The Sand-Reckoner (by Gillian Bradshaw)"/>
</h:p>
   </bk:desc>
  </bk:book>
 </list>
</inventory>

[Code source de l'exemple]

Les espaces de noms XLink et ITS sont juste utilisés pour associer ce document au fichier externe des règles ITS montré ci-dessous.

Le document de règles ITS contient plusieurs règles qui déterminent quelles parties du document d'inventaire traduire. Les règles utilisent des expressions XPath où les éléments sont préfixés. Ces préfixes sont associés aux espaces de noms utilisés dans l'inventaire. Voici une description de chaque règle its:translateRule de haut en bas :

  • La première indique de ne pas traduire l'élément inventory. Tous les sous-éléments de inventory en héritent. La plus grande partie du contenu de l'inventaire ne doit pas être traduite, et le moyen le plus pratique de définir les règles appropriées pour ce type de document consiste à annoncer la non-traductibilité de l'élément racine puis à lister toutes les exceptions ;

  • La deuxième indique de traduire l'élément desc du format hôte ;

  • La troisième indique de traduire l'élément title de l'espace de noms http://www.example.com/inventory-book ;

  • La quatrième indique de traduire l'élément desc de l'espace de noms http://www.example.com/inventory-book ;

  • La dernière indique de traduire l'attribut alt de l'élément HTML img.

<its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0"
 xmlns:book="http://www.example.com/inventory-book"
 xmlns:html="http://www.w3.org/1999/xhtml">
 <its:translateRule selector="//inventory" translate="no"/>
 <its:translateRule selector="//desc" translate="yes"/>
 <its:translateRule selector="//book:title" translate="yes"/>
 <its:translateRule selector="//book:desc" translate="yes"/>
 <its:translateRule selector="//html:img/@alt" translate="yes"/>
</its:rules>

[Code source de l'exemple]

Vers la table des matières. 4.1.3 Créez vos expressions XPath soigneusement

ITS emploie des expressions XPath dans plusieurs contextes pour identifier des nœuds. Cette utilisation prédomine dans des contextes de sélecteurs et d'attributs pointeurs comme ceux montrés dans les règles suivantes :

<its:translateRule selector="//term" translate="no"/>

ou encore :

<its:locNoteRule locNoteType="description" selector="//msg/data"
 locNotePointer="../notes"/>

Lors de l'écriture d'expressions XPath liées à ITS, comme les précédentes, on doit considérer les points suivants :

Dans les environnements utilisant XSLT pour traiter les expressions XPath liées à ITS, il est important de connaître le sous-ensemble de XPath désigné par les « motifs XSLT » (XSLT patterns) — cf. la remarque dans la section Approche globale de la spécification ITS. Utiliser seulement des motifs XSLT dans les attributs selector ITS permet d'éviter les problèmes qui peuvent se produire par rapport à l'attribut match dans l'élément template XSLT.

Outre ce conseil général, vous devriez prendre en compte les pratiques exemplaires en rapport à l'écriture des expressions XPath (cf. par exemple le Tutoriel XPath).

Vers la table des matières. 4.2 Exemple d'ajout d'un attribut à un schéma existant

Cet exemple montre comment ajouter un attribut (ici xml:lang) à un type de document existant. Nous ajouterons l'attribut à un élément nommé para.

Notez que cet exemple ne montre que quelques façons d'ajouter des attributs. Il en existe beaucoup d'autres, selon le langage de schéma et les techniques de modularisation employées dans le schéma existant.

Vers la table des matières. 4.2.1 Inclure xml:lang dans XML Schema

Pour inclure l'attribut xml:lang dans votre document XML Schema, importez le schéma xml.xsd du W3C dans votre propre schéma à l'aide de l'élément xs:import.

Exemple 34 : Importer la déclaration xml:lang dans XML Schema.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
 <!-- Import for xml:lang and xml:space -->
 <xs:import namespace="http://www.w3.org/XML/1998/namespace"
            schemaLocation="http://www.w3.org/2001/xml.xsd"/>
 ...

Une fois importé le schéma xml.xsd, vous pouvez utiliser la référence à xml:lang dans n'importe laquelle de vos déclarations d'élément.

Exemple 35 : Utiliser xml:lang dans XML Schema.
... 
<xs:element name="para">
 <xs:complexType>
  <xs:sequence maxOccurs="unbounded">
    ...
  </xs:sequence>
  <xs:attribute ref="xml:lang" use="optional"/>
 </xs:complexType>
</xs:element>
...

Vers la table des matières. 4.2.2 Inclure xml:lang dans RELAX NG

Déclarez xml:lang directement dans votre schéma. Il n'existe pas de déclaration de l'attribut xml:lang, ni de fragment de schéma normalisé le définissant dans RELAX NG. Vous devez déclarer xml:lang directement dans votre schéma et définir comme choix de valeurs soit le type de données language de XML Schema, soit la valeur vide.

Exemple 36 : Déclaration de xml:lang dans RELAX NG.
<element name="para" 
         xmlns="http://relaxng.org/ns/structure/1.0" 
         datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
  <attribute name="xml:lang">
    <choice>
      <data type="language"/>
      <value></value>
    </choice>
  </attribute>
  ...
</element>

Vers la table des matières. 4.2.3 Inclure xml:lang dans une définition DTD XML

Ajoutez xml:lang directement dans la liste d'attributs de votre élément.

Par exemple, pour ajouter xml:lang à l'élément para, vous devez indiquer ce qui suit dans une définition DTD :

Exemple 37 : Déclaration de xml:lang dans une définition DTD.
<!ELEMENT para (#PCDATA)> 
<!ATTLIST para
          xml:lang CDATA #IMPLIED>

Vers la table des matières. 5 ITS appliqué aux formats existants

Cette section présente plusieurs exemples de la façon d'utiliser ITS pour promouvoir la préparation de l'internationalisation de quelques types de documents XML bien connus. Ces exemples sont seulement illustratifs et demanderont peut-être une adaptation pour satisfaire aux besoins de chaque utilisateur spécifique.

Chaque format recouvre deux thèmes :

Voici les vocabulaires XML traités :

Vers la table des matières. 5.1 ITS et XHTML 1.0

XHTML [XHTML 1.0] est une reformulation des trois types de documents HTML 4 comme des applications de XML 1.0. HTML est une application SGML (Standard Generalized Markup Language), considéré par beaucoup comme le langage d'édition standard du Web.

Vers la table des matières. 5.1.1 Intégrer ITS à XHTML

Dans XHTML 1.0, on peut utiliser l'espace de noms XHTML avec d'autres espaces de noms XML, selon les Espaces de noms dans XML [XML Names], mais de tels documents ne sont plus du XHTML 1.0 strictement conforme.

Voici l'exemple d'un document contenant des règles ITS, lequel est un document XHTML 1.0 non conforme.

Exemple 38 : Règles ITS dans un document XHTML 1.0 non conforme
<html xmlns="http://www.w3.org/1999/xhtml"
 xmlns:its="http://www.w3.org/2005/11/its" lang="en" xml:lang="en">
 <head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <meta name="keywords" content="ITS example, XHTML translation" />
  <its:rules version="1.0" xmlns:h="http://www.w3.org/1999/xhtml">
   <its:translateRule selector="//h:meta[@name='keywords']/@content"
    translate="yes" />
   <its:termRule selector="//h:span[@class='term']" term="yes" />
  </its:rules>
  <title>ITS Working Group</title>
 </head>
 <body>
  <h1>Test of ITS on <span class="term">XHTML</span></h1>
  <p>Some text to translate.</p>
  <p its:translate="no">Some text not to translate.</p>
 </body>
</html>

[Code source de l'exemple]

Il y a trois façons d'utiliser ITS avec XHTML et de préserver la conformité du document XHTML :

  1. Utiliser la modularisation XHTML [XHTMLMod1.1]. Cf. la section 5.1.2 Utiliser XHTML Modularization 1.1 pour la définition de ITS pour des détails ;

  2. Utiliser des règles ITS globales externes, comme indiqué dans l'exemple suivant. Même l'information locale au sein du document qui serait gérés par des attributs ITS peut être fixée indirectement.

    Exemple 39 : Règles ITS externes pour XHTML.

    Ces règles illustrent quelques catégories de données ITS que vous pouvez associer à un balisage XHTML spécifique. Le premier élément its:translateRule indique de traduire l'attribut content de l'élément meta si l'attribut name a la valeur "keywords". Le deuxième its:translateRule indique de ne pas traduire les éléments p avec class="notrans". Le troisième its:termRule indique que les éléments span avec class="term" sont des termes.

    <its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0"
     xmlns:h="http://www.w3.org/1999/xhtml">
     <its:translateRule selector="//h:meta[@name='keywords']/@content"
      translate="yes" />
     <its:translateRule selector="//h:p[@class='notrans']"
      translate="no" />
     <its:termRule selector="//h:span[@class='term']" term="yes" />
    </its:rules>
    

    [Code source de l'exemple]

    Le document correspondant :

    <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
     <head>
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
      <meta name="keywords" content="ITS example, XHTML translation" />
      <title>ITS Working Group</title>
     </head>
     <body>
      <h1>Test of ITS on <span class="term">XHTML</span></h1>
      <p>Some text to translate.</p>
      <p class="notrans">Some text not to translate.</p>
     </body>
    </html>
    

    [Code source de l'exemple]

  3. Utiliser NVDL. Cf. la section 5.1.3 Utiliser NVDL pour intégrer ITS à XHTML pour des détails.

Vers la table des matières. 5.1.2 Utiliser XHTML Modularization 1.1 pour la définition de ITS

Cette section décrit comment utiliser XHTML Modularization 1.1 [XHTMLMod1.1] pour la définition de ITS. Elle définit d'abord un module abstrait ITS qui est ensuite implémenté au format XML Schema. Le module est destiné à être intégré dans des schémas existants ou nouveaux qui s'appuient sur XHTML Modularization 1.1.

5.1.2.1 Définition abstraite du balisage ITS

Voici la définition abstraite des éléments pour un balisage ITS global, laquelle est conforme à l'environnement XHTML Modularization [XHTMLMod1.1]. On trouvera d'autres définitions de modules abstraits XHTML dans la spécification XHTML Modularization [XHTMLMod1.1].

Notez que cette définition ne contient pas l'élément ruby et l'attribut dir, puisqu'ils sont déjà disponibles dans XHTML. On devrait associer un tel balisage existant aux catégories de données ITS avec un élément its:rules. Cf. la section 5.1.4 Associer du balisage XHTML à ITS.

ÉlémentsAttributsModèle de contenu minimal
rules version (CDATA), xlink:href (URI), xlink:type ("simple") ( translateRule | locNoteRule | termRule | dirRule | rubyRule | langRule | withinTextRule )*
translateRule Selector, translate ("yes"|"no") EMPTY
locNoteRule Selector, locNotePointer (CDATA), locNoteType ("alert"| "description"), locNoteRef (URI), locNoteRefPointer (CDATA) locNote?
locNote translate ("yes"|"no"), locNote (CDATA), locNoteType ( "alert" | "description"), locNoteRef (URI), termInfoRef ( URI ), term ( "yes" | "no" ), dir ( "ltr" | "rtl" | "lro" | "rlo" ) (PCDATA | ruby)*
termRule Selector, term ( "yes" | "no" ), termInfoRef ( URI ), termInfoRefPointer ( CDATA), termInfoPointer ( CDATA ) EMPTY
dirRule Selector, dir ("ltr" | "rtl" | "lro" | "rlo") EMPTY
rubyRule Selector, rubyPointer (CDATA), rtPointer (CDATA), rpPointer (CDATA), rbcPointer (CDATA), rtcPointer (CDATA), rbspanPointer (CDATA) rubyText
rubyText translate ("yes"|"no"), locNote (CDATA), locNoteType ("alert"|"description"), locNoteRef (URI), term ("yes" | "no"), termInfoRef (CDATA), dir ("ltr" | "rtl" | "lro" | "rlo" ), rbspan (CDATA) PCDATA
langRule Selector, langPointer (CDATA) EMPTY
withinTextRule Selector, withinText ("yes"|"no"|"nested") EMPTY

Voici les définitions abstraites de deux groupes d'attributs : l'attribut selector utilisé au sein des règles globales et les attributs ITS à utiliser localement. Ces définitions utilisent encore XHTML Modularization 1.1.

CollectionAttributs dans la collection
Selector selector (CDATA)
ITSLocal translate ("yes"|"no"), locNote (CDATA), locNoteType ("alert"|"description"), locNoteRef (URI), termInfoRef (URI), term ("yes" | "no")
5.1.2.2 Mise en œuvre du module XML Schema ITS

Le schéma suivant contient la mise en œuvre du module de balisage abstrait en XML Schema.

Exemple 40 :.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://www.w3.org/2005/11/its"
    xmlns:its="http://www.w3.org/2005/11/its"
    xmlns:h="http://www.w3.org/1999/xhtml" elementFormDefault="qualified"
    xmlns:xlink="http://www.w3.org/1999/xlink">
    <xs:import namespace="http://www.w3.org/1999/xlink" schemaLocation="xlink.xsd"/>
    <xs:import namespace="http://www.w3.org/1999/xhtml"
        schemaLocation="xhtml-schemas/xhtml-ruby-1.xsd"/>
    <xs:simpleType name="translate.type">
        <xs:restriction base="xs:string">
            <xs:enumeration value="yes"/>
            <xs:enumeration value="no"/>
        </xs:restriction>
    </xs:simpleType>
    <xs:simpleType name="term.type">
        <xs:restriction base="xs:string">
            <xs:enumeration value="yes"/>
            <xs:enumeration value="no"/>
        </xs:restriction>
    </xs:simpleType>
    <xs:simpleType name="locNoteType.type">
        <xs:restriction base="xs:string">
            <xs:enumeration value="alert"/>
            <xs:enumeration value="description"/>
        </xs:restriction>
    </xs:simpleType>
    <xs:simpleType name="dir.type">
        <xs:restriction base="xs:string">
            <xs:enumeration value="ltr"/>
            <xs:enumeration value="ltr"/>
            <xs:enumeration value="lro"/>
            <xs:enumeration value="rlo"/>
        </xs:restriction>
    </xs:simpleType>
    <xs:simpleType name="withinText.type">
        <xs:restriction base="xs:string">
            <xs:enumeration value="yes"/>
            <xs:enumeration value="no"/>
            <xs:enumeration value="nested"/>
        </xs:restriction>
    </xs:simpleType>
    <xs:attributeGroup name="its.Selector.attlist">
        <xs:attribute name="selector" type="xs:string" use="required"/>
    </xs:attributeGroup>
    <xs:attributeGroup name="its.ITSLocal.attlist">
        <xs:attribute name="translate" form="qualified" use="optional"
         type="its:translate.type"/>
        <xs:attribute name="locNote" type="xs:string" form="qualified" 
         use="optional"/>
        <xs:attribute name="locNoteType" form="qualified" use="optional"
         type="its:locNoteType.type"/>
        <xs:attribute name="locNoteRef" type="xs:anyURI" form="qualified"
         use="optional"/>
        <xs:attribute name="termInfoRef" type="xs:string" form="qualified"
         use="optional"/>
        <xs:attribute name="term" type="its:term.type" form="qualified"
         use="optional"/>
    </xs:attributeGroup>
    <xs:element name="rules" type="its:rules.type"/>
    <xs:complexType name="rules.type" mixed="false">
        <xs:choice minOccurs="0" maxOccurs="unbounded">
            <xs:element ref="its:translateRule"/>
            <xs:element ref="its:locNoteRule"/>
            <xs:element ref="its:termRule"/>
            <xs:element ref="its:dirRule"/>
            <xs:element ref="its:rubyRule"/>
            <xs:element ref="its:langRule"/>
            <xs:element ref="its:withinTextRule"/>
        </xs:choice>
        <xs:attributeGroup ref="its:rules.attlist"/>
    </xs:complexType>
    <xs:attributeGroup name="rules.attlist">
        <xs:attribute name="version" use="required" type="xs:string"/>
        <xs:attribute ref="xlink:href" use="optional"/>
        <xs:attribute ref="xlink:type" use="optional"/>
    </xs:attributeGroup>
    <xs:element name="translateRule" type="its:translateRule.type"/>
    <xs:complexType name="translateRule.type">
        <xs:attributeGroup ref="its:its.Selector.attlist"/>
        <xs:attribute name="translate" use="required" type="its:translate.type"/>
    </xs:complexType>
    <xs:element name="locNoteRule" type="its:locNoteRule.type"/>
    <xs:complexType name="locNoteRule.type">
        <xs:sequence minOccurs="0" maxOccurs="1">
            <xs:element ref="its:locNote"/>
        </xs:sequence>
        <xs:attributeGroup ref="its:its.Selector.attlist"/>
        <xs:attribute name="locNotePointer" type="xs:string" use="optional"/>
        <xs:attribute name="locNoteType" use="required" type="its:locNoteType.type"/>
        <xs:attribute name="locNoteRef" type="xs:anyURI" use="optional"/>
        <xs:attribute name="locNoteRefPointer" type="xs:string" use="optional"/>
    </xs:complexType>
    <xs:element name="locNote" type="its:locNote.type"/>
    <xs:complexType name="locNote.type" mixed="true">
        <xs:attribute name="translate" use="optional" type="its:translate.type"/>
        <xs:attribute name="locNote" type="xs:string" use="optional"/>
        <xs:attribute name="locNoteType" use="optional" type="its:locNoteType.type"/>
        <xs:attribute name="locNoteRef" type="xs:anyURI" use="optional"/>
        <xs:attribute name="termInfoRef" type="xs:anyURI" use="optional"/>
        <xs:attribute name="term" use="optional" type="its:term.type"/>
        <xs:attribute name="dir" use="optional" type="its:dir.type"/>
    </xs:complexType>
    <xs:element name="termRule"/>
    <xs:complexType name="termRule.type">
        <xs:attributeGroup ref="its:its.Selector.attlist"/>
        <xs:attribute name="term" type="its:term.type" use="required"/>
        <xs:attribute name="termInfoRef" type="xs:anyURI" use="optional"/>
        <xs:attribute name="termInfoRefPointer" type="xs:string" use="optional"/>
        <xs:attribute name="termInfoPointer" type="xs:string" use="optional"/>
    </xs:complexType>
    <xs:element name="dirRule" type="its:dirRule.type"/>
    <xs:complexType name="dirRule.type">
        <xs:attributeGroup ref="its:its.Selector.attlist"/>
        <xs:attribute name="dir" type="its:dir.type" use="required"/>
    </xs:complexType>
    <xs:element name="rubyRule"/>
    <xs:complexType name="rubyRule.type">
        <xs:sequence>
            <xs:element ref="its:rubyText"/>
        </xs:sequence>
        <xs:attributeGroup ref="its:its.Selector.attlist"/>
        <xs:attribute name="rubyPointer" type="xs:string" use="optional"/>
        <xs:attribute name="rtPointer" type="xs:string" use="optional"/>
        <xs:attribute name="rpPointer" type="xs:string" use="optional"/>
        <xs:attribute name="rbcPointer" type="xs:string" use="optional"/>
        <xs:attribute name="rtcPointer" type="xs:string" use="optional"/>
        <xs:attribute name="rbspanPointer" type="xs:string" use="optional"/>
    </xs:complexType>
    <xs:element name="rubyText" type="its:rubyText.type"/>
    <xs:complexType name="rubyText.type" mixed="true">
        <xs:attribute name="translate" type="its:translate.type" use="optional"/>
        <xs:attribute name="locNote" type="xs:string" use="optional"/>
        <xs:attribute name="locNoteType" type="its:locNoteType.type" use="optional"/>
        <xs:attribute name="locNoteRef" type="xs:anyURI" use="optional"/>
        <xs:attribute name="term" type="its:term.type" use="optional"/>
        <xs:attribute name="termInfoRef" type="xs:string" use="optional"/>
        <xs:attribute name="dir" type="its:dir.type" use="optional"/>
        <xs:attribute name="rbspan" type="xs:string" use="optional"/>
    </xs:complexType>
    <xs:element name="langRule"/>
    <xs:complexType name="langRule.type">
        <xs:attributeGroup ref="its:its.Selector.attlist"/>
        <xs:attribute name="langPointer" type="xs:string" use="required"/>
    </xs:complexType>
    <xs:element name="withinTextRule"/>
    <xs:complexType name="withinTextRule.type">
        <xs:attributeGroup ref="its:its.Selector.attlist"/>
        <xs:attribute name="withinText" type="its:withinText.type"/>
    </xs:complexType>
</xs:schema>

Voici un fichier pilote (driver file) utilisable pour évoquer le schéma ci-dessus.

Exemple 41 :.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:xhtml="http://www.w3.org/1999/xhtml"
    targetNamespace="http://www.w3.org/1999/xhtml"
    xmlns:its="http://www.w3.org/2005/11/its"
    xmlns="http://www.w3.org/1999/xhtml" blockDefault="#all">
    <xs:annotation>
        <xs:documentation> This is the XML Schema Driver for new Document Type
         XHTML Basic 1.0 + ITS
         $Id: Overview.html,v 1.10 2008/02/12 04:55:09 fsasaki Exp $
        </xs:documentation>
        <xs:documentation
         source="http://www.w3.org/TR/xml-i18n-bp/#integration-its-xhtmlmod"/>
    </xs:annotation>
    <xs:import namespace="http://www.w3.org/2005/11/its"
     schemaLocation="its-module.xsd"/>
    <xs:redefine schemaLocation="xhtml-schemas/xhtml-basic10.xsd">
        <xs:group name="HeadOpts.mix">
            <xs:choice>
                <xs:group ref="HeadOpts.mix"/>
                <xs:element ref="its:rules"/>
            </xs:choice>
        </xs:group>
        <xs:attributeGroup name="Common.attrib">
            <xs:attributeGroup ref="Common.attrib"/>
            <xs:attributeGroup ref="its:its.ITSLocal.attlist"/>
        </xs:attributeGroup>
    </xs:redefine>
</xs:schema>

Le fichier ci-dessous est une instance validable par rapport à ce schéma.

Exemple 42 :.
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:xlink="http://www.w3.org/1999/xlink"
    xmlns:its="http://www.w3.org/2005/11/its">
    <head>
        <title> </title>
        <its:rules version="1.0">
            <its:locNoteRule locNoteType="alert" selector="..." locNoteRef="...">
            </its:locNoteRule>
            <its:locNoteRule locNoteType="alert" selector="...">
                <its:locNote> </its:locNote>
            </its:locNoteRule>
            <its:termRule selector="..." term="yes"/>
        </its:rules>
    </head>
    <body>
        <h3> </h3>
        <table>
            <tr>
                <td> </td>
            </tr>
        </table>
        <ul>
            <li its:locNote="..." its:translate="no"> </li>
        </ul>
    </body>
</html>
5.1.2.3 Déclaration de conformité

Ce schéma correspond à la conformité de type 1 de la spécification ITS.

Le schéma ajoute l'élément ITS suivant au schéma XHTML :

Le schéma ajoute les attributs ITS locaux suivants au schéma XHTML :

Vers la table des matières. 5.1.3 Utiliser NVDL pour intégrer ITS à XHTML

Comme vouz l'avez constaté dans la section précédente, il est parfois assez laborieux d'intégrer ITS à un vocabulaire existant en utilisant seulement la modularisation et les fonctions de personnalisation d'un langage de schéma particulier. Dans de telles situations, on peut utiliser le langage de schéma NVDL à la place.

Dans NVDL, on peut créer une sorte de « méta-schéma » qui définit comment combiner et fournir des règles supplémentaires pour des schémas existants. Un schéma NVDL peut s'utiliser de la même façon que des schémas écrits en d'autres langages, tels que les définitions DTD, RELAX NG ou XML Schema. On peut alors utiliser un tel schéma pour valider ses instances de document, ou de façon à être guidé par un éditeur XML lors de l'édition des documents. Le site NVDL.org fournit des informations supplémentaires à propos du langage. On y trouvera également une liste d'aplications qui gèrent le langage NVDL.

Ajouter du ITS au XHTML implique d'autoriser l'élément its:rules dans l'élément head et d'autoriser la présence des attributs locaux ITS sur tous les éléments XHTML existants.

Exemple 43 : Écriture NVDL pour XHTML avec ITS.
<?xml version="1.0" encoding="UTF-8"?>
<rules xmlns="http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0"
       startMode="xhtml">

  <!-- Validation starts here -->
  <mode name="xhtml">
    <!-- XHTML elements are validated against XHTML schema -->
    <namespace ns="http://www.w3.org/1999/xhtml">
      <validate schema="../xhtml-schemas/xhtml11.xsd">
        <!-- Inside head element its:rules element is allowed -->
        <context path="head" useMode="its-rules"/>
      </validate>
    </namespace>

    <!-- ITS attributes are validated against separate schema -->
    <namespace ns="http://www.w3.org/2005/11/its" match="attributes">
      <validate schema="its-attributes-for-xhtml.rng"/>
    </namespace>
  </mode>

  <!-- Handling of ITS markup in head is different 
       because its:rules should be allowed -->
  <mode name="its-rules">
    <namespace ns="http://www.w3.org/2005/11/its">
      <validate schema="its-rules.rng"/>   
    </namespace>
    <namespace ns="http://www.w3.org/2005/11/its" match="attributes">
      <validate schema="its-attributes-for-xhtml.rng"/>
    </namespace>
  </mode>
</rules>

[Code source de l'exemple]

L'écriture NVDL référence trois schémas. Un pour XHTML et deux supplémentaires pour ITS. Le premier schéma supplémentaire définit les attributs locaux nécessaires pour XHTML.

Exemple 44 : Schéma définissant les attributs locaux ITS appropriés pour XHTML.
<?xml version="1.0" encoding="UTF-8"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0">

  <!-- Include schema with all ITS building blocks -->  
  <include href="its.rng"/>
  
  <!-- Pull out only definitions of ITS attributes 
       which are useful for XHTML -->
  <start>
    <group>
      <ref name="its-att.translate.attributes"/>
      <ref name="its-att.locNote.attributes"/>
      <ref name="its-att.term.attributes"/>
      <optional>
        <ref name="its-att.version.attributes"/>
      </optional>
    </group>
  </start>
  
</grammar>

[Code source de l'exemple]

Le deuxième schéma supplémentaire définit l'élément its:rules.

Exemple 45 : Schéma définissant l'élément ITS its:rules.
<?xml version="1.0" encoding="UTF-8"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0">

  <!-- Include schema with all ITS building blocks -->  
  <include href="its.rng"/>

  <!-- Pull out only definition of its:rules element -->
  <start>
    <ref name="its-rules"/>
  </start>

</grammar>

[Code source de l'exemple]

5.1.3.1 Déclaration de conformité

Ce schéma correspond à la conformité de type 1 de la spécification ITS.

Le schéma ajoute l'élément ITS suivant au schéma XHTML :

Le schéma ajoute les attributs ITS locaux suivants au schéma XHTML :

Vers la table des matières. 5.1.4 Associer le balisage XHTML existant à ITS

Plusieurs structures (constructs) XHTML mettent en œuvre la même sémantique que certaines catégories de données ITS. En outre, certains attributs XHTML doivent être traduits, ce qui n'est pas le comportement par défaut pour les documents XML conformément aux caractéristiques de traductibilité par défaut dans ITS. Ces attributs doivent être identifiés comme nécessitant une traduction.

Un élément ITS rules peut résumer ces relations. Du fait que XHTML est largement répandu et couvre une grande quantité de documents existants, les règles définies ici ne sont peut-être pas optimales pour tout le monde.

Exemple 46 : Règles ITS externes pour des documents XHTML.
<its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0"
 xmlns:h="http://www.w3.org/1999/xhtml">

 <!-- special content. (See note 1) -->
 <its:translateRule selector="//h:script" translate="no"/>
 <its:translateRule selector="//h:style" translate="no"/>

 <!-- Normal translatable attributes -->
 <its:translateRule selector="//h:*/@abbr" translate="yes"/>
 <its:translateRule selector="//h:*/@accesskey" translate="yes"/>
 <its:translateRule selector="//h:*/@alt" translate="yes"/>

 <its:translateRule selector="//h:*/@prompt" translate="yes"/>
 <its:translateRule selector="//h:*/@standby" translate="yes"/>
 <its:translateRule selector="//h:*/@summary" translate="yes"/>
 <its:translateRule selector="//h:*/@title" translate="yes"/>

 <!-- The input element (Important: See note 2) -->
 <its:translateRule selector="//h:input/@value" translate="yes"/>
 <its:translateRule selector="//h:input[@type='hidden']/@value" translate="no"/>

 <!-- Non-translatable element (See note 3) -->

 <its:translateRule selector="//h:del" translate="no"/>
 <its:translateRule selector="//h:del/descendant-or-self::*/@*" translate="no"/>

 <!-- Often-used translatable meta content. -->
 <its:translateRule selector="//h:meta[@name='keywords']/@content"
          translate="yes"/>
 <its:translateRule selector="//h:meta[@name='description']/@content"
          translate="yes"/>

 <!-- Possible term (Important: See note 4) -->
 <its:termRule selector="//h:dt" term="yes"/>

 <!-- Bidirectional information -->
 <its:dirRule selector="//h:*[@dir='ltr']" dir="ltr"/>
 <its:dirRule selector="//h:*[@dir='rtl']" dir="rtl"/>
 <its:dirRule selector="//h:bdo[@dir='ltr']" dir="lro"/>
 <its:dirRule selector="//h:bdo[@dir='rtl']" dir="rlo"/>

 <!-- Elements within text -->
 <its:withinTextRule withinText="yes"
  selector="//h:abbr | //h:abbr | //h:br | //h:cite | //h:code | //h:dfn
  | //h:kbd | //h:q | //h:samp | //h:span | //h:strong | //h:var | //h:b | //h:em
  | //h:big | //h:hr | //h:i | //h:small | //h:sub | //h:sup | //h:tt | //h:del
  | //h:ins | //h:bdo | //h:img | //h:a | //h:font | //h:center | //h:s | //h:strike
  | //h:u | //h:isindex" />

</its:rules>

[Code source de l'exemple]

Notes supplémentaires à propos de ces règles :

  1. Les éléments script et style peuvent contenir du texte nécessitant une traduction mais leur contenu doit être respectivement analysé par un filtre de script et un filtre CSS. En fonction des capacités de votre outils de traduction, vous pouvez laissez ces éléments comme nécessitant une traduction ;

  2. L'attribut value de l'élément input peut nécessiter ou non une traduction, selon la façon d'utiliser l'élément. La décision de traduire ou non la valeur de cet attribut dépendra de son utilisation dans une instance donnée. Notez toutefois qu'il n'est habituellement pas souhaitable de traduire ces valeurs puisqu'elles servent souvent d'identificateurs aux scripts : changez la valeur de l'attribut et le script risque de ne plus fonctionner. Les valeurs de l'attribut value ne sont normalement pas vues par l'utilisateur d'une page web ;

  3. L'élément del signale du texte supprimé et son contenu n'est en principe pas traduit. Comme les attributs n'héritent pas des règles ITS des éléments et que cet élément peut contenir des éléments avec des attributs nécessitant une traduction, tels que l'attributs alt de l'élément img, vous devez :

    • a) définir cette règle après avoir établi dans quelle mesure la traduction touche les valeurs d'attributs ;
    • b) utiliser des règles telles que selector="//h:del/descendant-or-self::*/@*" pour écraser toute possibilité de traduction sur un attribut dans un élément del ou un de ses descendants.
  4. L'élément dt est défini par HTML comme un « terme de définition » (definition term) et peut donc être envisagé comme candidat à l'association avec la catégorie de données Terminologie ITS. Néanmoins, pour des raisons historiques, cet élément a eu beaucoup d'autres utilisations. L'association ou non de l'élément dt à la catégorie de données terminologique ITS dépendra de son utilisation dans une instance donnée.

Vers la table des matières. 5.2 ITS et TEI

Le format TEI (Text Encoding Initiative) [TEI] concerne les documents littéraires et linguistiques, et il sert le plus souvent pour des éditions numériques de documents imprimés existants. Il convient néanmoins également à l'écriture générale (general purpose writing). La version P5 de TEI se compose de 23 modules combinables au besoin.

Vers la table des matières. 5.2.1 Intégrer ITS à TEI

TEI tient en un seul document ODD, et ses personnalisations sont égalements écrites en tant que documents ODD. ODD (One Document Does it all) est un langage de programmation lettré (literate programming language) de l'initiative Text Encoding Initiative pour écrire des schémas XML. Ces documents sont traités par des feuilles de style XSLT pour faire un schéma sur mesure au niveau de l'utilisateur en XML DTD, XML Schema ou RELAX NG.

Les ajouts ITS impliquent deux changements à TEI :

  1. Autoriser la présence de l'élément rules dans la section de métadonnées TEI (l'en-tête teiHeader) ;

  2. Ajouter des attributs locaux ITS à l'ensemble d'attributs global TEI.

Les deux sont aisément réalisés en utilisant des techniques standards dans ODD.

Le corps de la personnalisation TEI+ITS se compose d'un élément schemaSpec qui liste les modules à inclure (cet exemple-ci en inclut six) :

Exemple 47 : Un élément schemaSpec avec les modules à inclure.
<schemaSpec ident="tei-its" start="TEI">
 <moduleRef key="header"/>
 <moduleRef key="core"/>
 <moduleRef key="tei"/>
 <moduleRef key="textstructure"/>
 <moduleRef key="namesdates"/>
 <moduleRef key="msdescription"/> 
 <!-- Etc. -->
</schemaSpec>

[Code source de l'exemple]

En plus, nous chargeons le schéma ITS (dans sa version RELAX NG XML, le format employé par TEI pour exprimer les modèles de contenu) et surchargeons la définition de la classe de contenu model.headerPart de TEI pour inclure l'élément ITS rules :

Exemple 48 : Inclusion de l'élément rules ITS dans le schéma TEI.
<moduleRef url="its.rng">
 <content xmlns:rng="http://relaxng.org/ns/structure/1.0">
 <rng:define name="model.headerPart" combine="choice">
  <rng:ref name="rules"/>
 </rng:define>
 </content>
</moduleRef>

[Code source de l'exemple]

La classe de contenu détermine quels éléments sont admis en sous-éléments de teiHeader. Enfin, nous changeons la définition de la classe d'attributs globale att.global pour référencer les attributs locaux ITS (obtenus du schéma ITS chargé auparavant) :

Exemple 49 : Ajout des attributs locaux ITS aux attributs globaux.
<classSpec ident="att.global" type="atts" mode="change">
 <attList>
  <attRef name="span.attributes"/>
 </attList>
</classSpec>

[Code source de l'exemple]

Lors du traitement, cette personnalisation produit un schéma qui autorise un balisage comme celui-ci :

Exemple 50 : Document valide par rapport à un schéma TEI+ITS.
<TEI xmlns:its="http://www.w3.org/2005/11/its" xmlns="http://www.tei-c.org/ns/1.0">
 <teiHeader>
  <fileDesc>
   <!-- details of the file -->
  </fileDesc>
  <rules xmlns="http://www.w3.org/2005/11/its" version="1.0"
   xmlns:t="http://www.tei-c.org/ns/1.0">
   <translateRule translate="no" selector="//t:body/t:p/@*"/>
   <translateRule translate="yes" selector="//t:body/t:p"/>
  </rules>
 </teiHeader>
 <text>
  <body>
   <p rend="normal">Hello <hi>world</hi>
   </p>
   <p rend="special">Goodbye</p>
   <p its:translate="no">This must not be translated</p>
  </body>
 </text>
</TEI>

[Code source de l'exemple]

Dans cet exemple, un ensemble d'éléments de règle est fourni dans l'en-tête pour donner les règles, et le corps du texte réalise un écrasement spécifique.

5.2.1.1 Déclaration de conformité

Ce schéma correspond à la conformité de type 1 de la spécification ITS.

Le schéma ajoute l'élément ITS suivant au schéma TEI :

Le schéma ajoute les attributs locaux ITS suivants au schéma TEI :

Vers la table des matières. 5.3 ITS et XML Spec

Le format XML Spec [XML Spec] est destiné aux versions de travail, aux notes, aux recommandations et à tous les autres types de document du W3C tombant dans la catégorie des rapports techniques. XML Spec est disponible dans les formats suivants : XML DTD, XML Schema et RELAX NG.

Vers la table des matières. 5.3.1 Intégration de ITS à XML Spec

Le texte ci-dessous prend la version 2.10 de XML Spec comme exemple et montre comment lui intégrer ITS. Cette version est disponible dans les formats DTD, XML Schema et RELAX NG.

Remarque : Dans l'activité Internationalization du W3C, une définition DTD d'une version modifiée de XML Spec 2.9 est utilisée pour la création des documents. Cette version a été mise à jour avec des déclarations de balisage ITS.

L'intégration de ITS à la définition DTD XML Spec utilise les fichiers xmlspec-its.dtd (le schéma XML Spec) et its.dtd (le schéma ITS). Pour réaliser l'intégration, les modifications suivantes de la définition DTD XML Spec ont été effectuées :

  1. Les définitions ITS externes sont intégrées via la nouvelle entité <!ENTITY % its SYSTEM "its.dtd"> et l'appel d'entité %its; ;

  2. L'entité XML Spec existante %local.common.att; a été modifiée. Elle inclut maintenant les déclarations %its.att.local.with-ns.attributes; et xmlns:its CDATA "http://www.w3.org/2005/11/its". La première autorise l'utilisation des attributs locaux ITS, la deuxième est nécessaire pour autoriser l'utilisation de l'espace de noms ITS dans la définition DTD ;

  3. L'entité XML Spec %header.mdl; définit le modèle de contenu de l'élément header. L'élément ITS its:rules a été ajouté comme dernier élément de ce modèle de contenu. On peut ainsi utiliser l'élément its:rules dans un document XML Spec ;

  4. Les éléments ITS its:ruby et its:span ont été ajouté à l'entité XML Spec %p.pcd.mix;. Il est ainsi possible de les utiliser comme éléments de type en ligne (inline elements) ;

L'intégration de ITS dans le schéma RELAX NG de XML Spec emploie les fichiers xmlspec-its.rnc (le schéma XML Spec) et its.rnc (le schéma ITS). Les modifications apportées au schéma RELAX NG obéissent aux mêmes motivations que pour la définition DTD décrite précédemment. Elles sont les suivantes :

  1. Les définitions ITS externes sont intégrées via la déclaration include "its.rnc" ;

  2. Le modèle (pattern) its-att.local.with-ns.attributes est appelé depuis le modèle local.common.att ;

  3. Le modèle its-rules est appelé depuis le modèle header.mdl ;

  4. Les modèles its-ruby et its-span sont appelés depuis le modèle p.pcd.mix.

L'intégration de ITS dans le schéma XML Schema de XML Spec emploie les fichiers xmlspec-its.xsd (le schéma XML Spec), its.xsd (le schéma ITS), xml.xsd (pour les declarations de l'espace de noms XML) et xlink.xsd (pour les déclarations de l'espace de noms XLink). Les modifications apportées au schéma XML Schema de XML Spec obéissent aux mêmes motivations que pour la définition DTD décrite précédemment. Elles sont les suivantes :

  1. Les définitions ITS externes sont intégrées via une déclaration <xs:import> ;

  2. Le groupe d'attributs its-att.local.with-ns.attributes est ajouté au groupe d'attributs common.att …

  3. La déclaration d'élément its:rules est ajoutée au groupe d'éléments header.mdl ;

  4. Les déclarations d'élément its:ruby et its:span sont ajoutées au groupe d'éléments p.pcd.mix.

L'exemple suivant montre un document XML Spec conforme au schémas XML Spec+ITS. L'élément its:translateRule sert à indiquer de ne pas traduire les éléments pour le code, les mots-clés et les exemples. L'élément w3c-doctype est également marqué comme non traduisible par du balisage ITS local.

Exemple 51 : Exemple de document XML Spec avec du balisage ITS.
<?xml version="1.0" encoding="UTF-8"?>
<spec xmlns:its="http://www.w3.org/2005/11/its">
    <header>
        <title>Best Practices for XML Internationalization</title>
        <w3c-designation>...</w3c-designation>
        <w3c-doctype its:translate="no">W3C Working Draft</w3c-doctype>
        <pubdate>
            <day>5</day>
            <month>December</month>
            <year>2007</year>
        </pubdate>
        <publoc>
            <loc href="..." >...</loc>
        </publoc>
        <latestloc>
            <loc href="...">...</loc>
        </latestloc>
        <prevlocs>
            <loc href="..."
                >...</loc>
        </prevlocs>
        <authlist>
            <author>
                <name>...</name>
                <affiliation>...</affiliation>
            </author>
        </authlist>
        <abstract>
            <p>This document provides a set of guidelines for ...</p>
        </abstract>
        <status>
            <p/>
        </status>
        <langusage>
            <language id="en">en</language>
        </langusage>
        <revisiondesc>
            <p>This is an updated version of this document.</p>
        </revisiondesc>
        <its:rules version="1.0">
            <its:translateRule selector="//code | //kw //eg" translate="no"/>
        </its:rules>
    </header>
    <body>
        <div1 id="idIntro">
            <head>Introduction</head>
            <p>This document is a complement  ...</p>
        </div1>
    </body>
    <back>
        <div1>
            <head>References</head>
        </div1>
        <inform-div1>
            <head>Acknowledgements</head>
        </inform-div1>
    </back>
</spec>

[Code source de l'exemple]

5.3.1.1 Déclaration de conformité

Les trois schémas XML Spec décrits ci-dessus correspondent à la conformité de type 1 de la spécification ITS.

Les éléments ITS suivants sont ajoutés :

Les attributs ITS locaux suivants sont ajoutés :

Vers la table des matières. 5.3.2 Associer le balisage XML Spec existant à ITS

Plusieurs structures XML Spec mettent en œuvre la même sémantique que certaines catégories de données ITS. En outre, certaines valeurs d'attributs XML Spec doivent être traduites, ce qui n'est pas le comportement par défaut pour les documents XML conformément aux caractéristiques de traductibilité par défaut dans ITS. Ces attributs doivent être identifiés comme nécessitant une traduction et certains éléments comme n'en nécessitant pas.

Remarque : Lorsque vous avez le choix entre employer une structure XML Spec et employer une structure ITS, utilisez la structure XML Spec pour vous assurer que les outils de traitement XML Spec fonctionnent correctement. Utilisez du balisage ITS local seulement si XML Spec n'offre aucun équivalent.

Un élément ITS its:rules externe peut résumer ces relations. Les règles définies ici sont juste des exemples et nécessiteront peut-être une adapatation pour une utilisation particulière.

Exemple 52 : Règles ITS externe pour des documents XML Spec.
<its:rules xmlns:its="http://www.w3.org/2005/11/its"
 xmlns:xlink="http://www.w3.org/1999/xlink" version="1.0">
 
 <!-- Translatable attributes -->
 <its:translateRule selector="//graphic/@alt | //table/@summary | //term
  | //termdef | //key-term" translate="yes"/>

 <!-- Non-translatable elements/attributes -->
 <its:translateRule translate="no"
  selector="//version | // w3c-designation | w3c-doctype | //publoc | //altlocs
  | //prevlocs | //latestloc | //errataloc | //preverrataloc | //translationloc
  | //authlist | //author | //name | //affiliation | //email | //langusage
  | //language | //graphic | //proto | //arg | //scrap | //prodgroup | //prod
  | //lhs | //rhs | //wfc | //vc | //constraint | //bnf | //prodrecap
  | //interface | //module | //reference | //typedef | // struct | //component
  | //union | //case | //enum | //enumerator | //sequence | //constant
  | //exception | //attribute | //method | //parameters | //param | //returns
  | //raises | //typename | //att | //attval | //bibref | //code | //el | //kw
  | //nt | //var | //xnt | //key-term"/>

 <!-- Possible terms -->
 <its:termRule selector="//label | //def" term="yes"/>

 <!-- Elements within text -->
 <its:withinTextRule withinText="yes" selector="//abbr | //att | //attval
  | //code | //eg | //emph | //ins | //kw | //loc | //note | //qterm
  | //phrase | //quote"/>
 <its:withinTextRule withinText="nested" selector="//footnote
  | //termdef | //its:ruby"/>

</its:rules>

[Code source de l'exemple]

Vers la table des matières. 5.4 ITS et DITA

DITA (Darwin Information Typing Architecture) [DITA 1.0] est une architecture fondée sur XML pour créer, produire et livrer de l'information intelligible (readable information) sous forme de sujets typés discrets.

Vers la table des matières. 5.4.1 Intégration de ITS à DITA

DITA offre par défaut quelques caractéristiques ITS (cf. la section 5.4.2 Associer le balisage DITA existant à ITS pour plus de renseignements à ce sujet). Néanmoins, dans certains cas, on peut vouloir autoriser l'utilisation du balisage ITS directement dans ses documents DITA. Par exemple, l'attribut its:locNote ou l'élément its:rules. DITA fournit un moyen de créer une spécialisation de domaine (domain specialization) fondée sur l'élément foreign et des points d'extension d'attributs.

Ainsi on peut étendre la définition DTD Concept DITA comme suit :

Créer d'abord deux fichiers pour la spécialisation de domaine ITS. Le premier (itsDomain.ent) contient les définitions d'entités qui seront utilisées dans la définition DTD étendue.

Exemple 53 : Contenu du fichier itsDomain.ent.
<?xml version="1.0" encoding="UTF-8"?>
<!ENTITY % its-d-foreign "its"           >
<!ENTITY   its-d-att     "(topic its-d)" >

[Code source de l'exemple]

Le deuxième fichier (itsDomain.mod) contient la définition de l'élément dans lequel se placera le balisage ITS.

Exemple 54 : Contenu du fichier itsDomain.mod.
<?xml version="1.0" encoding="UTF-8"?>
<!-- declaration for the specialized wrapper and alternate element -->
<!ENTITY % its "its">

<!-- definition for the specialized wrapper and alternate element -->
<!ELEMENT its ((%its-rules;) | (%its-ruby;)) >
<!ATTLIST its %global-atts;
          class CDATA "+ topic/foreign its-d/its ">

[Code source de l'exemple]

On peut alors adapter le fichier concept.dtd pour prendre en compte le nouveau domaine.

Exemple 55 : La définition DTD Concept DITA modifiée pour ITS.

Inclure les entités du domaine ITS à la fin de la section des déclarations d'entités de domaine (Domain Entities Declarations) :

<!ENTITY % its-d-dec SYSTEM "itsDomain.ent" >
  %its-d-dec;

Inclure le type de document et l'espace de noms ITS :

<!ENTITY % its-def SYSTEM  "its.dtd" >
  %its-def;
<!ENTITY % its-d-namespace "xmlns:its CDATA #FIXED 'http://www.w3.org/2005/11/its'">
<!ENTITY % props-attribute-extensions  ""                            >
<!ENTITY % base-attribute-extensions   "%its-d-namespace;
  %att.version.attributes;
  %att.locNote.attributes;" >

Définir l'élément d'extension à la fin de la section d'extension de domaine (Domain Extension) :

<!ENTITY % foreign "foreign | %its-d-foreign;" >

Modifier la liste des domaines inclus dans l'entité included-domains :

<!ENTITY included-domains
  "&ui-d-att; &hi-d-att; &pr-d-att; &sw-d-att;
  &ut-d-att; &indexing-d-att; &its-d-att;" >

Inclure le module du domaine ITS à la fin de la section d'intégration des éléments de domaine (Domain Element Integration) :

<!ENTITY % its-d-def SYSTEM "itsDomain.mod" >
  %its-d-def;

[Code source de l'exemple]

Tous ces changements permettent d'inclure un nouvel élément its en divers endroits du document DITA et d'employer des structures définies par ITS là où la gestion DITA serait déficiente, tel que pour du texte ruby. Cela permet aussi d'employer une sélection d'attributs définis par ITS en complément de ce que DITA fournit déjà.

Exemple 56 : Document DITA avec ITS.

Ce document DITA inclut les structures ITS suivantes :

  • Un élément its:rules est ajouté à l'élément prolog pour indiquer, dans le cadre du document, que le contenu des éléments uicontrol n'est pas traduisible ;

  • Le deuxième élément p inclut un attribut its:locNote qui s'applique à son contenu 

  • Le dernier paragraphe inclut un élément its:ruby.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
 "dtd/itsConcept.dtd">
<concept id="DITAwithITS" xml:lang="en"
 xmlns:its="http://www.w3.org/2005/11/its" its:version="1.0">
 <title>Using ITS in DITA</title>
 <prolog>
  <its>
   <its:rules>
    <its:translateRule selector="ui" translate="no"/>
   </its:rules>
  </its>
 </prolog>
 <conbody xml:lang="ja">
  <p>Example of applying global rules: Normal text with
   <uicontrol>non-translatable text</uicontrol>.</p>
  <p its:locNote="Localization note">Text where the note applies.</p>
  <p>Example of ruby text:
   <ph xml:lang="ja">この本は <its><its:ruby>
    <its:rb>慶応義塾大学</its:rb>
    <its:rp>(</its:rp>
    <its:rt>けいおうぎじゅくだいがく</its:rt>
    <its:rp>)</its:rp>
   </its:ruby></its>/の歴史を説明するものです。</ph>
  </p>
 </conbody>
</concept>

[Code source de l'exemple]

5.4.1.1 Déclaration de conformité

Ce schéma correspond à la conformité de type 1 de la spécification ITS.

Le schéma ajoute l'élément ITS suivant à la définition DTD DITA :

Le schéma ajoute les attributs locaux ITS suivants à la définition DTD DITA :

Vers la table des matières. 5.4.2 Associer le balisage DITA existant à ITS

Plusieurs catégories de données ITS sont déjà mises en œuvre dans DITA. Par exemple, DITA propose un attribut translate qui offre la même fonctionnalité que l'attribut its:translate.

De la même façon que pour les autres formats, ces caractéristiques existantes peuvent être associées à des catégtories de données ITS, afin que les outils compatibles avec ITS puisse traiter sans heurts les documents sources DITA.

Remarque : Lorsque vous avez le choix entre employer une structure DITA et employer une structure ITS pour exprimer la même chose, utilisez la structure DITA pour vous assurer que les processeurs DITA fonctionnent correctement. Utilisez du balisage ITS local seulement si DITA n'offre aucun équivalent.

Exemple 57 : Associer du balisage DITA à ITS.
<?xml version="1.0"?>
<!-- Possible default ITS rules for DITA -->
<its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">

 <!-- Translatable attribute (some are deprecated) -->
 <its:translateRule selector="//image/@alt" translate="yes"/>
 <its:translateRule selector="//lq/@reftitle" translate="yes"/>
 <its:translateRule selector="//note/@othertype" translate="yes"/>
 <its:translateRule selector="//object/@standby" translate="yes"/>
 <its:translateRule selector="//othermeta/@content" translate="yes"/>
 <its:translateRule selector="//state/@value" translate="yes"/>
 <its:translateRule selector="//map/@title" translate="yes"/>
 <its:translateRule selector="//topicref/@navref" translate="yes"/>
 <its:translateRule selector="//topicgroup/@navtitle" translate="yes"/>
 <its:translateRule selector="//topichead/@navtitle" translate="yes"/>
 <its:translateRule selector="//data/@label" translate="yes"/>

 <!-- Non-translatable elements -->
 <its:translateRule selector="//draft-comment//*" translate="no"/>
 <its:translateRule selector="//draft-comment/descendant-or-self::*/@*"
  translate="no"/>
 <its:translateRule selector="//required-cleanup//*" translate="no"/>
 <its:translateRule selector="//required-cleanup/descendant-or-self::*/@*"
  translate="no"/>
 <its:translateRule selector="//coords" translate="no"/>
 <its:translateRule selector="//shape" translate="no"/>

 <!-- Translatability flags -->
 <its:translateRule selector="//*[@translate='no']" translate="no"/>
 <its:translateRule selector="//*[@translate='no']/descendant-or-self::*/@*"
  translate="no"/>
 <its:translateRule selector="//*[@translate='yes']" translate="yes"/>

 <!-- Directionality flags -->
 <its:dirRule selector="//*[dir='ltr']" dir="ltr"/>
 <its:dirRule selector="//*[dir='rtl']" dir="rtl"/>
 <its:dirRule selector="//*[dir='lro']" dir="lro"/>
 <its:dirRule selector="//*[dir='rlo']" dir="rlo"/>

 <!-- Elements within text (inline) -->
 <its:withinTextRule withinText="yes"
  selector="//boolean | //cite | //itemgroup | //keyword | //ph | //q |
   //state | //term | //tm | //xref | //b | //i | //sub | //sup | //tt |
   //u | //apiname | //codeph | //delim | //fragref | //kwd | //oper |
   //option | //parmname | //repsep | //sep | //synnoteref | //synph |
   //var | //cmdname | //filepath | //msgnum | //msgph | //systemoutput |
   //userinput | //varname | //menucascade | //shortcut | //uicontrol |
   //wintitle | //coords | //shape" />

 <!-- The keyword elements within keywords are sub-flow, no in-line -->
 <its:withinTextRule withinText="nested" selector="//keywords/keyword" />

 <!-- Elements within text (subflow) -->
 <its:withinTextRule withinText="nested"
  selector="//draft-comments | //required-cleanup | //alt | //fn |
  //indexterm" />   

 <!-- Terminology -->
 <its:termRule selector="//term | //dt | //termindex" term="yes" />

</its:rules>

[Code source de l'exemple]

Les déclarations ci-dessus couvrent plusieurs versions de DITA.

Vers la table des matières. 5.5 ITS et GladeXML

Glade [Glade] est un système de construction d'interface utilisateur pour GTK+ et Gnome. Il emploie des fichiers XML (GladeXML) pour stocker les composants de l'interface d'utilisateur. La bibliothèque a été portée sur plusieurs plateformes et elle offre des liaisons (bindings) dans plusieurs langages de programmation.

Exemple 58 : Exemple de document GladeXML.
<?xml version="1.0" standalone="no"?><!--*- mode: xml -*-->
<glade-interface>
 <widget class="GtkWindow" id="main_window">
  <property name="visible">True</property>
  <property name="title" translatable="yes">Glade Text Editor</property>
  <property name="type">GTK_WINDOW_TOPLEVEL</property>
  <property name="window_position">GTK_WIN_POS_NONE</property>
  <property name="modal">False</property>
  <property name="default_width">600</property>
  <property name="default_height">450</property>
  <property name="resizable">True</property>
  <property name="destroy_with_parent">False</property>
  <property name="decorated">True</property>
  <property name="skip_taskbar_hint">False</property>
  <property name="skip_pager_hint">False</property>
  <property name="type_hint">GDK_WINDOW_TYPE_HINT_NORMAL</property>
  <property name="gravity">GDK_GRAVITY_NORTH_WEST</property>
  <property name="focus_on_map">True</property>
  <property name="urgency_hint">False</property>
  <signal name="delete_event" handler="on_main_window_delete_event"/>
  <child>
   <widget class="GtkVBox" id="vbox1">
    <property name="visible">True</property>
    <property name="homogeneous">False</property>
    <property name="spacing">0</property>
    <child>
     <widget class="GtkHandleBox" id="handlebox2">
      <property name="visible">True</property>
      <property name="shadow_type">GTK_SHADOW_OUT</property>
      <property name="handle_position">GTK_POS_LEFT</property>
      <property name="snap_edge">GTK_POS_TOP</property>
      <child>
       <widget class="GtkMenuBar" id="menubar1">
        <property name="visible">True</property>
        <property name="pack_direction">GTK_PACK_DIRECTION_LTR</property>
        <property name="child_pack_direction">GTK_PACK_DIRECTION_LTR</property>
        <child>
         <widget class="GtkMenuItem" id="File">
          <property name="visible">True</property>
          <property name="label" translatable="yes">_File</property>
          <property name="use_underline">True</property>
          <child>
           <widget class="GtkMenu" id="File_menu">
            <child>
             <widget class="GtkImageMenuItem" id="Open">
              <property name="visible">True</property>
              <property name="label">gtk-open</property>
              <property name="use_stock">True</property>
              <signal name="activate" handler="on_Open_activate"/>
             </widget>
            </child>
            <child>
             <widget class="GtkImageMenuItem" id="Exit">
              <property name="visible">True</property>
              <property name="label">gtk-quit</property>
              <property name="use_stock">True</property>
              <signal name="activate" handler="on_Exit_activate"/>
             </widget>
            </child>
           </widget>
          </child>
         </widget>
        </child>
       </widget>
      </child>
     </widget>
     <packing>
      <property name="padding">0</property>
      <property name="expand">False</property>
      <property name="fill">True</property>
     </packing>
    </child>
   </widget>
  </child>
 </widget>
</glade-interface>

[Code source de l'exemple]

Vers la table des matières. 5.5.1 Intégration de ITS à GladeXML

Le contenu des fichiers GladeXML est composé essentiellement de données à ne pas traduire : des propriétés de machins (widgets) de l'interface d'utilisateur. Le contenu textuel est limité aux titres, aux étiquettes (labels) et quelques autres types de chaînes.

GladeXML n'offre aucune gestion pour quelques caractéristiques ITS mais pas pour toutes. Bien qu'il serait techniquement faisable de permettre l'utilisation de plus de balisage ITS dans les ressources GladeXML, il n'y a pas grand intérêt à le faire ici car ces ressources sont étroitement liées aux éditeurs et compileurs Glade qu'il faudrait modifier également.

Vers la table des matières. 5.5.2 Associer le balisage GladeXML existant à ITS

GladeXML propose un attribut translatable qui offre la même fonctionnalité que l'attribut its:translate. L'attribut comments peut également être associé aux notes de localisation.

Comme pour les autres formats, les caractéristiques existantes de GladeXML peuvent être associées aux catégories de données ITS en utilisant des règles globales, afin que les outisl compatibles avec ITS puissent traiter sans heurts les documents sources GladeXML.

Exemple 59 : Associer le balisage GladeXML à ITS.
<its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
 <!-- ITS rules for Glade 2.0, based on http://glade.gnome.org/glade-2.0.dtd -->
 <its:translateRule selector="/glade-interface" translate="no"/>
 <its:translateRule selector="//*[@translatable='yes']" translate="yes"/>
 <its:translateRule selector="//atkaction/@description" translate="yes"/>
 <its:locNoteRule selector="//*[@translatable='yes']"
  locNoteType="description" locNotePointer="@comments"/>
</its:rules>

[Code source de l'exemple]

Vers la table des matières. 5.6 ITS et DocBook

DocBook est un schéma XML d'utilisation générale qui convient tout particulièrement aux livres et aux documents à propos de matériels informatiques et de logiciels (mais nullement limité à ces applications). DocBook est entretenu par le comité technique DocBook de OASIS.

Vers la table des matières. 5.6.1 Intégration de ITS à DocBook

Le schéma DocBook V5.0 est tenu comme un schéma très modulaire et aisément personnalisable écrit en RELAX NG [RELAX NG 1.0]. Les techniques générales pour la personnalisation du schéma sont décrites dans [DocBook V5.0 HOWTO].

Les ajouts ITS impliquent les modifications suivante du schéma DocBook :

  1. Ajouter les attributs locaux ITS à tous les éléments DocBook existants.

    Les attributs locaux ITS ne sont pas tous ajoutés au schéma, car DocBook dispose déjà de moyens propres pour indiquer la directionnalité du texte. Ce balisage existant devrait être associé aux catégories de données ITS en utilisant l'élément its:rules. Cf. la section 5.6.2 Associer le balsiage DocBook existant à ITS ;

  2. Autoriser l'élément its:rules dans l'élément DocBook info, qui est un conteneur général de métadonnées ;

  3. Autoriser l'élément its:ruby comme élément de type en ligne presque partout où il y a du texte ordinaire (plain text).

Exemple 60 : Personnalisation du schéma DocBook.
# This schema integrates ITS markup (http://www.w3.org/TR/its/) 
# into DocBook schema (http://docbook.org)
#
# This schema conforms to Conformance Type 1 defined in
# http://www.w3.org/TR/its/#conformance-product-schema
# 
# Schema adds the following ITS elements into DocBook schema: 
#  * rules
#  * ruby
#
# Schema adds the following local ITS attributes into DocBook schema:
#  * translate
#  * locNote
#  * locNoteType
#  * locNoteRef
#  * term
#  * termInfoRef

# Namespace declarations for DocBook, ITS and HTML
# (HTML is used internally in DocBook schema)  
namespace db = "http://docbook.org/ns/docbook"
namespace its = "http://www.w3.org/2005/11/its"
namespace html = "http://www.w3.org/1999/xhtml"

# Include base DocBook schema
include "docbook.rnc"
{
   # Exclude ITS markup from "wildcard" element
   db._any =
      element * - (db:* | html:* | its:*) {
         (attribute * { text }
          | text
          | db._any)*
      }
}

# Include base ITS schema
include "its.rnc"

# Define pattern for local ITS attributes
db.its.attributes = 
   its-att.translate.attributes?
   & its-att.locNote.attributes?
   & its-att.term.attributes?
   & its-att.version.attributes?

# Add local ITS attributes to all DocBook elements
db.common.base.attributes &= db.its.attributes

# Allow its:rules inside info element
db.info.extension |= its-rules

# Allow Ruby markup almost everywhere
db.ubiq.inlines |= its-ruby

[Code source de l'exemple]

Pour votre convenance, il existe également un schéma « aplati » (flattened) stocké en un seul fichier.

  • dbits.rnc (schéma RELAX NG à syntaxe compacte en un seul fichier)

  • dbits.rng (schéma RELAX NG en un seul fichier)

Il n'est pas nécessaire d'ajouter l'élément its:span puisque DocBook fournit un élément similaire appelé phrase pouvant servir à rattacher des attributs locaux ITS à un morceau de texte arbitraire.

L'exemple suivant montre un échantillon d'article DocBook conforme au schéma DocBook+ITS. L'élément its:translateRule est utilisé pour indiquer de ne pas traduire les noms de fonction (marqués avec l'élément function). Le premier paragraphe est également marqué à ne pas traduire avec du balisage ITS local.

Exemple 61 : Échantillon de document DocBook avec balisage ITS.
<?xml version="1.0" encoding="UTF-8"?>
<article xmlns="http://docbook.org/ns/docbook" 
         xmlns:its="http://www.w3.org/2005/11/its" 
         xmlns:db="http://docbook.org/ns/docbook" 
         version="5.0" xml:lang="en">
  <info>
    <title>Sample article</title>
    <its:rules version="1.0">
      <its:translateRule translate="no" selector="//db:function"/>
    </its:rules>
  </info>
  <para its:translate="no">Non-translatable content</para>
  <section>
    <title>Sample section</title>
    <para>You can delete file using <function>unlink()</function>
     function.</para>
  </section>
</article>

[Code source de l'exemple]

5.6.1.1 Déclaration de conformité

Ce schéma correspond à la conformité de type 1 de la spécification ITS.

Le schéma ajoute les éléments ITS suivants au schéma DocBook :

Le schéma ajoute les attributs locaux ITS suivants au DocBook schema:

Vers la table des matières. 5.6.2 Associer le balisage DocBook existant à ITS

Plusieurs structures DocBook mettent en œuvre la même sémantique que des catégories de données ITS. En outre, certains attributs DocBook ont des valeurs qu'il faudrait traduire, ce qui n'est pas le comportement par défaut pour les documents XML conformément aux caractéristiques par défaut dans ITS. Ces attributs doivent être identifiés comme nécessitant une traduction.

Remarque : Lorsque vous avez le choix entre employer une structure DocBook ou employer une structure ITS pour exprimer la même chose, utilisez la structure DocBook pour vous assurer que les outils de traitement DocBook fonctionnent correctement. Utilisez du balisage ITS local seulement si DocBook n'offre aucun équivalent.

Un élément ITS its:rules externe peut résumer ces relations. Du fait de l'utilisation répandue et variée de DocBook, les règles définies ici sont juste des exemples qui nécessiteront peut-être une adaptation sur mesure pour une utilisation spécifique.

Exemple 62 : Règles ITS externes pour des documents DocBook.
<its:rules xmlns:its="http://www.w3.org/2005/11/its" 
      xmlns:db="http://docbook.org/ns/docbook"
      xmlns:xlink="http://www.w3.org/1999/xlink"
      version="1.0">

 <!-- Translatable attributes -->
 <its:translateRule selector="//db:table/@summary" translate="yes"/>
 <its:translateRule selector="//db:*/@xlink:title" translate="yes"/>
 <its:translateRule selector="//db:*/@xreflabel" translate="yes"/>
 <its:translateRule selector="//db:*/@label" translate="yes"/>

 <!-- Non-translatable elements/attributes -->
 <its:translateRule translate="no" selector="//db:*[@revisionflag = 'deleted']"/>
 <its:translateRule translate="no" selector="//db:*[@revisionflag = 'deleted']//@*"/>
 <its:translateRule translate="no"
          selector="//db:abbr
               | //db:author 
               | //db:classname 
               | //db:command 
               | //db:constant 
               | //db:date
               | //db:rédacteur 
               | //db:email 
               | //db:envar 
               | //db:errorcode 
               | //db:exceptionname 
               | //db:filename 
               | //db:function 
               | //db:initializer 
               | //db:interfacename 
               | //db:markup 
               | //db:methodname 
               | //db:modifier 
               | //db:ooclass 
               | //db:ooexception 
               | //db:oointerface 
               | //db:option 
               | //db:parameter 
               | //db:person 
               | //db:personname 
               | //db:productnumber 
               | //db:property
               | //db:returnvalue 
               | //db:symbol 
               | //db:tag 
               | //db:type 
               | //db:uri 
               | //db:varname"/>

 <!-- Possible terms -->
 <its:termRule selector="//db:glossterm" term="yes"/>
 <its:termRule selector="//db:firstterm" term="yes"/>
 <its:termRule selector="//db:abbrev"    term="yes"/>
 <its:termRule selector="//db:abbr"   term="yes"/>

 <!-- Bidirectional information -->
 <its:dirRule selector="//db:*[@dir='ltr']" dir="ltr"/>
 <its:dirRule selector="//db:*[@dir='rtl']" dir="rtl"/>
 <its:dirRule selector="//db:*[@dir='lro']" dir="lro"/>
 <its:dirRule selector="//db:*[@dir='rlo']" dir="rlo"/>

 <!-- Elements within text -->
 <its:withinTextRule withinText="yes"
           selector="//db:abbrev 
                | //db:accel 
                | //db:abbr 
                | //db:application 
                | //db:author 
                | //db:citation  
                | //db:citebiblioid 
                | //db:citerefentry 
                | //db:citetitle 
                | //db:classname 
                | //db:code 
                | //db:command 
                | //db:computeroutput 
                | //db:constant 
                | //db:database 
                | //db:date 
                | //db:rédacteur 
                | //db:email 
                | //db:emphasis 
                | //db:envar 
                | //db:errorcode 
                | //db:errorname 
                | //db:errortext 
                | //db:errortype 
                | //db:exceptionname 
                | //db:filename 
                | //db:foreignphrase 
                | //db:function 
                | //db:guibutton 
                | //db:guiicon 
                | //db:guilabel 
                | //db:guimenu 
                | //db:guimenuitem 
                | //db:guisubmenu 
                | //db:hardware 
                | //db:initializer 
                | //db:interfacename 
                | //db:jobtitle 
                | //db:keycap 
                | //db:keycode 
                | //db:keycombo 
                | //db:keysym 
                | //db:link 
                | //db:literal 
                | //db:markup 
                | //db:menuchoice 
                | //db:methodname 
                | //db:modifier 
                | //db:mousebutton 
                | //db:olink
                | //db:ooclass 
                | //db:ooexception 
                | //db:oointerface 
                | //db:option 
                | //db:optional 
                | //db:org 
                | //db:orgname 
                | //db:package 
                | //db:parameter 
                | //db:person 
                | //db:personname 
                | //db:phrase 
                | //db:productname 
                | //db:productnumber 
                | //db:prompt 
                | //db:property
                | //db:quote 
                | //db:replaceable 
                | //db:returnvalue 
                | //db:shortcut 
                | //db:subscript 
                | //db:superscript 
                | //db:symbol 
                | //db:systemitem 
                | //db:tag 
                | //db:token 
                | //db:trademark 
                | //db:type 
                | //db:uri 
                | //db:userinput
                | //db:varname 
                | //db:wordasword"/>

 <its:withinTextRule withinText="nested"
           selector="//db:alt 
                | //db:footnote 
                | //db:remark 
                | //db:indexterm 
                | //db:primary 
                | //db:secondary 
                | //db:tertiary"/>

</its:rules>

[Code source de l'exemple]

Vers la table des matières. A Références (non normatif)

BCP 47
Addison Phillips et Mark Davis, rédacteurs. Étiquettes pour l'identification des langues. Best Current Practice 47, septembre 2006. Disponible à http://www.rfc-editor.org/rfc/bcp/bcp47.txt
Bidi in X/HTML
Richard Ishida, rédacteur. Pratiques exemplaires d'internationalisation — Traitement des écritures de droite à gauche dans les contenus XHTML et HTML. Version de travail du W3C, 6 juin 2007. Disponible à http://www.w3.org/TR/2007/WD-i18n-html-tech-bidi-20070606/. La dernière version est disponible à http://www.w3.org/TR/i18n-html-tech-bidi/.
CharMod
Martin J. Dürst, François Yergeau, Richard Ishida, Misha Wolf, Tex Texin, rédacteurs. Modèle de caractères pour le Web 1.0 — Les fondamentaux. Recommandation du W3C, 15 février 2005. Disponible à http://www.w3.org/TR/2005/REC-charmod-20050215/. La dernière version est disponible à http://www.w3.org/TR/charmod/.
DITA 1.0
Michael Priestley, JoAnn Hackos, et. al., rédacteurs. OASIS Darwin Information Typing Architecture (DITA) Language Specification v1.0. Standard OASIS, 9 mai 2005. Disponible à http://www.oasis-open.org/committees/download.php/15316/dita10.zip.
DocBook V5.0 HOWTO
Jirka Kosek, Norman Walsh et Dick Hamilton. DocBook V5.0: The Transition Guide. Disponible à http://docbook.org/docs/howto/.
Glade
Glade - a User Interface Builder for GTK+ and GNOME. The GNOME Foundation. Disponible à http://glade.gnome.org/.
ITS
Christian Lieske et Felix Sasaki, rédacteurs. Jeu de balises d'internationalisation (ITS) version 1.0. Recommandaton du W3C, 3 avril 2007. Disponible à http://www.w3.org/TR/2007/REC-its-20070403/. La dernière version est disponible à http://www.w3.org/TR/its/.
ITS REQ
Yves Savourel, rédacteur. Exigences du balisage d'internationalisation et de localisation. Version de travail du W3C, 18 mai 2006. Disponible à http://www.w3.org/TR/2006/WD-itsreq-20060518/. La dernière version est disponible à http://www.w3.org/TR/itsreq/.
NVDL
Information technology -- Document Schema Definition Languages (DSDL) -- Part 4: Namespace-based Validation Dispatching Language (NVDL). International Organization for Standardization (ISO) ISO/IEC 19757-4:2003.
RELAX NG 1.0
Information technology – Document Schema Definition Language (DSDL) – Part 2: Regular-grammar-based validation – RELAX NG. International Organization for Standardization (ISO) ISO/IEC 19757-2:2003.
Ruby Annotation
Marcin Sawicki, Michel Suignard, Masayasu Ishikawa, et al. rédacteurs. L'annotation ruby. Recommandation du W3C, 31 mai 2001 Disponible à http://www.w3.org/TR/2001/REC-ruby-20010531/. La dernière version est disponible à http://www.w3.org/TR/ruby/.
TEI
Lou Burnard et Syd Bauman, rédacteurs. Text Encoding Initiative Guidelines development version (P5). TEI Consortium, Charlottesville, Virginia, USA, Text Encoding Initiative.
Unicode in XML
Martin Dürst et Asmus Freytag. Unicode dans XML et les autres langages de balisage. Note de groupe de travail du W3C, 16 mai 2007, Unicode Technical report #20. La dernière version est disponible à http://www.w3.org/TR/unicode-xml/.
XHTML 1.0
Steven Pemperton et al., rédacteurs. XHTML™ 1.0 — Le langage de balisage hypertexte extensible (deuxième édition). Recommandation du W3C, 26 janvier 2000, révisée le 1 août 2002. Disponible à http://www.w3.org/TR/2002/REC-xhtml1-20020801/. La dernière version est disponible à http://www.w3.org/TR/xhtml1/.
XHTMLMod1.1
Daniel Austin et al., rédacteurs. XHTML™ Modularization 1.1. Version de travail du W3C, 5 juillet 2006. Disponible à http://www.w3.org/TR/2006/WD-xhtml-modularization-20060705/. La dernière version est disponible à http://www.w3.org/TR/xhtml-modularization/.
XInclude 1.0
Jonathan Marsh, David Orchard et Daniel Veillard, rédacteurs. Inclusions XML (XInclude) version 1.0 (deuxième édition). Recommandation du W3C, 15 novembre 2006. Disponible à http://www.w3.org/TR/2006/REC-xinclude-20061115/. La dernière version est disponible à http://www.w3.org/TR/xinclude/.
XLIFF 1.2
Yves Savourel et al., rédacteurs. XLIFF Version 1.2. OASIS Committee Specification, 24 juillet 2007. Disponible à http://docs.oasis-open.org/xliff/v1.2/cs02/xliff-core.html. La dernière version est disponible à http://docs.oasis-open.org/xliff/xliff-core/xliff-core.html.
XLink 1.0
Steve DeRose, Eve Maler et David Orchard, rédacteurs. Langage de liaison XML 1.0. Recommandation du W3C, 27 juin 2001. Disponible à http://www.w3.org/TR/2001/REC-xlink-20010627/. La dernière version est disponible à http://www.w3.org/TR/xlink/.
xml:id
Jonathan Marsh, Daniel Veillard et Norman Walsh, rédacteurs. xml:id version 1.0. Recommandation du W3C, 9 septembre 2005. Disponible à http://www.w3.org/TR/2005/REC-xml-id-20050909/. La dernière version est disponible à http://www.w3.org/TR/xml-id/.
XML Names
Tim Bray, Dave Hollander et Andrew Layman, rédacteurs. Espaces de noms dans XML. Recommandation du W3C, 14 janvier 1999. Disponible à http://www.w3.org/TR/1999/REC-xml-names-19990114/. La dernière version est disponible à http://www.w3.org/TR/REC-xml-names/.
XML Spec
Le schéma et les feuilles de style XML Spec. Disponible à http://www.w3.org/2002/xmlspec/.

Vers la table des matières. B Remerciements (non normatif)

Ce document a été développé avec les contributions importantes des membres passés et présents du groupe de travail : Bartosz Bogacki (expert invité du W3C), Martin Dürst (expert invité du W3C), Tim Foster, Richard Ishida (W3C/ERCIM), Masaki Itagaki, Jirka Kosek (expert invité du W3C), Christian Lieske (SAP AG), Sebastian Rahtz (expert invité du W3C), Felix Sasaki (W3C/Keio), Yves Savourel (ENLASO Corporation), Diane Stoick (The Boeing Company), Najib Tounsi (École Mohammadia d'Ingénieurs Rabat (EMI)) et Andrzej Zydron.

À la date de publication, les membres du groupe de travail étaient les suivants : Bartosz Bogacki (expert invité du W3C), Damien Donlon (Sun Microsystems, Inc.), Martin Dürst (expert invité du W3C), Poonam Gupta (Centre for Development of Advanced Computing (CDAC)), Richard Ishida (W3C/ERCIM), Jirka Kosek (expert invité du W3C), Christian Lieske (SAP AG), Sebastian Rahtz (expert invité du W3C), Francois Richard (HP), Goutam Saha (Centre for Development of Advanced Computing (CDAC)), Felix Sasaki (W3C/Keio), Yves Savourel (ENLASO Corporation), Diane Stoick (The Boeing Company) et Najib Tounsi (École Mohammadia d'Ingénieurs Rabat (EMI)).