Skip to content

Annotation multilingue et pour langues peu dotées

Annoter dans des langues autres que l'anglais : le fossé de la diversité, les méthodes participatives avec des locuteurs natifs et comment localiser l'interface de Potato avec la prise en charge de la droite vers la gauche, les polices et les libellés traduits.

Annoter dans une langue autre que l'anglais, c'est deux problèmes à la fois. Le problème scientifique : la plupart des ressources en TAL couvrent une poignée de langues, les catégories ne se transfèrent pas proprement d'une culture à l'autre, et il vous faut de vrais locuteurs, pas seulement des personnes bilingues, pour produire de bons libellés. Le problème pratique : faire en sorte que l'outil affiche correctement la langue, y compris les écritures de droite à gauche et les polices non latines. Potato règle le second par la configuration ; le premier, c'est à vous de le gérer. Ce guide couvre les deux.

Le fossé de la diversité est réel et immense

Il existe environ 7 000 langues dans le monde et le TAL n'en sert vraiment que quelques dizaines. Joshi et al. (2020) l'ont quantifié : un petit nombre de langues disposent de données annotées en abondance, tandis que l'immense majorité, parlée par des milliards de personnes, n'en a presque aucune, et le fossé s'auto-entretient parce que les ressources affluent vers les langues qui en possèdent déjà. L'annotation est généralement le goulot d'étranglement. Si vous voulez qu'un modèle fonctionne dans une langue peu dotée, quelqu'un doit y annoter des données, et c'est dans cette annotation que la qualité se gagne ou se perd.

Annotez avec la communauté linguistique, pas seulement dans la langue

Le réflexe est d'embaucher des travailleurs de foule bilingues bon marché et de traduire un guide en anglais. Ces deux choix sont risqués. Bird (2020) s'oppose aux approches extractives qui traitent une communauté linguistique comme une source de données, et le modèle participatif du projet Masakhane (Nekoto et al., 2020) montre que l'alternative fonctionne à grande échelle pour les langues africaines : les locuteurs natifs contribuent à concevoir la tâche, à rédiger les consignes et sont propriétaires des libellés, plutôt que de valider des décisions prises ailleurs. Deux conséquences pratiques :

  • Recrutez des locuteurs courants, idéalement de la bonne variété. Une langue n'est pas monolithique ; le dialecte, la région et le registre comptent, et un locuteur d'une variété peut mal annoter une autre. Bilingue n'est pas synonyme de natif.
  • Ne supposez pas que les catégories se transfèrent. Le sentiment, le caractère offensant, la politesse et même les types d'entités nommées sont culturellement spécifiques. Un guide qui fonctionne pour la politesse en anglais peut se briser en silence dans une langue où la politesse est encodée grammaticalement. Faites en sorte que les locuteurs adaptent le schéma, pas seulement qu'ils traduisent les mots. C'est une décision de conception de schéma, pas une tâche de traduction.

Localiser l'interface de Potato

La moitié pratique. Potato localise l'interface destinée à l'annotateur par la configuration, sans modification du code, même s'il vaut la peine d'en connaître les limites au préalable.

Texte de l'interface. Le bloc ui_language est une table de chaînes pour les éléments de l'interface. Définissez la langue du document et traduisez les boutons et les titres que voit l'annotateur :

yaml
ui_language:
  html_lang: ar
  html_dir: rtl            # right-to-left for Arabic, Hebrew, etc.
  submit_button: "إرسال"
  instructions_heading: "التعليمات"

Définir html_dir: rtl inverse tout le document pour les écritures de droite à gauche en s'appuyant sur la gestion bidirectionnelle native du navigateur. Une limite qu'il faut assumer : ui_language couvre les écrans principaux d'annotation et de connexion, mais plusieurs pages côté administration (le tableau de bord, l'arbitrage, la formation et les écrans de déconnexion) restent uniquement en anglais, alors prévoyez cela si vos annotateurs doivent les voir.

Polices pour les écritures non latines. Les navigateurs ne fournissent pas toujours une bonne police par défaut pour les écritures CJK, arabe ou indiennes. Chargez-en une via une feuille de style de projet avec base_css :

yaml
base_css: "css/noto_font.css"

Données non anglaises. Potato lit les fichiers de données en UTF-8 par défaut et affiche n'importe quel caractère Unicode dans le champ de texte, si bien que le contenu non anglais s'affiche tel quel. Si un fichier utilise un autre encodage, surchargez-le fichier par fichier (encoding:) ou globalement (data_directory_encoding:).

Libellés traduits. C'est le seul piège subtil. Par défaut, Potato « humanise » les noms de libellés, en les reformatant et en mettant une majuscule initiale, ce qui peut dénaturer les écritures non latines. Conservez des valeurs name en anglais lisibles par la machine pour vos données, et montrez à l'annotateur un libellé traduit avec displayed_label, en désactivant l'humanisation :

yaml
annotation_schemes:
  - name: sentiment
    annotation_type: radio
    description: "ما هو شعور هذا النص؟"
    humanize_labels: false
    labels:
      - name: positive
        displayed_label: "إيجابي"
      - name: negative
        displayed_label: "سلبي"
      - name: neutral
        displayed_label: "محايد"

L'annotation enregistrée reste positive, de sorte que vos données restent propres pendant que l'annotateur travaille entièrement en arabe.

Consignes et consentement. Rédigez vos pages de consentement et de consignes surveyflow directement dans la langue cible ; ce sont des fichiers HTML que vous écrivez vous-même, sans rien qui impose l'anglais. Pour exécuter la même tâche dans plusieurs langues, Potato fournit un utilitaire setup_multilingual_config.py qui génère des configurations par langue à partir d'un modèle.

Pour aller plus loin