More multilingual transfer #146
Keine Reviewer
Label
Kein Label
Bug
Codeverbesserung
Einsteiger Freundlich
Idee
In Arbeit
Neues Feature
Prio A
Security Breach
Überprüfung notwendig
Verbesserung
Zu Beobachten
Kein Meilenstein
Niemand zuständig
2 Beteiligte
Kein Fälligkeitsdatum gesetzt.
Abhängigkeiten
Keine Abhängigkeiten gesetzt.
Referenz: SteamWar/BungeeCore#146
Laden…
In neuem Issue referenzieren
Einen Benutzer sperren
Keine Beschreibung angegeben.
Branch "moreMultiLingual" löschen
Das Löschen eines Branches ist permanent. Obwohl der Branch für eine kurze Zeit weiter existieren könnte, kann diese Aktion in den meisten Fällen NICHT rückgängig gemacht werden. Fortfahren?
Warning: Untested, vor mergen testen!
Signed-off-by: Lixfel agga-games@gmx.de
@ -56,0 +66,4 @@#Various commandsALERT=§f{0}BAN_YOU_BANNED=§7Du hast §e{0} §7gebannt§8. §7Grund§8: §c{1}Der Name ist finde ich etwas irreführend
Vllt besser 'BAN_MESSAGE_YOU'
@ -56,0 +73,4 @@IGNORE_YOURSELF=§cWie willst du dich selber ignorieren?IGNORE_ALREADY=§cDu ignorierst diesen Spieler bereits.IGNORE_IGNORE=§7Du ignorierst nun §e{0}§8.Auch diesen Namen finde ich etwas irreführend
Vllt besser 'IGNORE_MESSAGE'
@ -41,8 +42,6 @@ public class AlertCommand extends BasicCommand {for (String arg : args){msgBuilder.append(arg).append(" ");}Ein 'String.join(" ", args)' würde es auch hier tun
@ -1,5 +1,9 @@PREFIX=§eSteam§8War»UNKNOWN_COMMAND=§cUnbekannter Befehl.Ich würde noch persönlich für alle properties (Keys) also 'UNKNOWN_COMMAND' und so, mehrere Enums machen, sodass es einfacher ist Sachen zu ändern. Sonst muss man immer genau wissen, wo alles dieser Key verwendet wurde um es zu ändern.
Hierbei würde ich für jede Gruppe an Messages ein ENUM machen, also 'Unknown', 'Help', 'Usage', 'Other', 'Ignore' und dann sowas wie 'Ban', 'Mute' oder 'Punishments'
Nein, IntelliJ leitet einen nämlich beim Klicken auf z.B: "UNKNOWN_COMMAND"-String direkt in die Config-Datei weiter, wenn da ein Enum extra eingesetzt wird, welches umständlich gewartet werden muss, geht dieser vorteil verloren.
ok Dann will ich dazu nichts gesagt haben
@ -48,3 +48,3 @@BungeeCore.send(p, BungeeCore.CHAT_PREFIX + "§cDiesen Spieler gibt es nicht.");Message.send("UNKNWON_PLAYER", p);return;}else if(target.equals(user)){Warum sind das hier 'else if' Statements könnte man das nicht einfach alles als einfache 'if' Statements machen. Wo dann mit 'return' immer abgebrochen wird? Ich denke dann kann man das einfacher lesen. Weil es einfach immer ein 'if' dann der Abbruch weil das was sein soll nicht so ist.
@ -51,3 +51,3 @@BungeeCore.send(p, BungeeCore.CHAT_PREFIX + "§cWie willst du dich selber ignorieren?");Message.send("IGNORE_YOURSELF", p);return;}else if(IgnoreSystem.isIgnored(user, target)){s.o.
@ -56,0 +67,4 @@ALERT=§f{0}BAN_YOU_BANNED=§7Du hast §e{0} §7gebannt§8. §7Grund§8: §c{1}BAN_INVALID_TIME=§cUngültige Zeitangabe.Diese ungültige Zeitangabe gibt es auch beim Muten, womit einfach der Key 'INVALID_TIME' genauso gut wäre. Weil die Nachricht soll doch sicher nicht anders sein, wenn ich jemanden Mute im Gegensatz zu Bannen?
@ -56,0 +69,4 @@BAN_YOU_BANNED=§7Du hast §e{0} §7gebannt§8. §7Grund§8: §c{1}BAN_INVALID_TIME=§cUngültige Zeitangabe.BUG_SAVED=§7Dein Bugreport wurde gespeichert.Wenn wir die Ban Message und die Ignore Message so machen wie oben und unten beschrieben sollten wir das hier zu 'BUG_MESSAGE' ändern. Auch wenn die Nachricht das speichern meint sollten wir es dann einheitlich machen. Fände ich auch schöner. Weil dann nicht jedes System sein eigenen Message Namen bekommt für eine einfache Nachricht, die zurück gegeben wird.
Typos etc. wurden soweit gefixt.
Ich kann diesen Pull-Request auf dem Dev Bungee testen oder?
Warum solltest du das nicht können?
Sollte nun auch getestet sein.
Du musst wenn den Review machen, die Sache war ursrpüngllich mal von mir :)