IX^e SOMMET DE LA FRANCOPHONIE, BEYROUTH 2001

Indexation en français, Indexation en arabe

Beyrouth 28-29 septembre 2001

Les apports d’UNICODE, HTML4 et Dublin Core pour le traitement du texte multilingue : le cas des langues arabo-latines

Mokhtar BEN HENDA

CEM-GRESIC, Université de Bordeaux 3-FRANCE

ISD, Université La Manouba-TUNISIE

Résumé :

La problématique de cette étude s'inscrit dans le cadre d'un travail de recherche sur l'I18n des systèmes d'identification, d'étiquetage et de négociation des ressources d'information multilingues arabo-latines (URI, littéraux…). Dans le contexte actuel de la mondialisation et de l’internationalisation des systèmes d’information, comment la langue arabe est prise en compte au niveau de trois protocoles fondamentaux d’Internet à savoir HTML, Unicode et Dublin Core. L’analyse est orientée vers le problème de codage des caractères plutôt que l’analyse linguistique.

Mots Clés :

Multilinguisme – Internationalisation – Localisation – Systèmes d’information multilingues – Normes – Bidirectionnalité – Langue arabe – Dublin Core - Unicode

المستخلص :

تهدف هذه الدراسة إلى تحديد مفهوم عولمة النظم الإعلامية لوصف و معالجة الرصيد المعرفي متعدد اللغات على شبكة الإنترنت عامة والمتعلق باللغة العربية خاصة. ففي إطار العولمة التي يشهدها مجال المعلومات اليوم، ما هي الأشكال التي وقع اعتمادها لإعطاء اللغة العربية مكانتها في الأنظمة المعلوماتية الحديثة و بالخصوص على مستوى ثلاثة من أهم البرامج التي تشتغل بواسطتها شبكة الإنترنت و محتوياتها و نقصد بذلك لغة HTML و مواصفة اليونيكود و توصية Dublin Core للوصف البيبليوغرافي. تحليل هذه العناصر موجه إلى إشكاليات التشفير أكثر منه إلى المعالجة اللغوية و التحاليل الألسنية.

الكلمات الرئيسية :

تعدد اللغات – عولمة النظم الآلية - محلية النظم الآلية – نظم المعلومات متعدد اللغات – المواصفات – ازدواجية اتجاه الكتابة – اللغة العربية – دوبلان كور - يونيكود

I - Introduction

Si l'I18n des systèmes d'information et de communication continuent à progresser rapidement vers une transparence linguistique maximale des flux et des échanges des données entre systèmes ouverts et distribués, la pyramide des priorités linguistiques reste toujours défavorable à une présence des langues autres que latines et plus particulièrement les langues à double contraintes graphiques et directionnelles comme l’arabe. Pourtant les initiatives et les contextes de recherche ne cessent de se multiplier pour asseoir une véritable complémentarité linguistique et une harmonie culturelle solide sur le Net. Ces initiatives prennent forme de programmes, de protocoles, d’études et de projets d’envergures régionales et internationales dans des secteurs aussi divers et multiples que l’informatique, les télécommunications, les bibliothèques et les centres d’information, la traductique, la linguistique etc. La globalisation, l’i18n et la l10n, le standard Unicode et la norme ISO 10646, le projet UNL (Universal Networking Language)[1] etc. sont tous des exemple de ces initiatives qui visent l’ouverture de la communauté mondiale sur des plates-formes d’échanges et de coopération au-delà des barrières linguistiques. Le défi reste pourtant le suivant : comment atteindre ce degré d’universalité et de transparence sans toucher les particularités culturelles et linguistiques de chacun d’entre nous ?

L’intérêt porté dans ce document s’oriente vers un domaine particulier, celui des structures d’information et de leurs systèmes informatiques associés pour la création, la gestion et la diffusion de l’information scientifique et technique dans des ères d’échange et de coopération multilingues. Les bibliothèques et les services de documentation disposent à ce juste titre d’un rôle essentiel dans la chaîne d’information et de communication à laquelle ils sont tout particulièrement destinés à des échelles locales, régionales et internationales. S’il est vrai que cette catégorie d’institutions, surtout les bibliothèques et tout particulièrement les bibliothèques nationales, avaient tendance à s’occuper exclusivement des données factuelles et de référence, l’avènement des nouvelles structures des documents électroniques et des données multimédias à brisé ce cloisonnement pour permettre une ouverture sur les documents électroniques référentiels et en texte intégral. Les enjeux se multiplient et les défis s’accentuent. Dans un contexte multilingue (lourd !), la situation semble complexe … pour toutes les paires et les combinaisons linguistiques possibles. La langue arabe tout particulièrement est encore en phase de se positionner dans les méandres des systèmes d’information automatisés pour acquérir sa place en tant que langue partenaire des langues latines. Le projet de l’arabisation de Rameau, qui constitue une sorte d’extension « naturelle » du projet multilingue européen pour l’unification des listes vedettes matières (RAMEAU, SWD/RSWK et LCSH)[2], n’est qu’une démonstration de ce désir d’aller plus loin avec les acquis en la matière et de proposer des alternatives toujours plus adéquates et souples pour la transparence linguistiques des systèmes ouverts et distribués de l’information. Si Rameau, LCSH et SWD/RSWK ciblent essentiellement l’indexation des documents bibliographiques, d’autres techniques sont en cours d’usage pour traiter les documents électroniques en texte intégral. Nous essaierons dans ce document d’en évoquer trois essentiels et de soulever leurs apports par rapport au multilinguisme arabe-latin dans la structuration des documents multilingues, la reconnaissance des formes des caractères et l’indexation et la recherche des données.

II - Les axes de l’étude

Notre analyse portera donc sur un ensemble de trois caractéristiques fondamentales de l’environnement multilingue en général et du milieu documentaire en particulier. Nous suivrons une approche évolutive dans l’analyse de la portée multilingue depuis le codage des caractères, jusqu’à la structuration et le balisage des documents pour aboutir aux techniques d’indexation par éléments Meta. En effet, Unicode avec son approche universaliste de codage des caractères, HTML 4 avec sa nouvelle dimension d'I18n, et Dublin Core avec sa portée unificatrice dans le référencement des ressources d'information sur Internet, apportent des éléments de réponses grand publics pour l'intégration de la langue arabe dans Internet. Quel bilan ? Quelles perspectives ?

1. Le support UNICODE pour l’internationalisation : codage et rendu

En amont de tout système d’information automatisé, se situe un élément fondamental dont dépendent toutes les opérations subsidiaires inhérentes aux différentes tâches de traitement y compris les processus de l’indexation, du tri, de la recherche et de la diffusion de l’information. Cet élément de base n’est autre que le principe du codage de l’information. Tout document, toute norme, tout langage de programmation, tout protocole de communication, toute technique de codification des données textuelles est nécessairement associé à un jeu de caractères codés souvent appelé un répertoire de caractères dans lequel le système puise la signification des codes qu’il traite. C’est la nature des codes en question qui détermine la portée linguistique d’un système informatique concerné ou des applications qu’il supporte.

1.1 Le codage linguistique : Une histoire de « caractères » avant tout

C’est pour cette raison que tous les ordinateurs sont munis d’un certain nombre de ressources de traitement linguistique comme les jeux des caractères et les tables des codes des caractères qui leurs sont associés. En termes plus techniques, il s’agit respectivement des pages de fontes et des pages des codes auxquelles font appel les systèmes d’exploitation des machines pour gérer les caractères au niveau du codage et du rendu visuel.

L’histoire de l’informatique regorge d’une littérature abondante dans ce sens pour expliquer les modes et les techniques de codage des caractères et des fontes qui les accompagnent. On vit encore les séquelles de cette multitude de normes et de standards qui ont parsemé l’histoire de l’informatique et dans laquelle la présence des langues a été toujours marquée par un déséquilibre linguistique au profit des langues latines en général et de la langue anglaise en particulier. Sans vouloir reprendre le chemin des Croisades contre l’hégémonie américaine dans ce sens avec leur norme ASCII, chose déjà entreprise par beaucoup dont Claude de Loupy[3] et Bernard Cassen[4], il suffit de dire que tous les répertoires des caractères pris en comptes par toutes les initiatives, toutes les normes et tous les standards de codage des caractères sont obligatoirement ASCII à la base. Les langues autres que latines se contentent d’occuper les espaces d’arrière plan des tables de codes avec parfois des attributions d’espaces réduits.

Sans s’arrêter sur le codage à 5 bits utilisé pour les transmissions du télex, le codage des caractères a commencé avec l’ASCII (ISO 646) en forme de codes à 7 bits qui ne suffisait que pour l’anglais, l’indonésien et le swahili dans leurs transcriptions romanisées. L’extension de ce code vers une représentation à 8 bits a permis de représenter les autres langues dans les 128 positions supplémentaires à l’ASCII. C’était alors la norme ISO 8859-x avec ses 10 variantes linguistiques pour les langues à caractères diacritiques. Par un mécanisme d’alternance, les langues, autre que l’anglais, se substituaient l’une par rapport à l’autre sur les machines à vocation multilingue. Il est donc difficile de gérer des textes multiscripts qui nécessiteraient des normes de codages multiples à la fois. L’idée était donc partie de mettre en place un jeu de caractères universels capables de transcrire toutes les langues existantes sans obligation de changer de tables de codes pour chaque langue.

Les premières tentatives de codage sur 16 et 32 bits sont donc apparues pour permettre la manipulation des caractères du monde entier sur la même machine sans obligation de faire des choix sélectifs des langues utilisées. Unicode et ISO 10646 en sont la concrétisation de cette volonté d’aller au-delà des limites linguistiques des machines d’antan. Comment fonctionne alors ce nouveau mode de codage et quels sont ses apports pour le multilinguisme en général et la langue arabe en particulier ?

1.2 Unicode : un espoir ou une réalité pour l’internationalisation ?

Etant donné l’origine particulière d’Unicode en tant qu’initiative parallèle à l’ISO 10646 lancée par un consortium d’industriels de produits informatiques multilingues en 1989, les apports aux multilinguisme n’en restent qu’évidents, surtout après l’unification en 1991 des deux initiatives ISO et Unicode respectivement menées par le ISO/IEC JYC1/SC2 et le consortium Unicode pour garder une seule table de code synchronisée : le Jeu de Caractères Universels (Universal Character Set) codé sur deux octets (16 bits) donnant lieu à 65534 positions de codes. Il s’agit d’un cumul des standards précédents sous forme d’un jeu de caractères représentant pratiquement toutes les langues connues. Selon la définition de Joan M. Aliprand, « ces deux textes ne recensent pas simplement les systèmes d’écriture des langues les plus importantes, mais aussi tout un ensemble de symboles et d’autres éléments textuels … L’extension du répertoire d’écriture ne signifie pas simplement un accès à des écritures dont vous ne disposiez pas, mais un nombre plus important de signes pour les écritures déjà disponibles »[5]. L’avantage de JCU est son adaptabilité aux standards précédents de sorte que les conversions de et vers JCU sont possibles sans pertes de données. Pour une meilleure adaptabilité, des formes intermédiaires de codage sont prévues pour assouplir les conversions et les transactions de données inter-serveurs. UTF-8 est l’une des techniques qui permettent d’utiliser Unicode par une réduction de longueur de code de manière convenable et compatible avec les environnements développés autour de l’ASCII (7bits) et de l’ASCII étendu (8bits). Unicode et ISO 10646 évoluent aujourd’hui en parallèle dans une harmonie et une synchronisation totale au niveau des parties des codes communs. Unicode 1.1 correspond à ISO 10646-1 : 1993 et Unicode 3.0 correspond à ISO 10646-1 :2000.

Quelles sont toutefois les apports d’Unicode et d’ISO 10646 pour l’internationalisation des systèmes, des applications et des données multilingues et quelles en sont leurs limites d’usage ?

1. 3 Unicode et i18n

L’apparition du système de codage sur 16 bits a largement contribué à l’apparition du concept d’internationalisation (i18n) conduit depuis lors pour atteindre des degrés de transparence linguistique au niveau des systèmes, des applications et des données.

La technique générale consiste à introduire sur les anciennes versions « locales » les innovations apportées par les extensions « internationales » des codes.

Au niveau du codage des données, le grand avantage d’Unicode est sans doute ses deux règles d’or :

Coder des caractères et non des glyphes : Le standard Unicode couvre exclusivement les codes des caractères sans aucune considération pour la forme de leur présentation. Celle-ci est attribuée aux protocoles de plus haut niveau qui incombent aux programmes d’application. Unicode ne définit pas la forme des glyphes d’un caractère. Il identifie le « point de code » d’un caractère abstrait (i.e. Le caractère arabe Hamza) et les autres protocoles d’affichage d’un ordinateur se chargent du rendu graphique de ce caractère. Ainsi, Unicode donnerait la possibilité de coder chaque variante de caractère comme un caractère indépendant. Ceci évite plusieurs problèmes relatifs à l’universalité du code, à son efficacité, son uniformité et son ambiguïté. Le caractère espagnol « ll » est ainsi considéré comme deux « l » successifs et non un seul caractère. Les marques de vocalisation sont également codées à part pour éviter la duplication des points de codes pour des caractères similaires « é », « è », « ê » etc. Des caractères précomposés sont toutefois insérés dans la table Unicode en tant que Point de code unique (i.e. « ù », « ñ » etc.),question de garder une marge de compatibilité avec certaines normes comme ISO 8859-1 (Latin-1).

Unifier toutes les langues dans un seul répertoire de caractères : Par cette démarche, Unicode résout le problème inhérent aux différences des normes et standards de codages précédents (ASCII, ISO 8859-x etc.). Le passage d’une table de code ou d’un répertoire de caractère à un autre engendre souvent des pertes de données dues à des incompatibilités de codes. Un seul caractère peut être codé différemment dans plusieurs tables de codes ; un seul code peut identifier plusieurs caractères dans plusieurs tables de codes. L’unification de tous les caractères dans un seul répertoire facilite et rend transparente la manipulation de toutes les langues à la fois sans ambiguïté de codes et surtout sans obligation de conversion entre tables de codes.

Au niveau applicatif, l’internationalisation des programmes ne touche pas les codes de leurs noyaux internes. Sauf les fichiers contenant les éléments d’information traduisibles sont mis à jour. Parmi les fonctions clés de l’internationalisation des programmes notons surtout :

ð L’isolement des parties des codes traduisibles dans des fichiers séparés appelés fichiers ressources avec la possibilité d’y accéder quand nécessaire par le noyau du programme. Il s’agit en fait d’un certain nombre de fichiers en mode texte, des fichiers de bases de données, des fichiers codes sources etc. qui restent à l’écart du noyau dur le l’application.

ð Le changement des variables de formatage des données pour en faire des codes indépendants de la langue du système en cours. C’est le cas des dates, de l’heure, des chiffres, des symboles monétaires et des messages systèmes qui dépendent désormais des options de la langue locale et des besoins du pays concerné.

ð Le changement des routines de traitement linguistique (i.e. tri et recherche) pour en faire des procédures indépendantes de la langue du système en cours d’utilisation.

La localisation (l10n) des programmes « inerntionalisés » ne nécessite donc aucune modification sur le noyau central de l’application. Il suffit de traduire dans la langue voulue le contenu des fichiers « traduisibles » pour en faire ce qu’on appèle les « Locales », fichiers ressources qui prennent en compte les caractéristiques des linguistiques (et non des langues !) locales.

Ainsi, l’internationalisation des programmes et des applications par Unicode, permet de mettre en place une solution unifiée pour toutes les alternatives linguistiques du marché. Le principe du codage unique pour un seul caractère sans considération de son identité linguistique évite d’une part la rédaction de programmes personnalisés pour chaque langue, et d’autre part évite la corruption des données gérées par des applications qui utilisaient des codes de caractères différents au même moment. Tous les systèmes d’exploitation actuels tournant sur PC, Mac ou gros systèmes, la majorité des applications de bureautique, de bases de données etc. supportent Unicode. Les solutions Windows (systèmes d’exploitation et programmes d’application) en sont un exemple concret.

1.4 Unicode et langue arabe

Bien que le jeu de caractères universels (UCS) soit a-linguistique, il regroupe les caractères en blocs de codes selon la nature du script (caractères latins, cyrilliques, arabes, hébreux etc.). Les blocs de codes sont ainsi disposés dans des espaces de codes qui varient en grandeur en fonction du script concerné. Alors que le cyrillique ne dépasse pas les 256 points de codes, le japonais en occupe des milliers.

Les espaces de codes sont ordonnés dans une suite qui reproduit quand c’est possible la logique évolutive des anciennes normes : le premier espace est réservé à l’ASCII, suivi des caractères latins, grecs, cyrilliques, hébreux, arabes, etc. conformément à la famille de normes ISO 8859-x.

Le jeu des caractères UCS réserve ainsi une partie de son espace de codes au codage des caractères arabes au niveau de la sixième rangée du BMP (en contiguë, les caractères arabes de base et étendus). Les rangées FB, FC, FD et une partie de la rangée FE sont destinées par contre à coder les différentes formes de présentation des caractères arabes (glyphes) : isolés, surimprimés (overstiking) sur deux caractères ou plus.

L'état actuel de la présence du caractère arabe dans le BMP est issu d'une contribution d'une commission égyptienne qui a pu introduire les éléments suivants dans la codification du caractère arabe :

ð Les caractères de base de l'alphabet arabe avec leurs différentes formes contextuelles ;

ð Les caractères de voyellation ;

ð Les caractères latins pour la représentation de l'arabe parlé ;

ð Une amélioration des caractères de contrôle.

Parmi les particularités qui distinguent le caractère arabe dans le BMP par rapport aux autres tables de codes, on relève la présence des caractères composés par surimpression et les codes de gestion de la bidirectionnalité.

En effet, par comparaison à ISO 10646, il est confirmé qu’Unicode dispose de plus de définitions sémantiques pour certains caractères et constitue donc une meilleure référence pour tous les concepteurs de systèmes de publications typographiques de haute qualité. Unicode spécifie aussi des algorithmes d’affichage et de présentation de certaines écritures « ambiguës » comme l’arabe et l’hébreu afin de faire un rendu bidirectionnel. Pour cela, il fait appel à un algorithme BIDI (Bidirectionnel) pour attribuer à chaque caractère une propriété directionnelle héritée de celle du script dans lequel il est pris : les lettres latines sont d'une directionnalité gauche-droite ; les caractères arabes et hébreux sont d'une orientation droite-gauche.

Le traitement de la bidirectionnalité sous Unicode est automatiquement accompli par les algorithmes par défaut. Cependant, dans des situations de complexité avancée, des indications supplémentaires sont parfois nécessaires pour indiquer une directionnalité forcée pour une raison d’incises à plusieurs niveaux ou de bris de textes. Pour cette raison, Unicode dispose d'un ensemble de règles et de caractères invisibles de codage (Code U+200E pour la direction Gauche-Droite et code U+200F pour la direction Droite-Gauche) que les logiciels d'affichage ou d'impression interprètent pour établir la direction de chaque séquence de caractères. Le rôle des algorithmes d'affichage (rendering) est effectivement nécessaire pour traiter à la fois les questions de la bidirectionnalité et de l'analyse contextuelle pour la sélection des glyphes appropriés en fonction de la position du caractère dans le mot.

Unicode offre également les solutions adéquates pour faire le tri, la comparaison des chaînes de caractères etc. ISO 10646 reste par contre plus limité sur les fonctionnalités multilingues lourdes (rendu et bidirectionnalité) et se contente d’être un jeu de caractères comme les anciens codes ASCII et ISO 8859 sans portée sémantique notoire.

Caractérisé par un multilinguisme lourd (reconnaissance des formes et gestion Bidi)[6], le multilinguisme arabe-latin se voit largement renforcé par l’adoption d’Unicode en tant que jeu de caractères unifiés. L’usage restrictif de la norme ISO 8859-6 pour la combinaison de la langue arabe se voit désormais ouvert sur une coexistence multiple de caractères, donc de langues universelles au même moment. Grâce à Unicode, il est même question aujourd’hui d’aborder l’« arabisation » de zones systèmes historiquement exclusives à l’ASCII. A part les initiatives déjà en vigueur de certaines langues asiatiques, des tentatives des groupes de réflexions arabes sont en cours (i.e. AINC)[7] pour l’I18n des noms de domaines (DNS = Domain Name Systems). Unicode aurait ainsi ouvert les perspectives de développement d’un multilinguisme arabe-latin plus profond, plus souples et plus transparent. Des projets d’arabisation de listes de vedettes matières, comme il en est question pour Rameau et son arabisation n’en seront que renforcé grâce aux deux particularités essentielles de l’unification des caractères codées et de l’univoque représentation désambiguïsée des caractères multilingues et des algorithmes de traitement qui les accompagnent. Les solutions de la romanisation des scripts, de la translittération et de la traduction peuvent ainsi être abandonnées au profit d’une intégration plus homogène et globalisante des langues qui peuvent désormais coexister en présence d’algorithmes et de programmes supplémentaires de traduction automatique, conversion, analyse sémantique et linguistique à la volé etc.

Sauf que l’internationalisation des systèmes d’information et de documentation en général dépasse le cadre de l’internationalisation des listes de vedettes matières pour englober un éventail plus large de protocoles, programmes, normes et standards de traitement de l’information multilingue.

2. L’internationalisation des services et des outils d’information électronique

Déjà adopté en tant qu’alternative incontournable de l’internationalisation, Unicode est désormais présent dans quasi la totalité des normes et standards de traitement de l’information. C’est le répertoire de caractères unanimement recommandé comme jeu de caractères implicite dans l’étiquetage linguistique des données traitées ou échangées au sein des différentes applications, normes et formats de documents électroniques. Il est vrai que la famille ISO 8859-x continue à être en vigueur, mais la substitution est en cours et le passage définitif est imminent.

Déjà des normes et des standards d’échange et de traitement des données multilingues comme le format d’échange Unimarc, le langage HTML ou la norme Dublin Core, ont évolué vers des perspectives d’internationalisation de leurs jeux de caractères associés.

2.1 L’internationalisation des services d’information documentaires

Les bibliothèques et les services d’information ont une histoire particulière avec les ressources d’information multiscripts. Toute bibliothèque devrait « normalement » disposer d’une collection de documents multilingues et devrait « normalement » servir une population proportionnellement multilingues. L’intérêt porté aux applications bibliographiques (SGBD, Bureautique, OPACs, etc.) ne cessait de s’accroître pour permettre l’accès à ses ressources par une communauté multilingues et multiculturelles.

L’élément clé dans ces initiatives de conception de solutions multilingues pour les applications bibliographiques est sans doute une méthode d’encodage qui permettrait aux machines et aux logiciels de traiter les caractères et les symboles utilisés pour la représentation des textes écrits et leurs inter-échanges. Or les techniques de codages des ressources bibliographiques ont toujours été disparates, non uniformes et non exhaustives ; ce qui a toujours engendré l’exclusion de certains fonds linguistiquement « complexes » du fonds général de certaines bibliothèques. Dans les meilleurs des cas, elles évoluent de l’ASCII (7 bits) à l’une des normes de la famille ISO 8859-x (8 bits). Comme l’expliquent Foster J. Zhang et Marcia Lei Zeng[8], c’est la résultante essentielle de la marginalisation des bibliothèques par les développeurs d’applications qui s’orientent surtout vers le contexte plus porteur des entreprises pour développer dans les meilleurs des cas des applications bilingues. Les bibliothèques et les centres de documentation ont cependant toujours besoin d’un outillage linguistique simultané et multiscripts. L’absence d’un consensus universel pour l’adoption d’un jeu de caractères unifié a fait en sorte que chaque structure se débrouillait pour adopter ses propres méthodes de traitement multilingues.

Elisabeth Freyre & Françoise Bourdon[9], posent la problématique linguistique pour les bibliothèques à plusieurs niveau du traitement des fonds :

ð Quelle langue et/ou quelle écriture l'agence bibliographique nationale doit-elle choisir ?

ð Durant le déchargement (devenu fréquent) des notices de différents réservoirs ayant chacun leur langue et leur écriture, ou d'un même réservoir contenant des notices dans des langues et des écritures différentes, faut-il s'en tenir à 1 catalogue et à 1 langue et à 1 écriture ?

ð Est-il possible de gérer dans un même catalogue des notices rédigées dans des langues différentes / dans des écritures différentes ?

La réponse à ces questions a connu deux étapes fondamentales : la transcription et la translittération d’une part (le cas de la romanisation de caractères, mentionné dans les ISBD), et d’autre part, la migration vers des systèmes de codages des caractères sur plusieurs octets, en l’occurrence UNICODE et ISO 10646.

Bien que la majeure partie des bases de données en format MARC aient utilisé pour longtemps le codage ASCII ou tout autre code local, la migration vers Unicode était lente et difficile étant donné le volume rétrospectif des données à convertir et les techniques de conversion complexes à y appliquer.

S’il est tout à fait possible aujourd’hui de créer à la source des bases de données bibliographiques dans les formats MARC sous Unicode, il est toutefois difficile d’en assurer l’échange car les données Unicode dans les enregistrements devraient être au préalable converties dans un codage 8 bits de Unimarc ou USMarc.

Les initiatives (européennes et américaines surtout), ont déjà pris forme pour la mise à jours des spécifications des formats Marc sous formes de propositions et de recommandations pour l’usage d’Unicode. Il n’est cependant pas encore commun ni évident de savoir comment l’introduire comme répertoire unique de caractères pour tous les formats Marc du monde.

Ce qui est toutefois une évidence selon Aliprand, c’est que « Unicode et ISO 10646 fournissent un répertoire d’écritures et de signes bien plus grand que ceux prévus par les systèmes de bibliothèques, que ce soit ceux qu’utilisent USMARC ou UNIMARC »[10]. A ne citer que le cas de la langue arabe, les différents jeux de caractères d’Unimarc / USMarc proposent 124 codes de caractères arabes alors que Unicode en propose 141.

2.2 L’internationalisation des services d’information sur Internet

Bien que le monde des bibliothèques reste beaucoup plus ancien que l’univers Internet, les applications du Web ont fini par révolutionner de manière plus drastique le contexte de l’échange de l’information multilingues. Les systèmes ouverts et distribués des réseaux, les outils de recherches sur la base de données mondiale du Net, la localisation des postes clients partout dans le monde, etc. ont obligé la nécessité de concevoir et de mettre en place des solutions multilingues adéquates pour manipuler toutes les langues dans un seul jeu de caractères unifiés. Selon Lois Mai [et. al], « … Depuis 1998, les moteurs de recherche du Web sont entrés en concurrence à l'échelle mondiale et locale. Le traitement multilingue a émergé comme une question clé dans l'évolution des technologies de ces moteurs de recherche »[11].

La problématique multilingue que nous proposons d’aborder dans ce document se situe par contre en amont du système d’information sur Internet : la structuration des documents et leurs identifications linguistiques par les concepteurs des ressources d’information électroniques en formats HTML. Constituant la plus grande partie de ressources sur Internet, HTML (avec le concours du protocole internationalisé HTTP 1.0 & 1.1 pour le transfert des documents hypertextes) joue un rôle important dans l’internationalisation du réseau. Comment apparaissent alors ses apports pour le multilinguisme en général et le multilinguisme lourd (bidirectionnel et multiscripts) en particulier ?

2.2.1 L’étiquetage linguistique sous HTML 4.

Il faut dire d’emblée que le langage HTML dans sa version 4.0 (et sa version révisée 4.01), adhère pleinement à la norme Unicode par l’adoption du jeu des caractères universels dans ses différents formats et tout particulièrement UTF-8. HTML 4.0 incorpore aussi le RFC 2070 (Request for Comment) spécifique pour l’internationalisation de HTML par l’introduction d’un certain nombre d’éléments et d’attributs linguistiques innovateurs sur deux aspects tout à fait particuliers : l’étiquetage linguistique et la gestion de la bidirectionnalité.

L’identification des jeux des caractères au moment de la conception d’une ressource WWW applique généralement la méthode d’étiquetage de MIME avec les deux attributs les plus significatifs « CONTENT » et « CHARSET » sous la forme :

Content-Type: */*; charset=jeu de caractères (Exemple : Content-Type: text/plain; charset=ISO 8859-1

Cette méthode a toujours constitué le modèle d’étiquetage standard des langues de l’Europe de l’Ouest basé sur le jeu des caractères ISO-8859-1 adopté par défaut pour les documents HTML. Pour afficher des documents dans des langues autres que latines (i.e. arabe), il était nécessaire de choisir le jeu de caractères alternatif qu’il fallait indiquer comme valeur du champ « CHARSET » de la manière suivante :

Content-Type: text/plain; charset=ISO 8859-6

Selon les affirmations de Andrew Daniel (Université de Vancouvert)[12], cette manière causait des erreurs d’interprétation de la part de certains navigateurs anciens qui l’interpréterait comme un fichier binaire pour lequel ils lançaient des opérations de sauvegarde sur disque au lieu d’afficher la page dans le jeu de caractères spécifié. Cette fonctionnalité d’affichage était alors rectifiée en utilisant les paramètres « META » du langage HTML conformément à la structure suivante :

<META HTTP-EQUIV= «content-type » CONTENT= «text/html ; charset=iso-8859-6 »

L’introduction de cette nouvelle forme d’identification des valeurs linguistiques et des techniques de codage des documents à travers l’élément « META » a permis aux navigateurs de changer automatiquement de fontes chaque fois qu’il y à un nouvel appel pour un jeu de caractères codés différent. Les améliorations nouvelles d’Unicode et son adoption progressive par les concepteurs de logiciels et les fabricants de matériels assouplissent considérablement la rigueur des outils de traitement et de navigation multilingue. L’adoption de UTF-8 comme format général du jeu de caractères universel pour le Web va permettre l’acceptation de toutes les formes d’écritures dans les pages HTML et leur affichage implicite par les navigateur d’aujourd’hui ; Chose non appliquée avec ISO 8859-1 ou Shift_JIS. MSIExplore 5.0 et Netscape Communicator 4.6 en sont des exemples concrets.

Pour résumer l’importance de l’étiquetage linguistique, il est recommandé comme règles générales de suivre l’ordre de priorité suivant dans l’élaboration des documents Hypertextes prévues pour un usage multilingue :

Introduire le paramètre http « Charset » dans le champs « Content-Type » au niveau de l’entête du document ;
Effectuer une déclaration « META » pour « http-equiv » avec « Content-Type » et uen valeur appropriée pour « Charset » ;
Faire usage de l’attribut « Charset » au niveau des éléments qui font appel à des ressources externes.

Ceci va sans dire que les autres formes de balisages des documents électroniques sur Internet, en l’occurrence SGML et XML apportent davantage de support à l’internationalisation des documents, des notices bibliographiques par la maîtrise plus souple de la structure logique et sémantique des documents. Basé sur un codage interner en Unicode, la technique de marquage (forme et contenu) n’en peut que tirer un maximum de profit pour asseoir un nouveau contexte de traitement multilingue au niveau de l’identification des contenus et de leurs formes de représentation et d’échange.

2.2.2 La bidirectionnalité sous HTML 4.

La bidirectionnalité sous HTML 4.0 est très reliée à l’attribut de langue du contenu de la ressource concernée. Les deux attributs « Lang » et « Dir » se complètent pour identifier la valeur linguistique d’un document HTML.

L’attribut « Lang » est le code à deux caractères attribué selon ISO 636 à une langue écrite ou parlée. Il peut être indiqué en début d’entête ave la balise <HTML> (i.e. <html lang=« ar »>) pour indiquer l’identité linguistique de tout le document ou avec des éléments d’identification de parties du corps de documents (i.e. <p lang=« fr »>).

Comme le précise la spécification HTML 4.0 du CW3, l’information linguistique fournie par l’attribut « Lang » peut être utilisée dans plusieurs cas de figure :

ð Aider les moteurs de recherche ans les processus de l’indexation et de la restitution ;

ð Aider la synthèse de la parole ;

ð Aide le bon choix des glyphes pour un besoin d’impression de haute qualité ;

ð Aide à la correction orthographique et grammaticale …

L’attribut « Dir » par contre spécifie la directionnalité de base du document ou d’une séquence du document (paragraphe ou tableau). Les auteurs des documents HTML ont donc out intérêt en plus de préciser la langue, d’ajouter la directionnalité de base de leurs documents.

Bien qu’Unicode attribue une directionnalité de base aux caractères et définit un algorithme complexe pour la directionnalité du texte, HTML offre des fonctions plus importantes et plus claires pour gérer les mêmes fonctions.

L’attribut « Dir » peut être inséré en début de document avec la balise <HTML> (i.e. <html dir=« rtl »>) ou en parties du corps du document (i.e. <p dir=« rtl »>).

Une combinaison entre attributs « Lang » et « Dir » est aussi envisageable (i.e. <html lang= « ar » dir=« rtl »>).

La figure suivante illustre l’usage des champs MIME dans une zone METADATA pour l’identification des attributs linguistiques d’un document HTML rédigé en langue arabe.

Etiquetage linguistique d’un document HTML arabe par l’élément « META » sous Tango

Dans cet exemple, la zone META décline l’identité linguistique du document par les deux rubriques « META HTTP-EQUIV » suivantes :

Content-Type “CONTENT=”text/html; charset=asmo-708-fr

Ceci indique qu’il s’agit d’un document textuel en format HTML codé selon le jeu de caractères codés ASMO 708 ;

Content-Language “CONTENT=”ar : ceci précise que la valeur culturelle du document est explicitement relative à la langue arabe sachant que la norme ASMO pourrait être utilisée pour d’autres langues utilisant l’écriture arabe. L’entité du champ « Content-Language » décrit la/le(s) langue(s) naturelle(s) du public cible auquel le document est initialement destiné.

En définitive, nous pouvons affirmer qu’Unicode et HTML 4.0 ont largement contribué à la résolution d’un grand problème de traitement de la langue arabe au niveau du rendu visuel, de la structuration des documents hypertextuels et de la coexistence avec toutes les autres langues du monde, répertoriées dans le jeu de caractères universels. Sauf qu’à notre sens, ceci ne doit pas se limiter à un problème de représentation et de rendu graphique. Toute une approche sémantique est aussi à considérer pour toucher le contenu intellectuel et scientifique des documents multilingues sur le Web. L’indexation de ces documents est actuellement parmi les préoccupations des instances bibliographiques nationales et internationales pour des besoins de référencement, de contrôle et d’échange. Ou en est l’uniformisation et l’internationalisation de ce chapitre à échelle mondiale ?

3. L’Indexation multilingue par les éléments META et la norme Dublin Core

C’est en mars 1995 à Dublin (Ohio-USA), durant une série d’ateliers internationaux que les instigateurs du projet Dublin Core sont parvenus à un consensus pour unifier « la définition des ressources, au réseautage, aux normes d’encodage, à la recherche documentaire et à toute une gamme de sujets »[13]. Dublin Core venait ainsi comme projet unificateur pour marquer le début d’un consensus international afin d’harmoniser cet effort de référencement universel, consolidé par l’avènement d’Unicode.

Initialement prévue pour des affinités simples d’aide aux auteurs d’harmoniser le balisage sémantique de leurs documents, Dublin Core est aujourd’hui en cours d’usage dans différents domaines de spécialités comme les informations officielles, les activités du dépôt légal, la muséologie, et le commerce électronique[14].

Dublin Core[15] est à titre d’exemple un modèle de référence très avancé dans la communauté des spécialistes des bibliothèques numériques et des documents structurés qui vise depuis sa création à adresser le problème de la description unifiée des ressources d’information électroniques et donc de leur localisation dans un contexte réseaux.

Le projet Dublin Core prévoit 15 éléments de données descriptifs (métadonnées) qui décrivent les ressources d’information de façon à permettre leur repérage et leur restitution dans la masse des ressources accessibles sur le Web.

Bien que cette tâche d’identification (catalogage ou description bibliographique) était et le reste encore le champs d’action des formats MARC, Dublin Core constitue aujourd’hui l’une des alternatives les plus importantes à cet état de fait. Parmi les caractéristiques positives qui militent en sa faveur, sa simplicité d’usage pour les auteurs des documents, son extensibilité pour les critères locaux, son adoption massive par les grandes structures spécialisées dans toutes les disciplines[16], sa cohabitation avec d’autres règles de description méta etc.

Dublin Core est la voix d’expression de l’universalité des ressources et services Internet. Les 15 champs qu’il propose pour la description et l’indexation des données gagnent du terrain, consolidés par la progression de l’Unicode et l’amélioration de HTML.

Sauf que, Dublin Core connaît encore, et malgré tout, une série de difficultés et défis qu’il est censé relever face à son parcours d’universalité. Parmi ces défis, le volet linguistique reste toujours d’actualité.

3.1 L’I18n et la L10n de Dublin Core : la sémantique au cœur du défi linguistique

L'indexation par éléments META constitue à notre sens l'un des enjeux stratégiques pour les langues alphabétiques à caractères non latins afin de transgresser les simples limites des solutions de rendu des interfaces Homme-Machine et promouvoir sa reconnaissance implicite et dynamique par les moteurs de recherche. Le multilinguisme arabe-latin des corpus textuels, des thesaurus, des bases de données des connaissances, des index et fichiers inverses, des systèmes OPACs et de recherche en ligne … n'est pas encore un fait établi. Le référencement des ressources en langue arabe par des éléments META reste toujours sporadique, aléatoire et limité à des environnements linguistiques explicites et propriétaires encore éloignés d'un consensus international unanime.

L’un des problèmes majeurs, induit par le volet linguistique, est l’incohérence dans l’interopérabilité sémantique entre le dépositoires des documents ayant un label DC, car la définition des éléments constitutifs de Dublin Core n’a pas toujours été soumise à une pratique réglementée. Elle subit souvent l’interprétation personnalisée des auteurs ou des réalisateurs des ressources.

A part le nom et la définition dont dispose chaque élément DC pour des besoins d’identification par les humains, des identificateurs électroniques (jetons=tokens) d’index électroniques leur sont également attribués dans un objectif d’indexation par les robots des moteurs de recherche. Pour des raisons techniques, ces jetons sont exclusivement codés en chaînes de caractères ASCII (du genre « Subject », « Creator » etc.) pour être traité de façon uniforme malgré la différence leurs contenus multilingues. Ils constituent la base de l’interopérabilité sémantique de toutes les versions linguistiques de Dublin Core. Le grand problème de Dubln Core est aujourd’hui la prolifération des attributs locaux des éléments DC. Ayant été permis pour gagner en flexibilité et en extension vers des situations de description de documents à caractères locaux, il y a un risque vers la dérive de DC standard et la montée en valeur des alternatives locales qui pourraient toutefois enrichir l’interopérabilité sémantique si elle est partagée entre plusieurs communautés linguistiques. Ceci a toujours constitué un débat entre les « Minimalistes » qui tendent vers une version limitée de DC mais universelle et uniforme et les « structuralistes » qui prêchent la flexibilité et l’extension pour préserver la spécificité locale et la richesse de la diversité.

Une version arabe de DC était coordonnée par Hichem HADDOUTI, un chercheur du centre bavarois pour les systèmes à base de connaissance (FORWISS)[17]. Elle entre dans un processus de traductions multilingues des deux pages du standard effectuées dans plus de 47 langues pour servir de documents de référence. Une polémique est cependant en cours pour savoir identifier les versions linguistiques comme des versions isolées ou des simples traductions des versions évolutives de la source anglaise.

Pour les raisons d’indexation et de recherche multiscripts, des solutions vers des noyaux Dublin Core multilingues sont proposées. Une première esquisse est celle de la définition de noyaux parallèles dans la même ressource HTML qui assureront l’aiguillage des robots indexeurs vers les versions linguistiques appropriées. Le problème majeur à cette approche est le fait que les balises d’identification des versions linguistiques soient encore exclusivement à base de l’ASCII ; donc en caractères latins. D’où la restriction imposée pour que la déclaration META soit utilisée uniquement quand l’encodage des caractères est interprété en ASCII au moins jusqu’à ce que l’élément META soit atteint. Les agents clients pourront alors interpréter correctement l’élément META conformément à la spécification linguistique.

Cet état de fait nous met obligatoirement devant la problématique quasiment ignorée de l’i18n des littéraux de formatage (éléments en-têtes, attributs, balises HTML, etc.) exclusivement limités au jeu de caractères ASCII. Cette problématique constituerait à notre sens une continuité de l’i18n des URI qui constituerait l’extension de notre travail de recherche en la matière plus tard. D’autres éléments d’analyse relatifs au multilinguisme des éléments META de DC ainsi qu’aux apports d’Unicode pour l’i18n des zones systèmes sont au cœur des débats.

Mais, à notre sens, il est plutôt question pour le monde arabe actuellement, de se pencher plutôt vers une optimisation de l’interopérabilité sémantique entre ses structures nationales spécialisées et ses partenaires internationaux pour entrer dans une dynamique d’échange multilingue sur la base d’une unité sémantique et d’une transparence linguistique qu’assurent désormais beaucoup d’outils du marché grand public.

3.2 Applicabilité

Partant de son principe d’extensibilité, DC peut coexister avec toute autre norme ou règle de définition d’éléments méta.

L’alternative DC est entouré d’un consensus international qui essaie de mettre à la portée du grand public un grand nombre d’outils capables de l’aider à mieux maîtriser cette norme et à optimiser son usage. Devant l’absence flagrante des éléments META dans les contributions des auteurs des ressources HTML, des outils de conception de métadonnées sont mis au point pour aider à l’uniformisation de cette partie stratégique dans la structure des documents électroniques.

L’exemple suivant illustre une procédure de création d’éléments META par l’outil META BUILDER de l’université de Vancouver[18] mis en accès public pour la conception d’en-têtes standardisés conformes à Dublin Core. Nous reprenons dans la figure suivante la partie du formulaire relative à la saisie des variables concernant les jeux des caractères utilisés, en l’occurrence l’élément « CHARSET ».

Extrait du formulaire de définition des éléments META par META BUILDER

Le texte suivant illustre le rendu du traitement du formulaire sous forme d’un en-tête META normalisé à inclure au début d’une page de sources HTML. Les champs méta de Dublin Core, identifiés par le préfixe DC (i.e. <META NAME="DC.Title" CONTENT="charset iso 8859-6">), s’associent aux autres champs méta standard de HTML pour l’identité physique du document.

<TITLE>charset iso 8859-6</TITLE>

</HEAD>

III - Conclusion

S’il est vrai que les réalisations dans le processus de l’internationalisation des supports et des outils de traitement et de gestion de l’information gagnent beaucoup en quantité de solutions et en qualité de produits, les langues « minoritaires » ont encore beaucoup de chemin à faire pour gagner une place de partenariat et non plus de dépendance dans le contexte de la mondialisation qui s’installe. Point de pessimisme en cela, sauf que les barrières linguistiques sont encore à estomper pour atteindre le stade de l’équité. Si les efforts sont très bénéfiques jusqu’ici pour consolider une présence des langues minoritaires au niveau des contenus d’information, il n’en est pas encore confirmé que la même présence serait assurée dans les zones systèmes qui leurs sont toujours interdites.

Les services d’information et de communication sont les premiers à sentir les apports de l’internationalisation des outils et des systèmes car ceci leur fournit une assise de travail plus ouverte et plus dynamique pour renforcer la coopération interinstitutionnelle et interindividuelle. Le projet de l’arabisation de Rameau n’aurait pas beaucoup de chance de réussite s’il n’y avait pas cette évolution considérable au niveau de la représentation des langues sur support informatique.

L’enjeu est désormais de savoir se positionner par rapport à ces innovations pour actualiser d’une part l’actif en termes de traitement et de gestion des collections documentaires (conversions, reformatage, régénération etc.) et d’autre part pour optimiser voire même changer les politiques de travail et les choix techniques et technologiques des structures spécialisées comme les Bibliothèques Nationales et les centres de documentation et bibliothèques spécialisées et de recherche pour suivre l’évolution du contexte et rester au diapason des attentes et exigences des utilisateurs.

La formation des formateurs, des spécialistes de l’information ainsi que les utilisateurs est aussi un passage clé pour permettre l’évolution parallèle de tous les opérateurs concernés vers l’internationalisation des outils et des systèmes d’information contraints désormais à travailler en étroite collaboration. La technologie a pu estomper la distance ; c’est à l’homme de maîtriser l’outil et le contenu.

Notes