Drei häufige i18n-Fehler in Open-Source-LMS – und wie man sie vermeidet

Internationale Bildungsplattformen stehen vor einer scheinbar einfachen Aufgabe: Sie müssen Inhalte in mehreren Sprachen zugänglich machen. Doch die Realität zeigt: Die meisten Open-Source-LMS-Projekte (Learning Management Systems) scheitern an grundlegenden Internationalisierungsfehlern. Diese Fehler betreffen nicht nur die Oberfläche, sondern die gesamte Architektur der Plattform – und führen zu nutzerunfreundlichen oder sogar fehlerhaften Inhalten.

Nach fünfmonatiger Entwicklungsarbeit an einem Open-Source-LMS für Bibelschulen mit Unterstützung für Russisch, Englisch und bald Ukrainisch wurde klar: Die größten Herausforderungen lagen nicht im Code selbst, sondern in der falschen Behandlung von Sprachinhalten. Die Analyse führender Systeme wie Moodle, Open edX, Canvas LMS und Chamilo zeigte ein einheitliches Muster – und die gleichen Schwachstellen wie in unserem eigenen Projekt zu Beginn.

Falsche Annahme: Nutzerinhalte sind wie Oberflächenstrings

Die meisten LMS-Projekte setzen auf gettext oder ähnliche Systeme, um Benutzeroberflächen zu übersetzen. Texte wie "Anmelden", "Kurskatalog" oder "Aufgabe einreichen" werden in .po-Dateien oder Übersetzungsdiensten wie Transifex verwaltet. Ein Übersetzer übersetzt die Datei einmal – und die Oberfläche ist in allen Sprachen verfügbar. Doch diese Mechanismen versagen bei nutzergenerierten Inhalten.

Stellen Sie sich vor, ein Dozent erstellt einen Kurs mit dem Titel "Введение в Послание к Римлянам". Ein englischsprachiger Student sieht diesen Titel in kyrillischer Schrift – obwohl die Benutzeroberfläche perfekt ins Englische übersetzt ist. Das Problem: Die Oberfläche ist lokalisiert, der Inhalt nicht.

Die gängige Lösung – etwa Moodles multilang-Filter – zwingt Lehrkräfte dazu, jeden Inhalt in jeder Sprache zu verfassen. Ein unmögliches Unterfangen. Stattdessen braucht es ein separates Übersetzungssystem für nutzergenerierte Inhalte. Eine Datenbankstruktur wie diese trennt Übersetzungsmanagement von der ursprünglichen Inhaltserstellung:

CREATE TABLE content_translations (
  entity_type TEXT NOT NULL,       -- 'course', 'lesson', 'quiz_question'
  entity_id UUID NOT NULL,         -- Eindeutige ID des Inhalts
  field TEXT NOT NULL,             -- 'title', 'description', 'body'
  locale TEXT NOT NULL,            -- 'ru', 'en', 'uk', 'es'
  content TEXT NOT NULL,           -- Übersetzter Inhalt
  source TEXT NOT NULL,            -- 'human' | 'machine' | 'canonical'
  cached_at TIMESTAMPTZ NOT NULL,  -- Zeitstempel der Übersetzung
  PRIMARY KEY (entity_type, entity_id, field, locale)
);

Der Workflow: Ein Dozent erstellt einen Kurs in einer Sprache. Ein Übersetzungsdienst (maschinell oder manuell) füllt die Lücken in den anderen Sprachen – entweder sofort bei Veröffentlichung oder bei der ersten Anfrage. Die API der Plattform fragt dann gezielt nach der passenden Übersetzung und liefert sie aus.

Die zentrale Erkenntnis: Nutzerinhalte sind keine Oberflächenstrings. Sie erfordern ein eigenes Übersetzungssystem mit Cache-Mechanismen und flexiblen Quellen.

Sprachlängen werden ignoriert – bis es zu spät ist

Englische Texte sind oft kompakt. Doch schon Russisch benötigt 25–30 % mehr Platz für dieselbe Aussage. Arabisch ist kürzer – aber rechtsbündig geschrieben. Finnisch kann noch länger sein. Diese Unterschiede führen zu Layout-Problemen, wenn die Software nur für englischsprachige Nutzer getestet wird.

Ein Button mit dem Text "Save" passt problemlos in die Benutzeroberfläche. Doch sein russisches Pendant "Сохранить" überlappt möglicherweise mit benachbarten Elementen oder bricht in eine zweite Zeile um. Mobile Ansichten leiden unter solchen Designentscheidungen am stärksten.

Teilweise lässt sich das Problem mit CSS beheben:

/* Reserviert ausreichend Platz für längere Sprachen */
.action-button {
  min-width: 8rem;
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;
}

/* Verhindert Layout-Verschiebungen bei mehrzeiligen Titeln */
.lesson-list-cell {
  min-height: 4.5rem; /* Platz für zweizeilige russische Titel */
}

Doch der eigentliche Schlüssel liegt im systematischen Testen. Die meisten Entwicklungsteams arbeiten mit Designern, die nur englische Mockups sehen. Die ersten Hinweise auf Layout-Probleme kommen oft erst von Nutzern – und dann ist es zu spät.

Eine bessere Praxis: Ein Storybook mit Sprachumschalter, der standardmäßig Russisch anzeigt. Automatisierte Tests – etwa mit Playwright – erfassen Screenshots für alle unterstützten Sprachen. So werden Layout-Probleme bereits in der Continuous Integration erkannt, bevor sie Nutzer erreichen.

Kanonische Inhalte werden falsch übersetzt – oder erfunden

Dieser Fehler war der Auslöser für die gesamte Überarbeitung unseres Übersetzungssystems. Stellen Sie sich vor, ein Dozent schreibt auf Russisch: "Послание к Римлянам 8:28 говорит, что все содействует ко благу". Die Plattform übersetzt den gesamten Satz automatisch ins Englische – und liefert zurück: "Romans 8:28 says that everything works together for good."

Doch das ist kein Zitat aus einer anerkannten Bibelübersetzung. Es ist eine Übersetzung einer Übersetzung – und damit wertlos für theologische Inhalte. Genau hier liegt das Problem: Kanonische Inhalte wie Bibelverse, Gesetzestexte, medizinische Referenzen oder originale Literaturzitate dürfen nicht übersetzt werden. Sie müssen durch autoritative Quellen ersetzt werden.

Gleiche Probleme treten in anderen Bereichen auf:

• Programmierkurse mit Codebeispielen (Variablennamen nicht übersetzen!)
• Mathematiklehrgänge mit Formeln
• Rechtliche Kurse mit Gesetzeszitaten
• Medizinische Kurse mit klinischen Studiennummern
• Literaturkurse mit Originalzitaten

Die Lösung: Trennung von übersetzbarem Fließtext und kanonischen Referenzen. Ein Algorithmus identifiziert zunächst alle Referenzen – etwa Bibelverse –, ersetzt sie durch Platzhalter, übersetzt dann den umgebenden Text und fügt die kanonischen Inhalte aus einer separaten Datenbank zurück ein.

def translate_with_canonical_preservation(
    text: str,
    source_lang: str,
    target_lang: str
) -> str:
    # 1. Kanonische Referenzen extrahieren
    refs = extract_bible_refs(text, lang=source_lang)
    # [{'raw': 'Послание к Римлянам 8:28', 'book': 'ROM', 'chapter': 8, 'verses': [28]}]

    # 2. Jede Referenz durch einen Platzhalter ersetzen
    placeholders = {}
    for i, ref in enumerate(refs):
        token = f"⟦CANON_{i}⟧"
        placeholders[token] = ref
        text = text.replace(ref["raw"], token, 1)

    # 3. Den Text übersetzen
    translated = translate(text, source_lang, target_lang)

    # 4. Platzhalter durch die kanonischen Inhalte der Zielsprache ersetzen
    for token, ref in placeholders.items():
        translated = translated.replace(
            token,
            get_canonical_text(ref, target_lang)
        )

    return translated

Diese Methode stellt sicher, dass kanonische Inhalte immer korrekt und in der richtigen Sprache angezeigt werden – unabhängig davon, in welche Sprache der umgebende Text übersetzt wird.

Fazit: Internationalisierung ist kein Feature, sondern eine Architekturentscheidung

Die drei beschriebenen Fehler – verwechselte Inhaltsarten, ignorierte Sprachlängen und verlorene kanonische Texte – sind keine kleinen Unzulänglichkeiten, sondern systemische Probleme. Sie führen zu nutzerunfreundlichen, fehleranfälligen oder sogar theologisch ungenauen Inhalten.

Doch die Lösung ist nicht kompliziert: Trennen Sie Nutzerinhalte von Oberflächenstrings, testen Sie Designs für alle unterstützten Sprachen und bewahren Sie kanonische Inhalte in einer separaten Datenbank. Wer diese Prinzipien von Anfang an berücksichtigt, spart sich später kostspielige Nachbesserungen – und schafft eine wirklich barrierefreie Lernplattform für Nutzer weltweit.