SteamWar/BungeeCore
Archiviert
13
2

More MultiLang #169

Manuell gemergt
Lixfel hat 41 Commits von moreML nach master 2021-02-05 07:30:51 +01:00 zusammengeführt
Besitzer
Keine Beschreibung angegeben.
Lixfel hat eine neue Abhängigkeit 2021-01-19 19:30:44 +01:00 hinzugefügt
Lixfel hat eine Abhängigkeit 2021-01-19 19:30:50 +01:00 entfernt
Chaoscaot hat den Titel von WIP: More MultiLang zu More MultiLang 2021-01-19 20:19:53 +01:00 geändert
Lixfel hat 2021-01-27 10:16:38 +01:00 Änderungen angefragt
Lixfel hat einen Kommentar hinterlassen
Besitzer

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

Habe 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){
Besitzer

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)

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;
Besitzer

Wenn du das schon (sinnvollerweise) hier rein ziehst: Du brauchst hier keinen "header" mehr, mach doch direkt einen return

Wenn du das schon (sinnvollerweise) hier rein ziehst: Du brauchst hier keinen "header" mehr, mach doch direkt einen return
Autor
Besitzer

Diese Methode renturn direkt

Diese Methode renturn direkt
Besitzer

Du kannst im switch-case direkt returnen.

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
Besitzer

. am Ende

. am Ende
@ -116,9 +119,72 @@ POLLRESULT_HEADER=§eEs haben {0} abgestimmt auf die Frage: §7{1}
POLLRESULT_LIST=§e{0}§8: §7{1}
#BauCommand
BAU_ADDMEMBER_USAGE=/bau addmember <Spieler>
Besitzer

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)

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 @@
#BauCommand
BAU_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 Welt
Besitzer

Ok, 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).

Ok, 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}
Besitzer

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.

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.
Lixfel hat die Änderungen 2021-01-29 20:53:48 +01:00 genehmigt
Besitzer

Bitte Merge Conflict beheben.

Bitte Merge Conflict beheben.
Lixfel hat diesen Pull-Request 2021-02-05 07:30:51 +01:00 geschlossen
Lixfel löschte die Branch moreML 2021-02-05 07:32:36 +01:00
Dieses Repo ist archiviert. Du kannst Pull-Requests nicht kommentieren.
Keine Beschreibung angegeben.