PlugIn Welches ist der schlaueste Weg, ein Netzwerk mehrsprachig anzubieten?

[LuDom Media]

Moin, wie schon im Titel des Threads steht, wollte ich mal fragen, wie man es am schlauesten anstellt, ein gesamtes Netzwerk mehrsprachig zu programmieren.

Kurz dazu, wie ich mir das etwa vorstelle:
Man würde bei seinem first Join, wenn die Sprache des Clients nicht Deutsch ist, gefragt werden, ob man die Sprache des Clients auch als Serversprache verwenden möchte (sofern dieses Sprachpaket serverseitig angeboten wird, ansonsten würde es dann auf Englisch gestellt werden) und wenn ja, würden dann alle Elemente in der gewählten Sprache angezeigt werden. Eigentlich wie bei jedem grossen Netzwerk. Man soll das auch in den Lobbys über einen Befehl umstellen können.

Technisch gesehen würde ich wahrscheinlich eine grosse Datenbank haben, in der alle vom Spielen eingestellten Sachen in einer Tabelle drin sind und da würde die Sprache nun eben dazugehören.

Meine Frage wäre jetzt, wie würdet ihr anstellen, dass bei einer Ausgabe eines Plugins (die werden alle selbst geschrieben werden) die richtige Nachricht in der richtigen Sprache ausgegeben wird?

Also wie komme ich an die Sprachauswahl, ohne jedes Mal erneut auf die DB zugreifen zu müssen?
Und wie stelle ich es an, dass in den einzelnen Plugins mit Variablen und allem, was dazugehört eine Nachricht ausgegeben wird?

Muss ich mit Sprachpaketen arbeiten und jedes mal mit einer Datenbankabfrage pro Spieler und Nachricht (und danach mit Cases) das entsprechende Sprachpaket ausgeben, oder geht es einfacher?


Mir ist bewusst, dass es sich für ein kleineres Netzwerk nicht sonderlich lohnt, aber einerseits will ich, wenn ich eh alles selfcode nicht noch mal alles umschreiben, sollte irgendwan Bedarf sein und andererseits macht es mir irgendwie Spass alles etwas komplexer zu machen als nötig.

Danke im Voraus und n schönes Wochenende
~LuDom Media

 

[Malfrador]

Warum denn eine Datenbank? Sprachdateien als YAML-Dateien sind wunderbar.
Ich würde diese Dateien beim Serverstart lesen (wie eine normale Config) und im RAM lassen, bis sie gebraucht werden. Es ist ja nur Text, mehr als ein paar Megabyte werden da nicht zusammenkommen, wenn überhaupt.
Die Einstellung, welche Sprache jemand ausgewählt hat sollte natürlich in einer Datenbank sein oder anders zwischen den Servern synchronisiert werden. Die Sprachdaten selber aber nicht. Die Sprachauswahl kannst du dann einmal bei Login des Spielers aus der DB abfragen und solange speichern, wie der Spieler online ist.

 

[Chrisliebär❤️]

Das ist ein unfassbar gewaltiges Feld und zudem ein riesen Chaos. Sprachen sind nicht so einfach, wie man glaub. Verschiedene Sprachen nutzen unterschiedliche Geschlechter für Singular oder Plural und in Kombination mit anderen Wortteilen, müssen komplett unterschiedliche Startteile flektiert werden. Das ist ein absoluter Alptraum, wenn man eine Anwendung vollständig lokalisieren möchte. Ich halt davon auch grundsätzlich mehrere Fußballfelder Abstand, aber wenn du dich tiefer mit dem Thema beschäftigen möchtest, das fällt unter die Abkürzung "i18n" (Die Wortherkunft bleibt dem Leser überlasen).

Ich empfehle grundsätzlich sich die bestehenden Werkzeuge anzusehen, so dass man zumindest weiß, welche Probleme auf einen zukommen, danach kannst du noch immer eine einfachere Lösung verwenden. Ansonsten stocherst du aber im Dunkeln und wirst deinen Code mehrfach komplett neu schreiben müssen, da du Randfälle übersehen hast.

Achso und weil mir gerade auffällt, dass das Problem vielleicht nicht offensichtlich ist: Das Problem beginnt, sobald du nicht mehr nur statische Texte ausgeben willst, sondern Variabeln in deine Ausgaben einbaust. Ein paar Beispiele, bei denen das kein Problem ist:

• Du hast gewonnen.
• Dein aktueller Kontostand beträgt: $menge
• Du bist gestorben.

Die Problemfälle:

• Du hast von $spieler $amount $währung erhalten. / You just received $amount $währung from $spieler.
• Du hast einen Gegenstand erhalten / Du hast zehn Gegenstände erhalten.
• Das Event beginnt jeden Tag um 15 Uhr / The event starts every day at 3PM.

Du siehst also: Furchtbar und wenn wir noch asiatische Sprachen dazu packen, ist komplett vorbei.

 

[Baba43]

Es gibt für Java bereits einige Ansätze zur so genannten Internationalisierung (i18n).

Ich würde es, nachdem ich bereits verschiedene Ansätze bei uns ausprobiert habe, so machen:

Jedes Plugin definiert alle Sprachstrings in einem Enum inklusive Default in der Hauptsprache. Diese Strings werden bei uns aktuell in eine YML-Datei geschrieben, aber es wäre besser, sie in eine Datenbank zu schreiben, damit man später einfacher herausfinden kann, wo Übersetzungen fehlen. Zur Verwendung des Enums brauchst Du einen kleinen Helper, damit Platzhalter unterstützt werden können. Das funktioniert bei mir so, dass z. B. "{1,Player}" mit dem ersten Argument an den Aufruf von getText(Text.HELLO_PLAYER, "baba43") ersetzt wird. Der Übersetzer weiß anhand des Namens, was eingefügt wird und kann die Position verändern.

Ein großes Problem in Bezug auf Minecraft betrifft allerdings die interaktiven Texte d. h. TextComponents. Die zusammenzubauen ist immer eine unschöne Angelegenheit. Um das stückweise zu umgehen, haben wir eine kleine "Sprache" entwickelt, welche die TextComponents aus HTML-artigen Tags zusammenbaut. Diese Tags können dann nämlich auch in den Sprachdateien verwendet werden.

Dieser ganze Aufwand war bei uns am Ende übrigens relativ unnötig. Klar ist es schön, dass auch nicht-Entwickler mal den Text ändern können, aber eine wirkliche Internationalisierung haben wir damit nie gemacht. Solange Du nur einen Server betreibst, sehe ich darin auch überhaupt keinen Sinn, denn selbst Du es schaffst, die Systeme zu übersetzen, gibt es ja noch den Chat und alle spielerbezogenen Inhalte. Da die Community auf einem Server wichtiger ist als die Technik, würde ich zwei verschiedene Sprachen nicht auf einem Server spielen lassen. Das ganze Unterfangen ergibt aus meiner Sicht also erst Sinn, wenn Du das Netzwerk wirklich parallel in verschiedenen Sprachen betreiben willst: jeweils mit eigener Webseite, eigenem Forum, eigenem Team usw.

 

[LuDom Media]

Hey! Vielen Dank für eure Antworten. Ich werde mir mal Gedanken zu dem Thema machen, ist wahrscheinlich wirklich etwas komplexer, als ich es mir vorgestellt hatte.

Muss mal schauen, ob ich es mache, da es sich wahrscheinlich im Moment wirklich nicht lohnt. Denke, ich werde mir irgendwie die Schnittstellen einbauen, bzw. dafür sorgen, dass sie eingebaut werden könnten, ohne alles durcheinander zu bringen, aber allein bei den Sprachfiles hört es auf, da unser Team eh nur etwa 5 Sprachen zusammenbekommen würde.

Den einzigen Sinn, den ich im Moment an Sprachfiles sehen würde, ist, dass man bei verschiedenen Events (z.B. Halloween oder Weihnachten) einfach das File tauschen muss, wenn einige Nachrichten anders sein sollen und nicht alle Plugins austauschen muss. Das Austauschen der Plugins wäre meiner Meinung nach (da wir mit nem etwas Mühsamen Cloudsystem arbeiten) unnötiger Aufwand und könnte vermieden werden.

Danke für eure Antworten und noch nen schönen Sonntag euch!
~LuDom Media

 

[JOO200]

Wie @Baba43 bereits richtig erwähnt hat, haben wir für die Konvertierung String -> TextComponent eine eigene Methode geschrieben. Das würde ich aber mit meinem heutigen Wissensstand auch gar nicht mehr selbst schreiben, das gibt es nämlich schon:

MiniMessage — Adventure 4.7.0 documentation

docs.adventure.kyori.net

Allgemein scheint mir Adventure eine ganz interessante Library zu sein und ich werde diese wohl in Zukunft viel intensiver einsetzen. Zumindestens in WorldGuard ist der Einsatz schonmal vorgemerkt, wann genau ich die Zeit dafür habe, wird sich zeigen.

Tatsächlich gibt es dann noch mehrere Tools, um mehrere Sprachen zu speichern.
So detektiert WorldEdit zwischenzeitlich die Sprache vom Client automatisch und nutzt diese, wenn diese von einem entsprechenden Nutzer übersetzt wurde. Was genau dahinter liegt, kann ich aber nicht sagen, dafür hab ich zu wenig damit gearbeitet.

Ein anderes Tool, was mehrere Sprachen unterstützt, ist acf (annotated command framework) von Aikar. Das ist eigentlich ein Framework, um Befehle einfach umzusetzen, unterstützt aber auch mehrere Sprachen inklusive automatische Detektierung.

aikar/commands

Java Command Dispatch Framework - (Bukkit, Spigot, Paper, Sponge, Bungee, JDA, Velocity supported, generically usable anywhere) - aikar/commands

github.com

So viel zum technischen, nun aber, warum ich mich dagegen entschieden habe, das für Terraconia umzusetzen:
Ich habe für Terraconia auch zwischenzeitlich überlegt, ob man nicht mal das Netzwerk auf deutsch und englisch umstellen könnte. Aber:

• Aufgrund des Konzepts würden englisch- und deutschsprachige Spieler gemischt auf gleichen Welten spielen. Für einige Spieler wäre dann die Kommunikation problematisch. Während man sich im RL noch mit Händen und Füßen verständigen kann, geht das in Minecraft nicht ganz so gut.
• Wir nutzen trotz allem einige externe Plugins. Diese auf mehrere Sprachen umzustellen, wäre auch nicht einfach so möglich.
• Die Zielgruppe für die englische Sprache ist kleiner als man glaubt: Amerikanische und australische Spieler würden eine deutlich höhere Latenz haben. Daher glaube ich nicht, dass man sich wirklich so viele Spieler auf den Server holen würde.