SteamWar/BungeeCore
Archiviert
13
2

More multilingual transfer #146

Manuell gemergt
Lixfel hat 6 Commits von moreMultiLingual nach master 2020-11-28 09:23:21 +01:00 zusammengeführt
6 geänderte Dateien mit 19 neuen und 18 gelöschten Zeilen
Nur Änderungen aus Commit 730b56e4ec werden angezeigt - Alle Commits anzeigen

Datei anzeigen

@ -37,11 +37,6 @@ public class AlertCommand extends BasicCommand {
return;
}
StringBuilder msgBuilder = new StringBuilder();
msgBuilder.append(BungeeCore.CHAT_PREFIX);
for (String arg : args){
msgBuilder.append(arg).append(" ");
}
Message.broadcast("ALERT", ChatColor.translateAlternateColorCodes('&', msgBuilder.toString()));
Message.broadcast("ALERT", ChatColor.translateAlternateColorCodes('&', BungeeCore.CHAT_PREFIX + String.join(" ", args)));
}
}

Datei anzeigen

@ -55,7 +55,7 @@ public class BanCommand extends BasicCommand {
banReason.append(args[i]).append(" ");
}
String msg = banReason.toString();
Message.send("BAN_YOU_BANNED", sender, target.getUserGroup(), msg);
Message.send("BAN_MESSAGE_YOU", sender, target.getUserName(), msg);
target.ban(banTime, msg);
}
@ -73,7 +73,7 @@ public class BanCommand extends BasicCommand {
Date parsedDate = dateFormat.parse(arg.split("_")[0]);
return new java.sql.Timestamp(parsedDate.getTime());
}catch(ParseException exception){
Message.send("BAN_INVALID_TIME", sender);
Message.send("INVALID_TIME", sender);
return null;
}
}

Datei anzeigen

@ -40,6 +40,6 @@ public class BugCommand extends BasicCommand {
String message = String.join(" ", args);
SteamwarUser user = SteamwarUser.get(player.getUniqueId());
SWException.log(server, message, player.getName() + " " + user.getId());
Message.send("BUG_SAVED", player);
Message.send("BUG_MESSAGE", player);
}
}

Datei anzeigen

@ -47,15 +47,17 @@ public class IgnoreCommand extends BasicCommand {
if(target == null){
Message.send("UNKNWON_PLAYER", p);
return;
}else if(target.equals(user)){
}
Review

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.

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.
if(target.equals(user)){
Message.send("IGNORE_YOURSELF", p);
return;
Review

s.o.

s.o.
}else if(IgnoreSystem.isIgnored(user, target)){
}
if(IgnoreSystem.isIgnored(user, target)){
Message.send("IGNORE_ALREADY", p);
return;
}
IgnoreSystem.ignore(user, target);
Message.send("IGNORE_IGNORE", p, target.getUserName());
Message.send("IGNORE_MESSAGE", p, target.getUserName());
}
}

Datei anzeigen

@ -20,6 +20,7 @@
package de.steamwar.bungeecore.commands;
import de.steamwar.bungeecore.BungeeCore;
import de.steamwar.bungeecore.Message;
import de.steamwar.bungeecore.sql.SteamwarUser;
import net.md_5.bungee.api.CommandSender;
@ -34,7 +35,7 @@ public class MuteCommand extends BasicCommand {
@Override
public void execute(CommandSender sender, String[] args) {
if(args.length < 3){
BungeeCore.send(sender, BungeeCore.CHAT_PREFIX + "/mute [Spieler] [dd.mm.yyyy oder dd.mm.yyyy_hh:mm oder perma] [Grund]");
Message.send("USAGE_MUTE", sender);
return;
}
@ -51,7 +52,7 @@ public class MuteCommand extends BasicCommand {
muteReason.append(args[i]).append(" ");
}
String msg = muteReason.toString();
BungeeCore.send(sender, BungeeCore.CHAT_PREFIX + "Du hast " + target.getUserName() + " gemuted. Grund: §c" + msg);
Message.send("MUTE_MESSAGE_YOU", sender, target.getUserName(), msg);
target.mute(muteTime, msg);
}
}

Datei anzeigen

@ -2,6 +2,7 @@ PREFIX=§eSteam§8War»
UNKNOWN_COMMAND=§cUnbekannter Befehl.
Review

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.

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.
Review

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'

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'
Review

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.

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.
Review

ok Dann will ich dazu nichts gesagt haben

ok Dann will ich dazu nichts gesagt haben
UNKNWON_PLAYER=§cDiesen Spieler gibt es nicht.
INVALID_TIME=§cUngültige Zeitangabe.
#Help command
HELP_LOBBY=§7Kehre von überall mit §8/§el §7zur Lobby zurück!
@ -61,16 +62,18 @@ HELP_BAU_BAU_HOVER=§eNützliche Zusatzfunktionen
#Usage description of various commands
USAGE_ALERT=§8/§7alert §8[§eNachricht§8]
USAGE_BAN=§8/§7ban §8[§eSpieler§8] [§edd§8.§emm§8.§eyyyy §7oder §edd§8.§emm§8.§eyyyy§8_§ehh§8:§emm §7oder §eperma§8] [§eGrund§8]
USAGE_MUTE=§8/§7mute §8[§eSpieler§8] [§edd§8.§emm§8.§eyyyy §7oder §edd§8.§emm§8.§eyyyy§8_§ehh§8:§emm §7oder §eperma§8] [§eGrund§8]
USAGE_IGNORE=§8/§7ignore §8[§eSpieler§8]
#Various commands
ALERT=§f{0}
Review

Der Name ist finde ich etwas irreführend

Der Name ist finde ich etwas irreführend
Review

Vllt besser 'BAN_MESSAGE_YOU'

Vllt besser 'BAN_MESSAGE_YOU'
Review

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?

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?
BAN_YOU_BANNED=§7Du hast §e{0} §7gebannt§8. §7Grund§8: §c{1}
BAN_INVALID_TIME=§cUngültige Zeitangabe.
BAN_MESSAGE_YOU=§7Du hast §e{0} §7gebannt§8. §7Grund§8: §c{1}
Review

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.

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.
BUG_SAVED=§7Dein Bugreport wurde gespeichert.
MUTE_MESSAGE_YOU=§7Du hast §e{0} §7gemutet§8. §7Grund§8: §c{1}
BUG_MESSAGE=§7Dein Bugreport wurde gespeichert.
Review

Auch diesen Namen finde ich etwas irreführend

Auch diesen Namen finde ich etwas irreführend
Review

Vllt besser 'IGNORE_MESSAGE'

Vllt besser 'IGNORE_MESSAGE'
IGNORE_YOURSELF=§cWie willst du dich selber ignorieren?
IGNORE_ALREADY=§cDu ignorierst diesen Spieler bereits.
IGNORE_IGNORE=§7Du ignorierst nun §e{0}§8.
IGNORE_MESSAGE=§7Du ignorierst nun §e{0}§8.