Spécification de la prise en charge linguistique

Améliorer la prise en charge de la langue des corpus par la plateforme.

L'adoption d'Unicode pour la représentation des caractères ouvre la voie à la prise en charge de nombreuses langues et systèmes d'écriture.

Cela a un impact sur les possibilités :

• de tokenization, dont découlent :
  • les possibilités de construction de lexiques
  • les possibilités de recherche plein texte orientées mots
• d'annotation linguistique (semi-)automatique
  • les outils peuvent travailler directement sur de l'Unicode ou sur des versions translittérées des textes
  • les systèmes d'écriture eux-mêmes ont des variantes ayant un impact sur le TAL, par exemple l'Arabe voyellé ou pas
• d'affichage des mots dans la plateforme :
  • on offre déjà la possibilité de choisir une (seule) police (Unicode) pour afficher les mots d'un corpus dans les listes de résultats, concordances et éditions
  • il faut tenir compte du sens d'écriture :
    • pour les langues sémitiques il faut tenir compte de la disposition des listes de résultats par rapport à l'écriture de droite à gauche. Les mots et suites de mots s'affichent déjà de droite à gauche (mécanisme interne à SWT interprétant l'Unicode), mais par exemple :
      • les éditions sont justifiées à gauche alors que dans ce cas elles devraient être justifiées à droite
      • les concordances doivent intervertir leurs contextes gauches et droits et peut-être le côté de la colonne des références
      • etc. (il faudrait faire le point avec une personne habituée aux interfaces graphiques en langues sémitiques)
• de saisie des mots dans la plateforme :
  • il faut développer la relation entre TXM et les méthodes de saisie intégrées aux systèmes d'exploitation :
    • sous Linux il y a déjà quelques méthodes de saisie par défaut, mais pas pour l'Arabe ou le Russe par exemple
  • on peut aussi, de façon complémentaire, développer un composant TXM (multi-systèmes) pour les méthodes de saisie (voir s'il n'y a pas déjà des composants Java généraux de ce type)
  • le copier/coller fonctionne dans les champs de saisie pour l'Arabe, même si l'inversion des sens de déplacement du curseur et de la sémantique des touches Backspace/Delete n'est pas immédiate
• de tri des mots. Plusieurs composants de TXM sont concernés par les tris aujourd'hui :
  • le compilateur CWB qui trie les dictionnaires de propriétés de mots, pour que les codes numériques du corpus entretiennent entre eux une relation d'ordre alphabétique
  • les concordances qui réalisent divers tris alphabétiques (et non numériques comme ce devrait être le cas, car il faudrait pouvoir profiter des tris CWB et le calcul serait plus efficace - sur entiers vs sur chaînes)
• d'affichage d'éditions :
  • actuellement nous utilisons beaucoup HTML+CSS pour la visualisation d'éditions mais la relation entre Unicode et HTML n'est pas forcément immédiate. Il y a peut-être des contextes où il faudra utiliser des composants spécialisés (je pense à l'affichage de haut en bas)
  • la construction actuelle des éditions repose sur un encodage Unicode, XML ou XML-TEI. Il faudra s'assurer que tous les systèmes d'écriture peuvent en profiter

Enfin, il y aura toujours des langues et systèmes d'écriture à prendre en charge en dehors d'Unicode :

• caractères d'ancien Français (Graal), Norvégien (Menota), Russe (Scat), Égyptien (Liège), Akkadien (Paris)…

Description de la méthode de travail pour atteindre l'objectif

[Voir également le composants de tokenisation.]

En texte brut, la tokenization utilise les classes Unicode en différenciant les espaces des ponctuations faibles ou fortes.

Pour le chinois (ZH) ou l'arabe (AR), entre autres, cela ne suffit pas.

En chinois, à défaut de segmenter au niveau des mots, il est intéressant de segmenter systématiquement au niveau des idéogrammes (caractères Unicode) :

• ça permet d'envisager un lexique de mots, ou préfixes ou parties de mots (plutôt que de phrases complètes - inutiles dans un tel contexte)
• ça permet d'exprimer des recherches de mots par composition de mots-TXM, l'inverse n'étant pas possible, pas pertinent ou pas pratique du tout

Pour le tibétain (BO), il peut-être intéressant de donner un rôle d'espace à un rôle initial de type virgule (caractère) pour faciliter les recherches plein texte, tout en maintenant l'affichage du caractère dans l'édition (ou pas).
Il s'agit du caractère TSHEG :

U+0F0B TIBETAN MARK INTERSYLLABIC TSHEG
http://codepoints.net/U+0F0B
Unicode class: 'Other Punctuation' of name 'Po'.

Pour un corpus Akkadien, comme cela pourrait être fait pour tout système d'écriture alphabétique, il a été intéressant de développer une double-stratégie de tokenization : niveau mots ou niveau syllabes.

• Langues indo-européennes : les technologies utilisées par TXM gérent ces langues entièrement, en particulier le Français et ses diacritiques et ligatures
• Arabe : voir la section Objectifs pour un aperçu de ce que fait déjà TXM

• Langues indo-européennes : je ne sais pas si on peut déjà, et comment, saisir un c-cédille (ç) avec un clavier américain dans TXM
• Arabe : voir la section Objectifs pour un aperçu de ce que fait déjà TXM

• Langues indo-européennes : les technologies utilisées par TXM gérent ces langues entièrement
• Arabe : voir la section Objectifs pour un aperçu de ce que fait déjà TXM

• Langues indo-européennes : il faut construire un environnement linguistique ayant un catalogue de langues prises en charge
• Arabe : on commence à regarder le Stanford Log-linear Part-Of-Speech Tagger

Technologies :

• https://github.com/CLD2Owners/cld2