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 exemplaire | Mise en œuvre en tant que nouvelle fonction | Traitement 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 :
Y penser à deux fois avant de créer son propre schéma. Envisagez sérieusement d'utiliser des formats existants tels que
DITA, DocBook, ODF (Open Document Format),
OOXML (Office Open XML), XUL (XML User Interface Language),
UBL (Universal Business Language), etc. Ces formats intègrent déjà beaucoup d'idées utiles ;
Vérifier soigneusement si un format existant offre une capacité de modification intégrée. DocBook et DITA,
par exemple, ont leur propre ensemble de fonctions pour adapter leur format à des besoins particuliers ;
Les mécanismes de modification disponibles dépendront du langage de schéma (DTD, XML Schema, RELAX NG, etc.)
Par exemple, il est difficile d'obtenir une modularisation des schémas fondée sur des espaces de noms avec les définitions DTD ;
NVDL est un exemple de langage de méta-schéma conçu spécialement pour intégrer plusieurs vocabulaires existants
en un seul vocabulaire XML sans qu'il soit nécessaire de connaître les détails des schémas sources.
Ainsi, avec NVDL, on peut habituellement créer un schéma pour des documents composites plus facilement qu'avec d'autres
technologies de schéma ;
Chaque langage de schéma fournit différentes méthodes pour créer ou modifier des schémas existants. Les mécanismes
include,
import ou
redefine du langage XML Schema en sont des exemples ;
Certains processeurs ne gèrent pas toutes les structures des langages de schéma, à cause de mises en œuvre erronées ou
de différences dans les profils de conformité (par exemple, cf. les exigences de conformité de
XML Schema tome 1). Ainsi un schéma qui
fonctionne dans un environnement donné peut ne pas fonctionner dans un autre ;
Les possibilités dépendent aussi des fonctions du schéma qui sont visées par la modification. Par exemple :
Un redefine XML Schema n'est seulement possible que si le schéma modifié est créé avec des types nommés ;
Lorsqu'on utilise XML Schema, on ne peut appliquer la technique des schémas « déguisés »
(chameleon) ou « mandataires » (proxy)
— cf. http://www.xfront.com/ZeroOneOrManyNamespaces.html —
que si les schémas « déguisés » n'ont pas d'espace de noms. Par exemple, le
document XML Schema pour ITS
a un espace de noms cible et ne peut donc pas être un schéma « déguisé ».
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.
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.
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.
<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.
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.
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.
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.
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.
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.
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.
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.
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.
Dans le document DITA suivant :
<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 :
title: "Types of horse"
li: "Palouse horse:"
p: "{term}Palouse horses{/term}{fn/} have spotted coats. The {term}Nez-Perce{/term} Indians have been key in breeding this type of horse."
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.
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.
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.
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.
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.
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.
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.
É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é.
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 :
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 ;
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.
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).
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.
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
5 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).
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]
3 Lors de la création d'un contenu XML
Les créateurs de contenus XML devraient appliquer les pratiques exemplaires suivantes :
| Pratique exemplaire | Ré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.
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.
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]
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]
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).
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.
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].
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.
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.
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 :
Pour écraser l'information de traduction des attributs, vous devez utiliser un élément
its:translateRule dans votre document.
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.
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.
É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.
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&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&D facilities</title>
<body>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
<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.
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]
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 : 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&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.
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.
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 :
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 ».
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.
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 :
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.
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><span class="h1">Elibur Library</span> - 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.
