Mehrsprachige Bot-Antworten von Anfang an planen

„Ein Tickets wurden geschlossen“ ist verständlich, wirkt aber unfertig. Schwieriger wird es, wenn eine übersetzte Schaltfläche eine andere Handlung verspricht als die ursprüngliche Version oder eine Datumsangabe in zwei Sprachen unterschiedlich gelesen wird. Mehrsprachigkeit ist deshalb kein letzter Austausch von Textdateien. Sie betrifft die Struktur einer Antwort, die Auswahl ihrer Sprache und die Bedeutung aller eingesetzten Werte. Für einen Bot mit Dashboard müssen diese Entscheidungen über mehrere Oberflächen hinweg zusammenpassen.

Yurna besitzt im untersuchten Quellstand ein gemeinsames Übersetzungspaket mit Deutsch und Englisch. Die Konfiguration legt Englisch als Standardsprache fest. Der kleine Übersetzer löst verschachtelte Schlüssel auf, ersetzt benannte Platzhalter und fällt bei fehlenden Texten zunächst auf eine alternative Nachrichtensammlung, danach auf den Schlüssel selbst zurück. Diese Mechanismen sind konkret vorhanden. Sie garantieren noch keine vollständig übersetzte Anwendung. Der Artikel beschreibt, wie daraus ein systematischer Entwurf für neue Antworten und eine überprüfbare Erweiterung entstehen kann.

Die Sprache nach dem Publikum wählen

Eine persönliche Antwort kann sich an der Sprache der aufrufenden Person orientieren. Eine öffentliche Nachricht in einem gemeinsamen Kanal braucht dagegen eine andere Regel. Wenn jede Person durch einen Klick die Sprache einer für alle sichtbaren Nachricht verändert, wird die Oberfläche unruhig und schwer vorhersehbar. Der Entwurf verwendet deshalb für persönliche Rückmeldungen eine Nutzerpräferenz und für gemeinsame dauerhafte Inhalte eine Serverpräferenz. Eine Standardsprache greift nur, wenn die jeweils passende Präferenz fehlt oder nicht unterstützt wird.

Diese Rangfolge gehört an eine zentrale Stelle. Ein Befehl sollte nicht die Browsersprache, ein anderer die Servereinstellung und ein dritter zufällig Englisch verwenden, ohne dass die unterschiedliche Wahl begründet ist. Die aufrufende Funktion kennt das Publikum und fordert die passende Übersetzung an. Das Übersetzungspaket liefert den Text. So bleibt die fachliche Entscheidung über Sichtbarkeit und Sprache beim Vorgang, während die technische Auflösung der Texte wiederverwendbar bleibt.

Yurnas Sprachkonfiguration nennt ein Cookie für die serverseitige Darstellung und eine lokale Spiegelung für den Browser. Für den Entwurf muss geklärt sein, welche Quelle bei widersprüchlichen Werten Vorrang hat. Eine Seite sollte nicht zunächst auf Englisch erscheinen und unmittelbar nach dem Laden ohne bewusste Handlung auf Deutsch springen, wenn die gespeicherte Präferenz bereits serverseitig bekannt ist. Auch die Synchronisation über Geräte hinweg braucht eine definierte Aktualisierung, statt mehrere gleichberechtigte Wahrheiten zu erzeugen.

Ganze Aussagen statt zusammengesetzter Wortstücke

Eine Antwort sollte als vollständiger Satz übersetzt werden. Das Zusammenkleben von „Ticket“, einer Zahl und „geschlossen“ funktioniert vielleicht in einer Sprache und scheitert in einer anderen an Wortstellung oder Beugung. Benannte Platzhalter ermöglichen, dieselben fachlichen Werte an unterschiedlichen Stellen einzusetzen. Dabei bleibt der Schlüssel stabil, während der Satz sprachlich frei gestaltet werden kann. Die Übersetzung soll die gleiche Wirkung erklären, nicht dieselbe Zeichenfolge nachbilden.

Für das Beispiel bestätigt Yurna den Abschluss eines Tickets. Die Nachricht enthält die Ticketnummer und den Namen der zuständigen Person. Der Name ist ein eingesetzter Wert, kein Teil des Übersetzungsschlüssels. Ein zusätzlicher Grund kann als eigener klar abgegrenzter Text erscheinen. So müssen Übersetzungen keine beliebigen fremden Inhalte grammatisch in jeden Satz einpassen. Gerade längere benutzerdefinierte Gründe sind oft besser als eigener Absatz aufgehoben als mitten in einer komplizierten Vorlage.

// Beispielhafte Nachrichtenstruktur für einen begrenzten Vorgang.
const messages = {
  ticket: {
    closed: "Ticket {number} wurde geschlossen.",
    waiting: "Wir warten auf deine Antwort zu Ticket {number}.",
    closeFailed: "Ticket {number} konnte noch nicht geschlossen werden.",
  },
};

Die drei Schlüssel bezeichnen verschiedene Zustände. Sie sollten nicht aus einer gemeinsamen Erfolgsvorlage mit optionalem Wort „nicht“ erzeugt werden. Ein Fehler kann einen anderen nächsten Schritt benötigen als eine wartende Bearbeitung. Vollständige Nachrichten geben Übersetzenden den nötigen Kontext und erlauben natürliche Formulierungen. Gleichzeitig bleibt für die Entwicklung erkennbar, welche fachlichen Ergebnisse überhaupt eine Antwort besitzen. Fehlt ein Fehlertext, fällt das bereits bei der Sammlung der Zustände auf.

Platzhalter als Vertrag behandeln

Eine Übersetzung kann sprachlich gut und technisch unvollständig sein, wenn ein benötigter Platzhalter fehlt oder falsch benannt ist. Der einfache Yurna-Übersetzer ersetzt benannte Werte anhand eines Musters. Für die Qualitätssicherung wird deshalb geprüft, ob die Sprachversionen dieselben erforderlichen Platzhalter verwenden. Ein Tippfehler im Namen darf nicht erst im echten Ticket als sichtbare Klammerfolge auftauchen. Solche Prüfungen sind klein und schützen einen konkreten fachlichen Vertrag.

Die Werte selbst brauchen eine passende Behandlung für das Ausgabemedium. Ein Benutzername kann Zeichen enthalten, die in Discord-Markdown eine besondere Bedeutung besitzen. Eine Webansicht behandelt fremde Texte wiederum anders als eine Nachricht. Deshalb sollte die Übersetzungsfunktion nicht pauschal sämtliche Werte für jedes Medium gleich verändern. Der Entwurf trennt Textübersetzung von sicherer Darstellung. Die aufrufende Oberfläche weiß, ob sie gewöhnlichen Text, Markdown oder einen begrenzten formatierten Inhalt ausgibt.

Platzhalter sollten aussagekräftige Namen besitzen. „count“ oder „ticketNumber“ erklärt mehr als „value1“. Das erleichtert die Übersetzung und reduziert Vertauschungen. Gleichzeitig sind zu viele Platzhalter in einem Satz ein Warnsignal. Wenn eine Meldung sechs Werte mit unterschiedlichen grammatischen Rollen verbindet, ist eine Aufteilung möglicherweise verständlicher. Gute Internationalisierung verbessert dadurch häufig auch die Ausgangssprache. Sie zwingt dazu, Bedeutung und Struktur einer Meldung klarer zu formulieren.

Mehrzahl und Zahlen getrennt lösen

Die Auswahl einer Mehrzahlform ist nicht in jeder Sprache auf genau eins und alles andere begrenzt. Für einen erweiterbaren Entwurf sollte diese Entscheidung deshalb nicht durch verstreute einfache Bedingungen in jedem Befehl erfolgen. Die MDN-Dokumentation zu Intl.PluralRules beschreibt eine dafür vorgesehene sprachabhängige Auswahl. Yurnas einfacher Interpolationsmechanismus führt solche Formen nicht automatisch ein; eine entsprechende Erweiterung müsste ausdrücklich gestaltet werden.

Im Beispiel meldet eine Verwaltungsübersicht die Anzahl offener Tickets. Für null kann ein natürlicher eigener Satz sinnvoll sein: Es gibt derzeit keine offenen Tickets. Für eins und mehrere werden passende Formen gewählt. Der Entwurf zeigt damit nicht nur eine grammatische Variante, sondern unterstützt Orientierung. Eine leere Liste erhält eine verständliche Erklärung statt einer isolierten Null. Die fachliche Bedeutung bleibt in allen Sprachen gleich, auch wenn die konkreten Sätze unterschiedlich aufgebaut sind.

Zahlenformatierung ist eine zusätzliche Aufgabe. Tausendertrennzeichen und Dezimaldarstellung sollten nicht manuell durch beliebige Ersetzungen erzeugt werden. MDN beschreibt Intl.NumberFormat als sprachabhängige Formatierung. Für XP oder Coinbestände wird zuerst der tatsächliche Zahlenwert bestimmt und erst für die Anzeige formatiert. Ein bereits formatierter Text gehört nicht zurück in Berechnungen. Dadurch bleiben Daten und Darstellung getrennt und ein Sprachwechsel verändert keine fachlichen Werte.

Datum, Dauer und Zeitzone bewusst anzeigen

Ein Ticket kann zu einem eindeutigen Zeitpunkt geschlossen worden sein, während die Anzeige je nach Sprache anders aussieht. Sprache und Zeitzone sind dabei nicht dasselbe. Eine deutschsprachige Person kann sich in einer anderen Zeitzone befinden, und ein internationaler Server kann eine gemeinsame Anzeigezone festlegen. Der Entwurf entscheidet deshalb beide Aspekte ausdrücklich. Ein Datumsformat darf nicht unbemerkt die Annahme enthalten, dass alle Menschen mit derselben Sprache denselben lokalen Tag sehen.

Für eine persönliche Detailansicht kann die lokale Anzeige sinnvoll sein. Für eine gemeinsame Planung sollte zusätzlich eine eindeutig verständliche Zeitbasis erkennbar bleiben. Die Dokumentation zu Intl.DateTimeFormat beschreibt die entsprechenden Formatierungsoptionen. Die eigene Anwendung muss weiterhin festlegen, welche Option zum Publikum passt. Eine korrekt formatierte Zahl ist noch keine verständliche Terminangabe, wenn ihre Zeitzone oder ihr Bezug unklar bleibt.

Dauern benötigen ebenfalls Kontext. „In zwei Stunden“ ist für eine aktuelle Erinnerung hilfreich, verliert aber in einem exportierten Transkript seinen Bezug. Dort ist ein vollständiger Zeitpunkt besser. „Seit zwei Stunden offen“ beschreibt wiederum eine andere Richtung als „endet in zwei Stunden“. Übersetzungsschlüssel sollten diese Bedeutungen trennen. Eine allgemeine Vorlage „zwei Stunden“ kann nicht zuverlässig ausdrücken, ob ein Zustand vergangen, laufend oder künftig ist. Präzise Ausgangstexte verhindern spätere sprachliche Verrenkungen.

Rückfälle sichtbar, aber nicht störend gestalten

Ein fehlender Übersetzungsschlüssel sollte nicht zu einer leeren Schaltfläche führen. Yurnas Rückfall auf Standardsprache und schließlich Schlüssel macht Lücken zumindest erkennbar. Für die Entwicklung ist das hilfreich. Für eine veröffentlichte Oberfläche bleibt ein roher Schlüssel jedoch ein Qualitätsfehler, der gezielt gefunden werden sollte. Der Rückfall ist eine letzte Absicherung und kein Ersatz für die Prüfung der tatsächlich verwendeten Nachrichtensammlung.

Die Qualitätssicherung kann Schlüssel zwischen Sprachen vergleichen und unbenutzte Einträge gesondert untersuchen. Ein fehlender Schlüssel ist klarer als eine absichtlich unterschiedliche Satzstruktur. Deshalb wird nicht jede Textabweichung als Problem gewertet. Die Prüfung konzentriert sich auf vorhandene Zustände, benötigte Platzhalter und zulässige Ausgabetypen. Eine ältere nicht mehr verwendete Meldung kann entfernt werden, wenn keine Funktion mehr darauf verweist. So bleibt die Sammlung überschaubar und Übersetzungsarbeit zielgerichtet.

Rückfalltexte sollten außerdem nicht während eines einzigen Vorgangs beliebig die Sprache wechseln. Wenn ein ganzer neuer Funktionsbereich noch nicht übersetzt ist, kann eine konsistente Standardsprache verständlicher sein als eine Mischung pro Satz. Welche Strategie gewählt wird, hängt vom Veröffentlichungsumfang ab. Wichtig ist, dass die Person weiterhin den Vorgang versteht. Eine halb übersetzte kritische Bestätigung verdient vor der Freigabe mehr Aufmerksamkeit als ein selten gelesener dekorativer Hilfetext.

Längere Texte im tatsächlichen Layout prüfen

Eine Übersetzung kann deutlich mehr Platz benötigen als ihr Ausgangstext. Ein knapp bemessener Knopf, eine Rangkarte oder eine eingebettete Discord-Nachricht muss damit umgehen können. Die Lösung ist nicht automatisch eine schlechter verständliche Abkürzung. Zuerst wird geprüft, ob das Layout mehr Raum oder einen sinnvollen Umbruch erlauben kann. Besonders wichtige Handlungen sollten nicht auf ein mehrdeutiges einzelnes Wort reduziert werden, nur weil die ursprüngliche Sprache zufällig kurz war.

Für den Ticketabschluss werden deshalb beide Sprachversionen in der tatsächlichen Oberfläche betrachtet. Lange Anzeigenamen und größere Ticketnummern kommen hinzu. Der Test prüft, ob Buttons vollständig lesbar sind, Fehlermeldungen nicht abgeschnitten werden und die nächste Handlung in beiden Sprachen eindeutig bleibt. Eine künstlich verlängerte Testübersetzung kann zusätzliche Layoutgrenzen sichtbar machen, ersetzt aber keine sprachliche Kontrolle. Technische Breite und natürliche Formulierung sind zwei verschiedene Qualitätsmerkmale.

Die abschließende Prüfung verwendet persönliche und öffentliche Antworten, fehlende Präferenzen, unbekannte Sprachwerte, null und mehrere Tickets sowie absichtlich fehlende Platzhalter. Ein Sprachwechsel darf keine fachliche Aktion erneut auslösen und keine ungespeicherten Einstellungen verlieren. Wenn diese Fälle halten, wird Mehrsprachigkeit zu einer stabilen Eigenschaft der Anwendung. Yurnas gemeinsames Paket bietet dafür einen klaren Ausgangspunkt. Der entscheidende Schritt ist, Sprache als Teil jeder vollständigen Antwort zu planen, statt sie erst nach der Funktion anzukleben.