More MultiLang #169
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#169
Laden…
In neuem Issue referenzieren
Einen Benutzer sperren
Keine Beschreibung angegeben.
Branch "moreML" 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?
WIP: More MultiLangzu More MultiLangHabe jetzt nicht jede Meldung im Detail durchgegangen, aber ich denke, dass wir das sowieso erst im Livebetrieb dann final durchtesten können. Die Grundprinzipien, auch, was ich mir da beim Formatting z.T. gedacht habe, sollten erkennbar sein.
@ -101,6 +101,11 @@ public class Message {sender.sendMessage(msg);}public static void broadcast(String message, boolean prefixed, String onHover, ClickEvent onClick, Object... params){Ich glaube, jeder Broadcast, den wir haben, ist Prefixed. Wsl. ist mir da in der Methode drunter nur ein kleiner Fehler unterlaufen, das falsch auszustellen, da würde ich dich bitten, das dort zu ändern und diese detailliertere Methode zu entfernen (es sei denn, du findest einen Broadcast ohne Prefix)
@ -86,2 +70,2 @@break;}private String calcHeader(ProxiedPlayer player){String header;Wenn du das schon (sinnvollerweise) hier rein ziehst: Du brauchst hier keinen "header" mehr, mach doch direkt einen return
Diese Methode renturn direkt
Du kannst im switch-case direkt returnen.
@ -3,7 +3,10 @@ SPACER=UNKNOWN_COMMAND=§cUnbekannter Befehl.UNKNOWN_PLAYER=§cDiesen Spieler gibt es nicht.UNKNOWN_TEAM=§cDieses Team gibt es nicht. am Ende
@ -116,9 +119,72 @@ POLLRESULT_HEADER=§eEs haben {0} abgestimmt auf die Frage: §7{1}POLLRESULT_LIST=§e{0}§8: §7{1}#BauCommandBAU_ADDMEMBER_USAGE=/bau addmember <Spieler>Wie bei den anderen Usages auch: Umlaute/zeichen wie /<> (wobei wir glaube ich üblicherweise statt <> immer [] verwendet hatten, können wir aber auch mal kanonisieren) immer §8, Grundbefehl §7, Argumentplaceholder §e (einfach um das auge mit zu führen, die Sonderzeichen sind nur Kontext, den Grundbefehl hat der Spieler ja schon korrekt eingegeben & nur die Argumente interessieren ihn eigentlich. Bitte auch mal bei den anderen USAGEs durchgehen (werde das jetzt nicht überall markieren)
@ -118,1 +121,4 @@#BauCommandBAU_ADDMEMBER_USAGE=/bau addmember <Spieler>BAU_ADDMEMBER_SELFADD=§cDu brauchst dich nicht selbst hinzufügen!BAU_ADDMEMBER_ISADDED=§cDieser Spieler ist bereits Mitglied auf deiner WeltOk, wir müssen hier einheitlich bleiben: Nach (absolutem) Blödsinn/Ausrufen !, nach Fehlermeldungen/Aussagen ., oder nicht .? Ich denke, wir sollten nach so Statusmeldungen etc. am Ende noch einen Punkt bringen, um den Satz einfach abzurunden (auch vom gedachten Sprachfluss her). Ich habe aber auch nichts dagegen, wenn wir das ohne Punkt machen, aber wenn dann überall gleich & konsequent! (Auch hier markiere ich das mal jetzt NICHT überall ;) ) In Hover-Messages würde ich es jedoch auf jeden Fall ohne Punkt machen (Da meistens sowieso kein ganzer Satz).
@ -122,0 +148,4 @@CHALLENGE_SELF=§cSchizophren?CHALLENGE_IGNORED=§cDer Herausgeforderte hat dich geblockt.CHALLENGE_INARENA=§cDer Herausgeforderte ist bereits in einer Arena.CHALLENGE_BROADCAST=§e{0}§7-§eDuell§7: {1} vs {2}Weiß nicht, ob das formatting schon vorher so war, würde hier aber denke ich den - sowie : und vs §8 machen, Duell §7 und die Teilnehmer §e hervorheben.
Bitte Merge Conflict beheben.