Automated systems for access to multilingual and multiscript library materials
Parmi les publications de l’IFLA, souvent trop méconnues, voici un ouvrage capital qui fera date. Il fait en effet le point sur un sujet important et crucial, non seulement pour les bibliothèques nationales ou les bibliothèques spécialisées, mais aussi pour les bibliothèques publiques qui développent des collections dans d’autres langues que le français. Comment cataloguer les livres écrits en arabe, chinois, hébreu, ou russe, dans un système informatisé sans multiplier les systèmes et les contraintes ? La Bibliothèque nationale de France n’a pas encore résolu cette difficulté.
Edité par deux grandes spécialistes du traitement informatique des langues non latines, Monica Ertel et Sally McCallum, ce livre fait le point sur le sujet et reprend les communications faites à un séminaire pré-congrès à Madrid en 1993.
Les langues en caractères non latins
Sally McCallum situe le problème du traitement informatique des langues telles que le cyrillique, chinois, japonais, coréen, arabe, hébreu, grec, thaï, hindou, arménien, géorgien, etc., dans le temps, en rappelant qu’en 1986 (premier séminaire tenu à Tokyo), le problème était sans solution claire. Mais l’informatique ayant fait depuis de tels progrès, de nombreux systèmes en offrent maintenant la possibilité – une liste des principaux logiciels de bibliothèques multi-écritures est d’ailleurs donnée à la fin du livre. Aux problèmes techniques liés à l’affichage de droite à gauche et au tri, il faut ajouter les difficultés de translittération (phonétique ou réversible), de formats et de règles de catalogage applicables à des structures de langues différentes, soit syllabiques, soit idéographiques. Le point est fait sur l’état des normes de translittération et sur le problème fondamental du jeu de caractères.
Un jeu de caractères universel
L’ISO a finalement trouvé la solution en produisant un jeu de caractères universel, appelé Unicode (ISO/IEC 10646). Ce jeu, qui permet de traiter toutes les langues, utilise soit deux, soit quatre octets – et non plus un seul octet comme le code ASCII – pour permettre le codage de milliers de caractères (65 536). Base et fondement de tout système voulant utiliser des caractères non latins, il permet de coder les lettres accentuées soit sur un, soit sur deux caractères et fournit un algorithme pour une présentation bidirectionnelle des langues. L’implémentation du code est en cours – déjà réalisée pour le format USmarc – mais pas encore pour Unimarc. C’est dire que, pour utiliser Unicode, il faut un ordinateur qui accepte cette codification des caractères (la plupart des machines utilisent actuellement le jeu ASCII), un logiciel de base capable de traiter ces caractères et des claviers modifiés. L’influence d’Unicode sur les réseaux est décrite dans un article de Norio Murakami.
Les systèmes qui existent
La troisième et dernière partie décrit le multilinguisme de plusieurs systèmes : Aleph (système israélien), VTLS, Minisis et RLIN. Dans tous ces systèmes, construits avant l’arrivée d’Unicode, les principales langues en caractères non latins sont gérées. Le principe est d’utiliser plusieurs tables de caractères introduites par des « codes d’échappement » suivis par le code de la table. La langue de chaque lettre ou de chaque mot peut ainsi être définie avec précision et des notices multilingues peuvent être affichées, avec des index dans les différents alphabets. De même, la plupart des systèmes offrent une translittération automatique en caractères latins pour l’affichage. Pour le classement, une table de correspondance permet d’attribuer une valeur à chaque lettre.
Ces exemples concrets sont intéressants, car ils montrent les techniques nécessaires au traitement des fichiers contenant des notices en caractères non latins. Mais de nombreux problèmes demeurent – notamment l’utilisation d’Unicode, car aucun logiciel ne l’utilise –, la réforme des formats, les fichiers d’autorité et les problèmes d’accès et de tri.