Skip to content

Annotation in mehreren und in wenig ausgestatteten Sprachen

Annotieren jenseits des Englischen: die Ressourcenlücke, partizipative Verfahren mit Muttersprachlern und wie du die Potato-Oberfläche lokalisierst, mit Rechts-nach-links-Unterstützung, Schriftarten und übersetzten Labels.

Wer in einer anderen Sprache als Englisch annotiert, hat es mit zwei Problemen zugleich zu tun. Das wissenschaftliche: Die meisten NLP-Ressourcen decken eine Handvoll Sprachen ab, Kategorien lassen sich nicht sauber von einer Kultur in die andere übertragen, und für gute Labels brauchst du echte Sprecherinnen und Sprecher, nicht bloß zweisprachige Personen. Das praktische: die Sprache im Werkzeug korrekt darzustellen, samt Rechts-nach-links-Schriften und nichtlateinischen Fonts. Das zweite erledigt Potato über die Konfiguration, das erste bleibt an dir. Dieser Leitfaden behandelt beides.

Die Ressourcenlücke ist real und groß

Es gibt weltweit rund 7.000 Sprachen, und NLP bedient davon einige Dutzend ernsthaft. Joshi et al. (2020) haben das beziffert: Für wenige Sprachen gibt es gelabelte Daten im Überfluss, für die allermeisten, gesprochen von Milliarden Menschen, fast keine, und die Lücke verstärkt sich selbst, weil Ressourcen dorthin fließen, wo schon welche sind. Der Engpass liegt meist bei der Annotation. Wenn ein Modell in einer wenig ausgestatteten Sprache funktionieren soll, muss jemand Daten darin labeln, und an dieser Stelle entscheidet sich die Qualität.

Mit der Sprachgemeinschaft annotieren, nicht nur in ihrer Sprache

Der erste Impuls ist, günstige zweisprachige Crowdworker anzuheuern und eine englische Richtlinie zu übersetzen. Beides ist heikel. Bird (2020) wendet sich gegen extraktive Ansätze, die eine Sprachgemeinschaft als Datenquelle behandeln, und das partizipative Modell des Masakhane-Projekts (Nekoto et al., 2020) zeigt, dass die Alternative für afrikanische Sprachen im großen Maßstab trägt: Muttersprachlerinnen und Muttersprachler entwerfen die Aufgabe mit, schreiben die Richtlinien und verantworten die Labels, statt anderswo getroffene Entscheidungen zu bestätigen. Daraus folgt zweierlei:

  • Wirb fließende Sprecher an, möglichst der passenden Varietät. Eine Sprache ist kein Monolith, Dialekt, Region und Register spielen eine Rolle, und wer eine Varietät spricht, labelt eine andere womöglich falsch. Zweisprachig ist nicht dasselbe wie muttersprachlich.
  • Setz nicht voraus, dass Kategorien übertragbar sind. Sentiment, Beleidigung, Höflichkeit und selbst Typen von Eigennamen sind kulturell geprägt. Eine Richtlinie, die für englische Höflichkeit taugt, kann in einer Sprache, in der Höflichkeit grammatisch kodiert ist, unbemerkt danebengehen. Lass Sprecher das Schema anpassen, nicht nur die Wörter übersetzen. Das ist eine Frage des Schemaentwurfs, keine Übersetzungsaufgabe.

Mehrere Showcase-Aufgaben bilden solche mehrsprachigen Daten nach und eignen sich als Einstieg: sprachübergreifende Natural Language Inference in 15 Sprachen (XNLI), Übersetzungsqualität über 200 Sprachen (FLORES) und Sentiment für indonesische Regionalsprachen (NusaX).

Die Potato-Oberfläche lokalisieren

Nun die praktische Hälfte. Potato lokalisiert die Oberfläche für Annotierende über die Konfiguration, ohne Codeänderungen, wobei du die Grenzen vorher kennen solltest.

Text der Oberfläche. Der Block ui_language ist eine Zeichenketten-Tabelle für den Rahmen der Oberfläche. Setz die Dokumentsprache und übersetze die Schaltflächen und Überschriften, die Annotierende sehen:

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

Mit html_dir: rtl kippt das ganze Dokument für Rechts-nach-links-Schriften, über die eingebaute bidirektionale Behandlung des Browsers. Eine Einschränkung, die man kennen sollte: ui_language deckt die zentralen Annotations- und Login-Seiten ab, mehrere Verwaltungsseiten (Dashboard, Adjudikation, Training und Logout) sind aber weiterhin nur auf Englisch. Plane das ein, wenn deine Annotierenden dort hinkommen.

Schriftarten für nichtlateinische Schriften. Browser bringen nicht immer eine brauchbare Standardschrift für CJK-, arabische oder indische Schriften mit. Lade eine über ein Projekt-Stylesheet mit base_css:

yaml
base_css: "css/noto_font.css"

Nicht-englische Daten. Potato liest Datendateien standardmäßig als UTF-8 und gibt beliebiges Unicode im Textfeld aus, nicht-englische Inhalte erscheinen also unverändert. Nutzt eine Datei eine andere Kodierung, überschreib sie pro Datei (encoding:) oder global (data_directory_encoding:).

Übersetzte Labels. Hier lauert die eigentliche Falle. Standardmäßig macht Potato Labelnamen „lesbar“, formatiert sie also um und schreibt sie in Großbuchstaben am Wortanfang, was nichtlateinische Schriften entstellen kann. Behalte für deine Daten maschinenlesbare englische names und zeig der annotierenden Person über displayed_label ein übersetztes Label, mit abgeschaltetem Humanizing:

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: "محايد"

Gespeichert wird weiterhin positive, deine Daten bleiben also sauber, während die annotierende Person durchgängig auf Arabisch arbeitet.

Anleitungen und Einwilligung. Schreib die Einwilligungs- und Instruktionsseiten deines surveyflow direkt in der Zielsprache, es sind HTML-Dateien von dir, nichts erzwingt Englisch. Wenn dieselbe Aufgabe in mehreren Sprachen laufen soll, liefert Potato das Hilfsskript setup_multilingual_config.py mit, das aus einer Vorlage Konfigurationen pro Sprache erzeugt.

Weiterführende Lektüre