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
