Minecraft Wiki
Registrieren
Advertisement
Bücherregal
Dies ist das Archiv der Gemeinschaftsportaldiskussion für Juli bis Dezember 2017. Bitte bearbeite diese Seite nicht.
Neue Fragen können auf der aktuellen Diskussionsseite gestellt werden.

Grundsatzdiskussion: Welche Sicht soll das Wiki grundsätzlich beschreiben?[]

In dieser sehr langen Diskussion wurde thematisiert, dass es unterschiedliche Sichtweisen gibt:

  • Erzählerische Sicht (Beispiel: Die Schweinezombies gelangen manchmal durch Netherportale in die Oberwelt)
  • Technische Sicht (Beispiel: Das Spiel generiert Schweinezombies direkt in der Oberwelt, sie kommen nicht aus dem Nether)
  • Communitysicht (Beispiel: Die Community sagt "Pyramide" und nicht "Wüstentempel")

Es begann eine weitere, umfangreiche Diskussion, welche Sichtweise das Wiki beschreiben soll. Diese weitete sich auf die Diskussion "Hund" oder "gezähmter Wolf" aus.

Wir scheinen uns einig zu sein, dass dem Wiki-Leser an erster Stelle die erzählerische Sicht gezeigt wird. Diese sollte für interessierte Leser um die technische Sicht ergänzt werden. Die Communitysicht sollte in Weiterleitungen berücksichtigt werden.

Das Hauptproblem ist nun die Definition von "erzählerischer Sicht": Was soll das sein, was wir sehen? - Damit wird das schwammige Gebiet der Deutung betreten. In der Diskussion wurden verschiedene Ansätze verfolgt, was denn die alleinig gültige Deutung sein darf. Ich finde, dieses Vorgehen ist schon falsch. Man muss unterschiedliche Quellen heranziehen, um zu verstehen, was sich die Entwickler gedacht haben. Leider wissen sie es manchmal selber nicht (Hat der Creeper ein Fell?). Der Programmcode kann eine hilfreiche, darf aber nicht die maßgebliche Quelle sein, denn oft ändert sich der erzählerische Sinn, während der Code, den kein Spieler sieht, der alte bleibt (Der Diamant hieß im Code lange "Emerald").

Zusammenfassung von Fusseel: Wir müssen ein für alle Mal klären, wie solche Sachen, in diesem Fall nicht eindeutige definierte Artikelnamen, gehandhabt werden. Wir können dafür auch noch einmal eine ganz neue Diskussion im Gemeinschaftsportal starten, da die momentane Grundsatzdiskussion sehr bauwerksorientiert ausgelegt ist. - Das ist hermit geschehen. -- Sumpfhütte 10:18, 20. Jun. 2017 (UTC)

Aus meiner Sicht sind technische Fakten so zu beschreiben, wie sie sind. Wenn man z.B. sagt, Schweinezombies gelangen durch Portale in die Oberwelt, dann behauptet man damit, dass im Nether ein Schweinezombie ins Portal laufen würde und ist damit schlichtweg falsch. Stattdessen kann man schreiben: "Dadurch entsteht der Eindruck, als würden sie durch das Portal in die Oberwelt gelangen". Wenn wir uns da nicht alle einig sind, dann wundert mich das.
In Sachen Bezeichnungen zählen natürlich nur die Begriffe, die dem Spieler im Spiel offen zugänglich sind, z.B. weil der Name des Gegenstandes im Inventar angezeigt wird. Deswegen kann man z.B. den Schild nicht einfach "Schutzschild" nennen, nur weil es schon eine Seite mit Namen "Schild" gibt.
"Wolf" ist einer dieser Begriffe, er steht bei einer Todesmeldung eindeutig im Chat. Deswegen kann nach meinem (und Fusseels?!) Grundsatz der gezähmte Wolf nicht einfach als Hund bezeichnet werden.
In anderen Fällen ist die Sache weniger eindeutig: Der Begriff "Bauwerk" wird im Spiel zwar verwendet, aber nicht in einer Weise, die klarstellt, dass alles andere kein Bauwerk ist. Nur in solchen Fällen - oder wenn, wie früher beim Endtransitportal, überhaupt kein Begriff gegeben ist, haben nach meinem (und Fusseels?!) Grundsatz die weiteren Argumente überhaupt einen Stellenwert. Wäre es nicht so, müsste sich ja das Wiki gegen das Spiel stellen. Mein (und Fusseels?!) Prinzip ist aber: "Das Wiki beschreibt ein Spiel, das Eigenschaften und Terminologien hat, und verwendet diese Terminologien. Damit steht das Beschriebene (das Spiel) über der Außenwelt (der realen Welt)."
Alle Argumente, die das Spiel nicht selbst vorgibt, können von mir aus gegeneinander aufgewogen werden. Vorrang hat aber das Spiel.
Das soll jetzt nicht als eine Aufzählung von Tatsachen verstanden werden, sondern als eine Grundsatzformulierung, die es zu diskutieren gilt. Iwer Sonsch (Diskussion) 10:58, 20. Jun. 2017 (UTC)
Aus meiner Sicht sind technische Fakten so zu beschreiben, wie sie sind. => Ja unbedingt, aber nicht immer in der Einleitung. Das Spiel simuliert eine Spielrealität. Diese sollte in der Einleitung beschrieben werden. ergänzend dazu kommt die technische Sicht: "erzählerisch: Die Sonne wandert über den Himmel. Technisch: Ein Sprite wird über den Hintergrund bewegt. Daher sieht man die Sonne auch im Untergrund, wenn der Tunnel bis zum Ende des geladenen Bereiches reicht." -- Sumpfhütte 11:05, 20. Jun. 2017 (UTC)
Ob ein Gegenstand in "Schild" oder "Schutzschild" heißt, wird von der Crowdin-Community festgelegt. Das Wiki übernimmt immer die deutsche Übersetzung, auch wenn die Wiki-Autoren andere Vorschläge haben. -- Sumpfhütte 11:09, 20. Jun. 2017 (UTC)
Aber "Die Sonne bewegt sich über den Himmel" ist doch eine technisch korrekte Formulierung: Das Sprite heißt Sonne, der Hintergrund heißt Himmel, und die Terminologie des Spiels widerspricht dem nicht. Auch in der Einleitung kann man Unwahrheiten geschickt ausweichen, z.B. "durch Netherportale tauchen Schweinezombies auch manchmal in der Oberwelt auf".
Bezüglich der Crowdin-Community: Dadurch, dass die Ergebnisse der Crowdin-Verhandlungen ins Spiel eingebaut werden, sind sie genauso sehr "im Spiel" wie die englischen Originalbegriffe - und nicht einfach als "Community-Formulierungen" abzuwerten. Iwer Sonsch (Diskussion) 11:21, 20. Jun. 2017 (UTC)
Es sind ja auch Community-Formulierungen, die jeder ändern kann, wenn derjenige genug Stimmen dafür mobilisiert. Aber es sind eben offizielle Community-Formulierungen, deswegen werden sie ja auch im Wiki verwendet, und daran hat bisher auch niemand was auszusetzen gehabt.
Ich stimme Sumpfhütte zu, die Spielersicht (aka erzählerische) sollte immer die wichtigste sein. Die technische Sicht gehört in die Steckbriefe sowie entsprechende Unterabschnitte (siehe Minecraft Wiki:Projekte/Daten in Artikel einbinden) und die Community-Sicht gehört höchstens in den Trivia-Abschnitt. Wie das in den einzelnen Fällen aussieht, muss von Fall zu Fall separat entschieden werden, da das nicht immer ganz eindeutig ist. | violine1101 (Diskussion) 12:13, 20. Jun. 2017 (UTC)
Je mehr ich darüber nachdenke, desto schwammiger und unglücklich gewählt finde ich die Fokussierung auf den "Spielersicht"-Aspekt: So, wie er jetzt dasteht, könnte man unter "Spielersicht" nämlich wahlweise das verstehen, womit der Spieler im Spiel direkt konfrontiert wird ("Ich habe einen Wolf gezähmt. Jetzt ist der Wolf gestorben, und im Chat steht auch, dass der Wolf gestorben ist"), oder das, was sich der Spieler dabei denkt ("Hmm... Es gibt Ozelots, und wenn ich die zähme, werden Katzen daraus. Dann müsste doch, wenn ich einen Wolf zähme, ein Hund dabei rauskommen." Und wenn ich ein Pferd zähme, kriege ich wohl ein Pony). Mir (und Fusseel?!) ist es aber wichtig, dem ersten Aspekt Vorrang vor dem zweiten zu geben. Schon allein deswegen, weil sich nicht jeder Spieler das Gleiche denken wird, das Spiel aber durchaus immer die gleichen Informationen liefert. Iwer Sonsch (Diskussion) 12:31, 20. Jun. 2017 (UTC)
Das Wiki soll an erster Stelle die erzählerische Sicht beschreiben. Das ist ist nicht immer das, was der Spieler glaubt zu sehen, sondern was die Erzähler (= Mojang) sich dabei gedacht haben. Dies herauszufinden, ist nur in wenigen Fällen schwierig. Aus erzählerischer Sicht sieht der Spieler in der Welt natürliche und künstliche Dinge. Ein Baum ist natürlich, ein Wüstenbrunnen und ein Wüstentempel sind künstlich. Zum vertiefenden Verständnis gibt es dann in den Artikeln Absätze, die die technische Sicht erklären. Hier erfährt der Spieler, dass Bäume in Wirklichkeit gar nicht wachsen, sondern fertig generiert werden, dass Wüstenbrunnen ein Biomzusatz sind und dass Wüstentempel eine Bauwerks-ID haben. Eine Weiterleitung "Pyramide" auf "Wüstentempel" (oder "Hund" auf "Wolf (gezähmt)") bildet dann die Communitysicht ab, so dass jeder Leser das findet, was er sucht, auch wenn er nur den Commuitybegriff kennt. -- Sumpfhütte 12:56, 20. Jun. 2017 (UTC)
Solange man diesen Aspekt betont, stimme ich zu. Iwer Sonsch (Diskussion) 13:32, 20. Jun. 2017 (UTC)

Das waren jetzt die Grundsätze, die unserer Sichtweise zugrunde liegen. Sumpfhüttes, Fusseels und mein Grundsatz scheinen für mich im Großen und Ganzen übereinzustimmen. Ich würde aber trotzdem noch gerne eine Grundsatzformulierung von @Violine1101, Nethonos, MarkusRost oder @Smartboyirom lesen, um die dazugehörige Position zu verstehen. Ginge das? Iwer Sonsch (Diskussion) 21:52, 20. Jun. 2017 (UTC)

Ich finde, es sollte keine Grundsatzformulierung geben, sondern von Fall zu Fall entschieden werden. So zähle ich beispielsweise die Bezeichnung "Hund" zur erzählerischen Sicht und nicht wie Sumpfhütte zur Community-Sicht. | violine1101 (Diskussion) 21:54, 20. Jun. 2017 (UTC)
Ich denke mit diesem "Grundsatz" wird soweit jeder einverstanden sein, da er einfach der beste Weg für in verständliches Wiki ist. Daher wird auch ohne seine Festlegung bisher nach diesem "Grundsatz" gehandelt und wird es wohl auch weiter.
Dadurch lassen sich aber nicht, wie von @Iwer Sonsch behauptet, alle Diskussionen vermeiden. Es wird immer einige Punkte geben, bei denen die Grenzen nicht ganz klar definiert und erkennbar sind. Dort muss dann über die verschiedenen Sichten diskutiert und mit Argumenten überzeugt werden. Führt dies nicht zu einer eindeutigen Einigung, muss notfalls abgestimmt werden. Und das bedeutet natürlich noch längst nicht das endgültige Ende eines Themas. Mit neuen Argumenten kann die Diskussion zu einem späteren Zeitpunkt jederzeit wieder aufgenommen werden.   HorseHead MarkusRost (Diskussion) 22:25, 20. Jun. 2017 (UTC)
@Violine1101: Ob formuliert oder nicht, Grundsätze gibt es immer. Es gibt immer Gründe, warum man das eine Argument stärker gewichtet als das andere. Und wenn man es schafft, diese Gründe allgemein zu erkennen und darzustellen, kann man im nächsten Schritt darauf eingehen, welche intuitiven Grundsätze nun für ein Netzwerk mit Verantwortung wichtiger sind als andere. Und eben darum bitte ich um eine Formulierung. Oder geht bei dir einfach alles nach Gefühl?
@MarkusRost: Nicht ganz. Ich bin mit diesem Grundsatz eben nicht einverstanden, weil er einfach inkonsequent ist. Wie du selbst betonst, ist dieser Nullgrundsatz einfach nicht in der Lage, irgendein dauerhaft effizientes Lösungssystem zu ermöglichen. Und selbst dort, wo er (insbesondere durch Abstimmungen) überhaupt zu einem Ergebnis führt, erhalten wir weder Stabilität, noch Einheitlichkeit innerhalb des Netzwerkes. Wie bereits in meiner Antwort an violine1101 erwähnt, haben wir hier im Wiki die Verantwortung, sinnvolle Entscheidungen zu treffen. Da können wir nicht einfach sagen, mit der ineffizientesten und inkonsequentesten Lösung wären alle einverstanden.
Ich hoffe, ich spreche auch im Sinne von Sumpfhütte und Fusseel. Iwer Sonsch (Diskussion) 22:39, 20. Jun. 2017 (UTC)
Sumpfhüttes, Fusseels und mein Grundsatz scheinen für mich im Großen und Ganzen übereinzustimmen.
~ @Iwer Sonsch
Ich bin mit diesem (violine1101's; Iwer Sonsch (Diskussion) 22:57, 20. Jun. 2017 (UTC)) Grundsatz eben nicht einverstanden, weil er einfach inkonsequent ist.
~ ebenfalls @Iwer Sonsch
Da hast du dich wohl etwas widersprochen...
Falls du wirklich versuchst einen Grundsatz zu finden, der immer zu 100% eindeutig ist, so wirst du kein besseres Ergebnis als "Wir behandeln das Spiel Minecraft" erhalten. So gut ein Grundsatz auch ist, er kann nicht immer eindeutig sein. Jeder gewichtet Argumente verschieden oder ordnet sie einer anderen Sicht zu, daher gibt es Diskussionen um dort eine Lösung für alle zu finden.   HorseHead MarkusRost (Diskussion) 22:48, 20. Jun. 2017 (UTC)
@MarkusRost: Mit violine1101's "Grundsatz", keinen Grundsatz zu haben, bin ich nicht einverstanden. Wenn du den von Sumpfhütte meinst, ist das durchaus schonmal ein Anfang.
Dann verstehe ich allerdings nicht, wie man - nach Sumpfhüttes Betonung in Beitrag 7 ("Das Wiki soll an erster Stelle...") - noch für den "Hund" einstehen kann. Ebendieser Hund existiert in Minecraft nämlich einfach nicht, sondern einzig der gezähmte Wolf, wie in der von Entwicklerseite deutlichen Abgrenzung zu Ozelot/Katze klar wird. Nach diesem Grundsatz (dem du offenbar zustimmst), fällt doch mindestens die Hälfte deiner Argumente weg, oder? Iwer Sonsch (Diskussion) 22:57, 20. Jun. 2017 (UTC)
Ich bezog mich durchaus auf den Grundsatz von Sumpfhütte, auch wenn es für mich eher Standard-Wiki-Richtlinien sind als ein Grundsatz, der erst festgelegt werden muss. Vermutlich meinte violine sowas ähnliches.
Das Wiki soll an erster Stelle die erzählerische Sicht beschreiben. Das ist ist nicht immer das, was der Spieler glaubt zu sehen, sondern was die Erzähler (= Mojang) sich dabei gedacht haben. Dies herauszufinden, ist nur in wenigen Fällen schwierig.
~ Sumpfhütte
Dort hast du einen Kern von Sumpfhüttes Aussage: Der Hund/Wolf ist einer dieser schwierigen Fälle. Will Mojang einen zahmen Wolf oder eher Hund und Katze? Es ist nicht eindeutig, das sieht jeder verschieden, also wurde diskutiert.   HorseHead MarkusRost (Diskussion) 23:07, 20. Jun. 2017 (UTC)
"eher Richtlinien als ein Grundsatz, der erst festgelegt werden muss". Aha, die Terminologie (gut zu wissen, sehr gut dass du darauf hinweist). In meinem Wortschatz bezeichnet eher das Wort "Grundsatz" die Motive, nach denen jemand intuitiv entscheidet, während man Richtlinien erst festlegen muss. Wenn man sich nun auf einen Grundsatz (also eine Denke) einigt, kann vielleicht eine Richtlinie daraus werden. Aber wenn man sich ohnehin auf die gleiche Denke einigt - und darin besteht mein Ziel in einer Grundsatzdiskussion - ist so eine verbindliche Vorgabe vielleicht gar nicht notwendig. Wir meinen also wahrscheinlich das Gleiche.
In Bezug auf den Wolf. Wenn man die Erzählersicht nimmt - bei einem Spiel, in dem es Endermen, Netherportale, Illager und Diamantrüstungen gibt -, dann wundert es mich, wenn man den Entwicklern die Einführung ebendieser Objekte erlaubt, aber die Existenz eines gezähmten Wolfs mit der Begründung abstreitet, es gebe ja keinen gezähmten Wolf in der echten Welt. Es mag ja andere Argumente für den "Hund" geben - vielleicht ist seine Form nicht ganz eindeutig, oder der Kontrast zum Paar Katze-Ozelot nicht ganz so stark - aber das Argument mit der echten Welt könnte an dieser Stelle doch einfach mal wegfallen, oder? -- Iwer Sonsch; 09:51, 21. Jun. 2017 (UTC)
In meinem Wortschatz bezeichnet eher das Wort "Grundsatz" die Motive, nach denen jemand intuitiv entscheidet, während man Richtlinien erst festlegen muss. Wenn man sich nun auf einen Grundsatz (also eine Denke) einigt, kann vielleicht eine Richtlinie daraus werden.
~ Iwer Sonsch

Du möchtest also, dass das in die Richtlinien aufgenommen wird? Wenn ja, dann muss ich dich enttäuschen. Die Richtlinien stellen die Verhaltensregeln im Minecraft Wiki dar, alles weitere wird in den Diskussionen diskutiert. Du versuchst, die anderen Autoren an eine von dir festgelegte Regel zu binden, ohne dazu tatsächlich eine Diskussion zuzulassen. Das geht nicht. | violine1101 (Diskussion) aka 188.210.60.168 10:36, 21. Jun. 2017 (UTC)

Du versuchst, die anderen Autoren an eine von dir festgelegte Regel zu binden
~ violine1101
Im Gegenteil. Das Wörtchen "vielleicht" weist klar darauf hin, dass ich dieses Szenario eben nicht als den Standard ansehe. Vielmehr wollte ich mich von genau diesem Vorwurf bereits mit der zitierten Aussage abgrenzen, weil ich das Gefühl hatte, @MarkusRost würde meinen Begriff "Grundsatz" so auffassen, wie wir beide den Begriff "Richtlinie" verstehen. Ich betone daher auch in genau diesem Zitat, dass es so eine Richtlinie ohne Einigung ohnehin nicht geben wird (Beachte das Wörtchen "wenn"). Es ist mir schleierhaft, wie man das missverstehen kann...
"ohne dazu tatsächlich eine Diskussion zuzulassen" Ich habe das genaue Gegenteil oft genug klar und unmissverständlich betont. -- Iwer Sonsch; 11:06, 21. Jun. 2017 (UTC)

{{ungelöst}}

@Fusseel: Korrekt. Nur weil jemand die Diskussion nicht lösen will, ist es falsch, sie für bereits gelöst zu erklären. Nach den letzten Missverständnissen habe jedenfalls ich mich erklärt und die Gegenseite nichts mehr von sich hören lassen.
Diese Diskussion hat weiterhin das Ziel zu klären, nach welchen Prinzipien (vielleicht ist das die beste Bezeichnung) Entscheidungen im Wiki getroffen werden sollen. Iwer Sonsch (Diskussion) 11:44, 24. Jun. 2017 (UTC)
Ich hatte das ungelöst wieder entfernt, da du es mit der Begründung eingefügt hast, da man ja noch Diskussionen führen muss.

Man wird immer Diskussionen führen müssen!

Es ist nicht möglich eine Regeln aufzustellen, ohne das noch bei der ein oder anderen Sache Uneinigkeiten aufkommen. Ein Wiki ist schließlich keine Diktatur!
Und für mich ist diese Diskussion tatsächlich eigentlich erledigt. Soweit ich das erkenne, haben sich alle auf den Vorschlag von Sumpfhütte geeinigt (der bereits das aktuelle Verfahren beschreibt). Ich weiß also nicht genau worauf du jetzt noch hinaus möchtest. Dies kannst du gerne hier drunter schreiben, da es auch deutlich aussagekräftiger ist als ein ungelöst.   HorseHead MarkusRost (Diskussion) 11:54, 24. Jun. 2017 (UTC)
Es gibt einfach noch Leute, die Sumpfhüttes Vorschlag mit Füßen treten - sei es beim Hund (bevor die Notch-Tweets gefunden wurden), sei es beim Pilzland. Da war ich davon ausgegangen, dass manche Leute - namentlich Nethonos, Smartboyirom und violine1101 - nicht einverstanden sind und die Diskussion damit noch nicht beendet ist.
Wenn das auf dich nicht zutrifft, ist das schonmal ein Anfang. Iwer Sonsch (Diskussion) 11:59, 24. Jun. 2017 (UTC)
Bitte achte etwas auf deine Wortwahl. Ich habe nun bereits mehrfach gesagt, das jeder die Wichtigkeit einiger Argumente anders sieht. Und bloß weil jemand nicht deiner Meinung ist, heißt das nicht er habe unrecht. Ich habe dir z.B. gezeigt worauf meine Meinung zu dem Hund basiert und ich denke mal den anderen die für den Hund waren, werden ähnliche (wenn auch nicht unbedingt die gleichen) Argumente (gehabt) haben. Bloß weil du diese Argumente nicht für so wichtig hältst wie sie, heißt das nicht, das sie nach einem völlig anderen Prinzip argumentieren.   HorseHead MarkusRost (Diskussion) 12:07, 24. Jun. 2017 (UTC)
@MarkusRost: Sumpfhütten Darstellung beschreibt nur in der Theorie, wie es momentan eigentlich bereits gehandhabt werden sollte. Das wird aber an zu vielen Stellen einfach nicht umgesetzt, da es eben nicht festgeschrieben ist. Der Vorschlag, alles wie es momentan ist, in einem regellosen Wirrwarr zu lassen, kam von violine1101. Die Etablierung weiterer Leitlinien hat mit "Diktatur" nichts zu tun. Wir haben genauso genug Sachen in der Demokratie fest geregelt, um sie nicht jedes Mal neu diskutieren zu müssen. Damit ist nicht jeder einverstanden, aber man kann halt nicht jedes Mal bei Null anfangen. Weitere Leitlinien sollen einerseits einen festen Bezugspunkt darstellen und uns halt langwierige Diskussionen ersparen. Das hat nichts mit Unterdrückung zu tun, das gibt einfach die Möglichkeit, sich stattdessen auf wichtigere Aufgaben zu konzentrieren. Und die gibt es auf jeden Fall, genug Seiten sind vergleichsweise karg. Durch solche Leitlinien wird uns ja auch nicht jede Diskussion erspart, aber wenn wenigstens ein paar entfallen, ist das Erfolg genug.
Momentan fehlt einfach die Kontinuität, mal geht es so, mal so. Der Leser will nicht in dem einen Artikel lesen, dass du denkst, die Pilzinsel sollte lieber "Pilzland" heißen, und dann bei der Wüste wieder den In-Game Namen vorgelegt bekommen. Er will bei allen Artikeln genau eins von beidem. Das ist zwar gut und schön, wenn da immer fünf Leute drüber abgestimmt haben, aber es führt zu einer willkürlichen Struktur, die den Leser verwirrt, weil es nicht mit dem Spiel, dass er/sie kennt übereinstimmt, oder mit der Community, in der er/sie sich bewegt. Es stimmt willkürlich mit irgendetwas überein. Es bedarf deswegen einfach Prioritäten, die in so einer Leitlinie eingefasst wären. Gibt es keine In-Game Bezeichnung greift dann bspw. die Community oder der Code. Fusseel (Diskussion) 13:33, 24. Jun. 2017 (UTC)
Fusseel ist einfach ein viel besserer Redner als ich. Alles, was er schreibt, sollte eigentlich klar sein, man vergisst es nur immer wieder.
In Bezug auf den Hund wurde ein Argument angeführt und bestimmt vertreten, das nach Sumpfhüttes Grundsatz einfach überhaupt keinen Stellenwert hat: Die Nichtexistenz von gezähmten Wölfen in der echten Welt. Man kann den Entwicklern nämlich ebensowenig verbieten, aus Erzählersicht einen gezähmten Wolf einzuführen wie einen Creeper, eine Netherfestung oder den Enderdrachen. Und das hat gar nichts damit zu tun, dass ich das Argument für nicht so wichtig halte, sondern dass der Grundsatz dieses Argument als unbedeutend einstuft - der Grundsatz, den ich nicht aufzwingen, sondern diskutieren und deswegen diese Diskussion weiterführen will.
Und natürlich stimmt es, dass auch mit dem Grundsatz nicht jede einzelne neue Frage ohne jede Klärung beantwortet werden kann, ja manchmal sogar mehrere Standpunkte halbwegs nachvollziehbar sein können. Aber dann haben wir wenigstens einen klaren Grund, warum sich die Mehrheit in eine gewisse Richtung entscheidet, anstatt dass wir zuerst die Argumente nicht wirklich besprechen und am Ende eine Seite ohne Entkräftung der Argumente überstimmt wird und keine Ahnung hat, warum. Iwer Sonsch (Diskussion) 14:27, 24. Jun. 2017 (UTC)

@Nethonos: Was denkst du eigentlich? Ich hatte gehofft, dass wir alle über das Thema diskutieren können. Iwer Sonsch (Diskussion) 15:31, 24. Jun. 2017 (UTC)

Der Vorschlag, alles wie es momentan ist, in einem regellosen Wirrwarr zu lassen, kam von violine1101.
~ Fusseel
Was soll sich denn mit dem Grundsatz daran verändern? Für das, was du meinst, ist einfach keine Regel notwendig, denn eine solche Regel würde noch viel viel mehr Wirrwarr verursachen. Selbst wenn eine solche Regel existieren sollte, wird man sie nie so genau formulieren können, dass es keine Unregelmäßigkeiten mehr gibt, über die zwangsläufig sowieso diskutiert werden muss. | violine1101 (Diskussion) 16:53, 24. Jun. 2017 (UTC)
@Fusseel: Ich meinte nicht, dass ich eine Regelung als Diktatur empfinde. Ich finde nur die Absicht von @Iwer Sonsch garnicht mehr zu diskutieren nicht gut. (Bei jeder Diskussion über eine Bezeichnung mit Undeutlichkeiten wird sich beschwert)
@Iwer Sonsch: Was den Hund betrifft, ich wollte dort mit meinem Argument es gäbe im richtigen Leben keine zahmen Wölfe nicht behaupten, dass soetwas in Minecraft nicht eingefügt werden darf. Ich wollte damit vielmehr unterstreichen, dass der Wolf ein natürlich vorkommendes Wesen ist und ich daher vermutet habe, dass daher auch die gezähmte Form natürlich sein sollte. Und sollten bei einer Abstimmung die gegnerischen Argumente nicht entkräftet worden sein, so liebt es auch hier meistens an der Wertigkeit.
Es gab diese Argumente und jene. Mir sind diese wichtiger als jene also bin ich hierfür. Bloß weil man es anderes gewichtet hat, muss man auch verstehen, dass die andere Seite eventuell eine andere Gewichtung hatte. Dabei kann sich das Ganze immer noch auf gleichen Grundsatz beziehen.
@Violine1101: Diese Meinung vertrete ich ebenfalls, wenn sie aber unbedingt einen "Grundsatz" dafür haben wollen, wie ein Wiki funktioniert, können sie diesen gerne aufschreiben. Es treten dadurch ja nicht einmal Änderungen zum jetzigen Verhalten auf.
Der Kern dieser Diskussion liegt soweit ich erkennen kann eher darin dass @Fusseel und aber vor allem @Iwer Sonsch nicht verstehen (wollen) wieso jemand eine andere Meinung haben könnte. Eine eigene Meinung bedeutet nämlich nicht unbedingt einen anderen "Grundsatz" Man muss sich auf die Gegenargumente auch einlassen um zu verstehen, warum sie für jemanden eventuell wichtiger als für mich sein könnten.
Und zum Schluss nochmal @Iwer Sonsch: Niemand ist gezwungen sich an Diskussionen zu beteiligen, man kann auch nur mitlesen und sich daraus seine Meinung bilden.   HorseHead MarkusRost (Diskussion) 17:04, 24. Jun. 2017 (UTC)
Ich finde nur die Absicht von Iwer Sonsch garnicht mehr zu diskutieren nicht gut.
Diese Absicht habe ich nicht, und ganz besonders nicht in dieser Grundsatzdiskussion. Ich meinte im Gegenteil, dass wir bei einer Diskussion nicht dabei aufhören sollten, unsere Argumente genannt zu haben und die Position der jeweils anderen in keinster Weise zu verstehen, sondern wir vielmehr über die Gründe reden sollten, warum wir die Argumente so gewichten, mit dem Ziel, Entscheidungen auch verstehen zu können. Wenn wir uns dabei auf eine Sicht einigen könnten, würden wir eine Diskussion dadurch niemals unterdrücken. Wir hätten nur eine gute Chance, uns von vornherein einig zu sein, zumindest sobald die Argumente auf dem Tisch liegen (also die "Diskussion" im bisherigen Sinne bereits stattgefunden hat).
"nicht verstehen wollen, wieso jemand eine andere Meinung haben könnte" Im Gegenteil. Deswegen will ich die Diskussion eben auf die Grundsatzebene vertiefen, anstatt wie bisher ratlos dazustehen, weil die Gewichtung mir komplett unsinnig erscheint, und ich nicht weiß, warum ich überstimmt werde.
"und aber vor allem Iwer Sonsch" Vielleicht schlage ich tatsächlich über die Stränge, dann tut mir das leid. Ich vertrete meine Ansicht aber auch nur deswegen so vehement, weil ich damit nicht alleine dastehe. Ein Teil der Vehemenz ist aber auch durch direkte Missverständnisse zwischen violine1101, MarkusRost und mir entstanden. Ich stelle immer noch fest, dass fast jede Aussage, die jemand aus einem meiner Zitate gefolgert hat, falsch ist.
"Niemand ist gezwungen, sich an Diskussionen zu beteiligen" Natürlich, vielleicht habe ich da überschossen. Allerdings wird es mir dadurch erschwert, Nethonos zu verstehen, was ich schade finde. Bei der nächsten Diskussion werde ich mich dann wieder über seinen Standpunkt wundern, weil ich dann wieder seine Gründe nicht kenne. Iwer Sonsch (Diskussion) 18:04, 24. Jun. 2017 (UTC)

Wenn es eine offizielle Übersetzung gibt, dann wird auch die fürs Wiki genommen. Es spielt keine Rolle, ob die Zeichenkette tatsächlich im Spiel vorkommt. Diskussionen über Übersetzungen gibt's hier nur, wenn etwas nicht in der Übersetzungsdatei vorkommt, wie bspw. die Endsiedlung
~ violine1101

Gilt nicht. Präzedenzfall Hund. Sind wir uns da einig?

Ich finde, es sollte keine Grundsatzformulierung geben, sondern von Fall zu Fall entschieden werden.
~ violine1101

Das werte ich als Ja. Iwer Sonsch (Diskussion) 13:08, 8. Jul. 2017 (UTC)

Versuche nicht, meine Worte zu verdrehen. Du weißt genau, dass ich das nicht meinte. | violine1101 (Diskussion) 13:22, 8. Jul. 2017 (UTC)
"Versuche nicht, meine Worte zu verdrehen." Etwas diplomatischer habe ich das @MarkusRost, Violine1101 auch mitgeteilt. Es war ihnen egal.
"Du weißt genau, dass ich das nicht meinte." Nein, weiß ich nicht. Welche der beiden Aussagen meintest du nicht, aka in welchem der beiden Punkte hast du mir schon immer zugestimmt? Iwer Sonsch (Diskussion) 13:27, 8. Jul. 2017 (UTC)
Artikelnamen

Bei der Vergabe eines Artikelnamens wird stets der Name gewählt, den das entsprechende Element in der deutschen Übersetzung des Spiels hat (siehe Sprachdatei). Die deutsche Übersetzung wird auf der Crowdin-Plattform durch eine Gruppe von Freiwilligen in Gemeinschaftsarbeit durchgeführt. Hier kann man sich daran beteiligen. Namensvorschläge oder -kritiken für diese Spielelemente sind auf der Crowdin-Plattform zu diskutieren.

~ Gestaltungsrichtlinien
Crowdin geht immer vor, aber nicht für alles gibt es Übersetzungen. Dann muss man einen Namen überlegen. Im Fall Hund gibt es eine Übersetzung für Wolf, in der Diskussion ging es darum, ob diese auch für den Hund gibt, oder es dort keine gibt.   HorseHead MarkusRost (Diskussion) 13:28, 8. Jul. 2017 (UTC)
Doch. Es gibt eine Übersetzung für das Tier, das hier von der Mehrheit fälschlicherweise als "Hund" bezeichnet wird. Diese Übersetzung lautet Wolf, und sie ist im Spiel bestätigt. Ich werde noch nachsehen, ob "Wolf" auch auf Crowdin bestätigt ist. Iwer Sonsch (Diskussion) 13:31, 8. Jul. 2017 (UTC)
Diese Diskussion gehört nicht zu den Gestaltungsrichtlinien! Wenn du mit dem Hund nicht einverstanden bist, dann komme bitte mit neuen Argumenten dazu hier. Crowdin liegt immer an erster Stelle, doch beim Hund war die Frage, ob die Übersetzung auch für den Hund gilt oder da etwas fehlte. Die Abstimmung hat das wohl klargestellt. Die Diskussion zum Hund ist nicht Thema dieser Diskussion!   HorseHead MarkusRost (Diskussion) 13:57, 8. Jul. 2017 (UTC)

Better Together Update[]

Kategorie für Vorschaubilder von den Entwicklern[]

Titel sagt alles. Es sind einfach so viele hier im Wiki und da es ja z. B. auch historische Bilder gibt würde das meiner Meinung nach sinnvoll sein. Es gibt im Wiki genug Bilder, die einfach etwas verwirrend sind, da man nicht weiß, wo sie herkommen. Kämen sie von den Entwicklern würde das oft einiges erklären, z. B. kann ich mir die Herkunft dieses Bildes (Datei:Zaubertisch Verzauberte Rüstung und Schwert.jpg) einfach nicht erklären. Mit einer eigenen Kategorie hätte man in solchen Fällen zumindest einen Ansatz oder kann es wirklich löschen, ohne sich Sorgen machen zu müssen, ein historisches Beweisstück vernichtet zu haben. Die eigene Kategorie soll eben auch dazu dienen, dass solche Bilder nicht mal aus Versehen gelöscht werden, weil jemand nicht weiß, dass sie von den Entwicklern stammen (Soll jetzt aber auch nicht heißen, dass jedes Bild von dene gleich ein Heiligtum ist!). Ich hatte das z. B. bei den Biomen erlebt und da war es dann aufwendig, die wieder mit originaler Quelle herauszusuchen. Außerdem sollte bei Bildern in der Kategorie eine Quellenpflicht bestehen. Was denkt ihr? – Fusseel 00:15, 9. Jul. 2017 (UTC)

Viele Bilder sind so alt, dass sie gewissermaßen schon wieder historisch sind. Eine eigene Kategorie wäre aber nicht sinnlos, ich wäre dafür. Nur, da ergibt sich das Problem, dass das nicht so einfach herauszufinden ist.
Die umgekehrte Google-Bildersuche könnte dir helfen beim Suchen nach der Quelle (am besten immer mit der originalen Datei suchen). Oder das englische Wiki, das hat vllt eine Quellenangabe, wenn es auch das Bild benutzt. Oder Reddit, da tauchen im Normalfall alle Vorschaubilder/-tweets von Mojang-Entwicklern sofort auf. Im Fall des Bruchstein-Zaubertisches konnte ich aber beim besten Willen keine Quelle finden. Sicher, dass das ein Entwickler-Vorschaubild ist? Ich allerdings diese beiden Tweets gefunden, die würden als evtl neue Quelle ausreichen. | violine1101 (Diskussion) 07:49, 9. Jul. 2017 (UTC)
Stimmt, die Google-Bildersuche gibt es ja auch! Im englischen Wiki schaue ich immer als erstes, für das Bild hatte ich vor einer Weile wirklich schon alles abgegrast. Die Bildersuche hat es jetzt aber gebracht, das hier ist der korrekte Tweet. Das war aber auch eine Safari, den Tweet/Imgur-Link hat die Bildersuche nämlich nicht geliefert. ^^
Und die Kategorie dient meiner Meinung nach dann hauptsächlich dazu, dass die Bilder eben nicht versehentlich gelöscht oder überschrieben werden. Jetzt wo du auch gerade diese beiden Beispiele verlinkt hast fällt mir sogar auf, dass mir genau das gestern bei diesem Bild passiert ist. Kann halt keiner wissen, dass es ein Entwicklerbild ist, wenn es nirgendwo steht.
Ich würde sagen, dann legen wir die Kategorie einfach mal an. Wie geht das genau? :D Einfach irgendwo einbauen und sie wird automatisch erzeugt? Ich würde sie "Entwicklungsbilder" oder "Entwicklerbilder" nennen, auf jeden Fall nichts zu langes. – Fusseel 10:29, 9. Jul. 2017 (UTC)
Ich hätte "Vorschaubilder" genommen. Einfach die Datei der Kategorie zuweisen und dann die Seite Kategorie:<Name> erstellen mit einer Beschreibung, wofür die Kategorie ist. Orientiere dich am besten an der Kategorie:Historische Bilder. | violine1101 (Diskussion) 10:36, 9. Jul. 2017 (UTC)
Super, danke! Mache ich gleichmal so. Werden Kategorien dann auch irgendwo zentral eingetragen, wie bei den Vorlagen? Und soll das dann mit zu irgendwelchen Richtlinien für Bilder oder so, das Vorschaubilder mit der entsprechenden Kategorie und Quelle hochzuladen sind? – Fusseel 10:50, 9. Jul. 2017 (UTC)
Kategorie sind immer auch in einer Kategorie. Dies müsstest du von den Historischen Bildern übernehmen können.   HorseHead MarkusRost (Diskussion) 10:52, 9. Jul. 2017 (UTC)
Gut, danke. Gibt es eigentlich ein Tool, womit ich einfach die entsprechenden Dateien auswählen kann, damit sie der Kategorie hinzugefügt werden? Oder ist es zwingend nötig, jede Seite einzeln zu bearbeiten? – Fusseel 11:47, 9. Jul. 2017 (UTC)
Jede Seite einzeln. Allerdings kann ich mir vorstellen, dass es reichen könnte, wenn du auf deiner Testseite die URL sammelst, damit ein netter Bot die Kategorie einträgt. Was meinen die Bots dazu? :-) -- Sumpfhütte 15:23, 9. Jul. 2017 (UTC)

Das ist kein Problem, kann ein Bot gut machen. Einfach eine Liste mit den Seitennamen anlegen, dann kann der Bot die auslesen.   HorseHead MarkusRost (Diskussion) 15:27, 9. Jul. 2017 (UTC)

Versionsvermerk in Artikeln[]

Um das gleich an den Anfang zu stellen, der Vorschlag bezieht sich auf eine Bearbeitungshilfe für uns und soll eventuell gar nicht erst für die Leser sichtbar sein!
Also, mir fällt bei meinen vielen Bearbeitungen und vor allem Überarbeitungen immer wieder auf, dass z. T. große Teile vieler Artikel veraltet sind. Teilweise sogar so stark, dass es einfach nicht mehr feierlich ist, selbst bei Artikeln ganz klassischer Inhalte, wo eigentlich ständig mal irgendjemand lesen sollte. Ich weiß, dass man unmöglich immer alles aktuell halten kann, aber es wäre immerhin ganz gut, da mal einen Überblick zu bekommen und zu stark veraltete Artikel in Zukunft leicht ausfindig machen zu können. Meine Idee besteht nämlich darin, in den meisten Artikeln einen Versionvermerk zu hinterlassen, der angibt, mit welcher Version von Minecraft der Artikel das letzte Mal abgeglichen wurde. Dieser Vermerk würde vom Autor manuell angepasst werden, wenn auch wirklich der Artikel geprüft und angepasst wurde. Also nichts automatisches, denn dann ist plötzlich alles aktuell, aber eigentlich doch nicht. Der Sinn dahinter ist zum Einen eine Bearbeitungshilfe für zukünftige Autoren, damit diese sich schneller ein Bild machen können, was wahrscheinlich alles fehlen wird und wo demzufolge anzusetzen ist. Außerdem sollten die Zuordnungen zu einer Version wie bei einer Kategorie zentral zugänglich sein, so dass man nachschauen kann, welche Artikel z. B. noch auf dem Stand der 1.5 sind und dann zu lange nicht mehr überarbeitete Artikel mit Vorrang mal bearbeitet.
Das System soll aber z. B. nicht dazu führen, dass nach jedem Update jemand überall durchrennt und die Versionsnummer erhöht. Muss ja nicht sein, nicht jeder Artikel muss auch jede Version geprüft werden, jetzt ist es schließlich nicht anders. Welche Versionsintervalle genutzt werden ist genauso offen, aber die Hauptversionen machen wohl am meisten Sinn (1.0; 1.1; ...). Bin mal gespannt, was ihr dazu denkt. – Fusseel 00:48, 9. Jul. 2017 (UTC)

<!--[[Minecraft Wiki: Versionsvermerk 1.12]]--> ergibt . Dann könnte man von besagter Seite aus sehen, welche Seiten darauf verlinken. Nachteil: Man sieht die Seiten, wenn man nach Seiten mit Präfix: Minecraft Wiki sucht. Iwer Sonsch (Diskussion) 06:45, 9. Jul. 2017 (UTC)
@Iwer Sonsch: das funktioniert so nicht. Auskommentierte Links werden auch nicht in der Linkliste angezeigt. Ich würde das eher über eine Markierungskategorie lösen.
@Fusseel: Gute Idee! Nur: Welche Seiten sind hier denn momentan noch groß veraltet? Ich wüsste nicht, dass das sonderlich viele sind.
Sollte man das nur für die Java-Edition machen oder auch für die Bedrock Edition? Und: Diese Markierung könnte auch ohne große Probleme die Vorlage "Änderung" ersetzen. | violine1101 (Diskussion) 07:20, 9. Jul. 2017 (UTC)
Die Vorlage "Änderung" wird anders verwendet. Sie markiert neue Snapshot-Inhalte und wird beim Erscheinen der fertigen Version entfernt. Die Erfahrung zeigt, dass dabei nicht jedesmal der gesamte Artikel geprüft oder gar überarbeitet wird, auch wenn er nur kurz ist. Daher kann man die zwei Markierungen nicht zusammenfassen. - Zur "Aktuell"-Markierung: Es wäre schön, wenn das funktionieren würde. Aber es wird passieren, dass viele Artikel noch die Markierung "aktuell 1.12" enthalten, obwohl sie auch für "1.14" noch aktuell sind. Das wird wahrscheinlich sogar für die Mehrzahl der Artikel gelten, denn wir haben über 1000 Artikel, davon über 600 für Blöcke, Gegenstände, Kreaturen und Biome. Niemals wird jemand nach jeder Vollversion alle 600-1000 Artikel prüfen (und mit jeder Version werden es mehr). Für den umgekehrten Fall haben wir die Vorlage "Stub", die jeder einsetzen kann, wenn er merkt, dass ein Artikel nicht aktuell ist. -- Sumpfhütte 08:37, 9. Jul. 2017 (UTC)
Nun ja. Wenn ein Artikel die Markierung "aktuell 1.12" hat, und man meint, dass sich bis zur 1.15 nichts daran geändert haben dürfte, kann man es einfach lassen. Wenn man es doch nachprüft und feststellt, dass der Artikel tatsächlich aktuell ist, schreibt man "aktuell 1.15". Das kann schon funktionieren. Iwer Sonsch (Diskussion) 08:42, 9. Jul. 2017 (UTC)
Das Problem ist eher der Eindruck für die Leser. Steht in einem Artikel "Aktuell 1.8" schreckt das ab. Das Wiki scheint dann sehr veraltet, man liest es sich also nicht durch. Ist der Hinweis versteckt, z.B. durch eine versteckte Kategorie, findet ihn wieder niemand zum Überprüfen.   HorseHead MarkusRost (Diskussion) 08:52, 9. Jul. 2017 (UTC)
Eine versteckte Kategorie findet nicht niemand. Statt "aktuell" kann man außerdem auch "abgeglichen mit" schreiben. Iwer Sonsch (Diskussion) 08:54, 9. Jul. 2017 (UTC)
Ich sehe kein Problem darin, eine Kategorie "Stand 1.12" oder so unten zu haben. Auf die Kategorien sieht eh kaum jemand. Aber wenn es euch stört, könnte man diesen Hinweis auch per CSS nur für nicht angemeldete Benutzer verstecken, oder ganz unauffällig mit JavaScript neben "Diese Seite wurde zuletzt am 9. Juli 2017 um 11:08 Uhr geändert" verschieben. | violine1101 (Diskussion) 09:08, 9. Jul. 2017 (UTC)
"Stand" klingt noch besser, da wäre ich dafür. Iwer Sonsch (Diskussion) 09:23, 9. Jul. 2017 (UTC)
Mein Einwand, dass das bei 1000 Artikeln nicht funktionieren wird, hat sich auch erledigt, denn Fusseel hat ja deutlich von einer "Bearbeitungshilfe für uns" gesprochen. Es geht also nicht darum, dass mit jeder Minecraft-Version alle Artikel geprüft werden sollen, sondern wenn jemand einen Artikel prüft, kann er ein Prüfsiegel für den nächsten Bearbeiter hinterlassen. Es sollte dabei aber deutlich werden, was es bedeutet: "Letzte vollständige Überarbeitung mit Stand 1.12". Bei nur "Stand 1.12" fehlt nämlich das Entscheidende, der Hinweis auf die "vollständige Überarbeitung". - @Violine1101: Zur technischen Umsetzung: Wie würde man etwas eingeben und wo genau würde man das dann sehen? -- Sumpfhütte 09:44, 9. Jul. 2017 (UTC)

Wie würde denn ein Artikel dem Stand 1.12 entsprechen, wenn er nicht vollständig überarbeitet wäre? Oder meinst du mit "vollständig überarbeiten", dass man die Hälfte neu formuliert und noch 20% Informationen, die schon immer da waren, draufschlägt? Das ist doch für die Aktualität kein Kriterium. Iwer Sonsch (Diskussion) 09:49, 9. Jul. 2017 (UTC)

Am einfachsten wäre eine versteckte Kategorie, diese wird wie eine normale Kategorie eingebunden und durch ein magisches Wort auf der Kategorienseite ist diese unter den Artikeln nur zu sehen, wenn man in seinen Einstellungen das Anzeigen versteckter Kategorien aktiviert hat.   HorseHead MarkusRost (Diskussion) 09:52, 9. Jul. 2017 (UTC)
Man schreibt einfach bitte in die Kategorienseite? Iwer Sonsch (Diskussion) 09:57, 9. Jul. 2017 (UTC)
(Bearbeitungskonflikt × 3)
Nein, __HIDDENCAT__.
Meine Idee wäre: Dem Artikel wird einfach ganz unten vor den Interwiki-Links eine Vorlage wie bspw. {{Stand|1.12}} (vllt sogar {{Stand|1.12|17w54a}}) hinzugefügt. Diese Vorlage fügt den Artikel einer versteckten Kategorie zu. Das kann man dank Modul:Version/Nummern sogar automatisieren, sodass es nur zwei Kategorien gibt, nämlich "Aktuelle Artikel" und "Inaktuelle Artikel" (dann muss man nicht für jede neue Version eine neue versteckte Kategorie erstellen). Gleichzeitig fügt sie einen Link Letzte vollständige Aktualitätsüberprüfung für 1.12 (oder so) hinzu, der auf die Kategorie verlinkt, den man aber nur sehen kann, wenn man ein bestimmtes Helferlein aktiviert hat. | violine1101 (Diskussion) 10:00, 9. Jul. 2017 (UTC)
Zwei Kategorie halt ich für eher ungünstig, nicht alles änder sich immer und man kann so die ganz alten nicht von den fast aktuellen unterscheiden. Auch eine Sortierung [[Kategorie:Kontrolle_alt|1.10]] würde nicht funktionieren, da nach dem ersten Zeichen gelistet wird. Somit wäre eine Kategorie pro (Voll-)Version nötig. Eventuell landen diese Kategorien alle in einer Überkategorie, sodass man eine Liste alle Versionen mit Artikeln finden kann, die nach Version sortiert ist. Dort kann dann auch stehen 1.6 - 3 Seiten. So kannman leicht bei den alten anfangen.   HorseHead MarkusRost (Diskussion) 10:07, 9. Jul. 2017 (UTC)
Kann man die 12 in 1.12 nicht als Integer lesen lassen? Die Idee mit der Vorlage finde ich jedenfalls gut. Und ja, mehrere Kategorien in einer Überkategorie würden eigentlich auch funktionieren. Iwer Sonsch (Diskussion) 11:03, 9. Jul. 2017 (UTC)
Nein, es wird das erste Zeichen genommen zum Sortieren, also werden "1", "11", "12", "1.12" etc. alle an der gleichen Stelle einsortiert.
Mein Gedanke war halt, dass man eigentlich nur wissen muss, ob eine Seite überhaupt inaktuell ist. Aber mit einzelnen Versionskategorien geht das natürlich auch, neue Versionen kommen ja jetzt nicht so oft raus. Da stellt sich jetzt aber noch die Frage: Wie weit soll man da gehen? Reicht "1.11" oder sollen kleinere Updates wie 1.11.2 eine eigene Kategorie bekommen? | violine1101 (Diskussion) 11:13, 9. Jul. 2017 (UTC)

Ich würde nur für die Hauptversionen Kategorien anlegen, die genauere (Entwicklungs-)Version kann ja als zweiter Parameter in der Vorlage stehen und nur im Hinweis auftauchen. Dann kann man es immer noch unterscheiden   HorseHead MarkusRost (Diskussion) 11:17, 9. Jul. 2017 (UTC)

Ich habe jetzt mal die Vorlage {{Stand}} erstellt. | violine1101 (Diskussion) 12:23, 9. Jul. 2017 (UTC)
Okay, Vorlage und Helferlein sind fertig und einsatzbereit. | violine1101 (Diskussion) 15:58, 9. Jul. 2017 (UTC)

Anleitung für Ansichten im Wiki[]

Was haltet ihr davon, Fussels Anleitung zur Erstellung von isometrischen Bildern als "Minecraft Wiki:Isometrische Bilder" offiziell ins Wiki zu übernehmen? (unter "Minecraft Wiki", da es eine Anleitung fürs Wiki ist). -- Sumpfhütte 12:54, 25. Jul. 2017 (UTC)

Es sind keine isometrischen Bilder, steht schon in der Einleitung. :D
Also darauf hatte ich gehofft, dass der Artikel an so eine Stelle übernommen werden kann, obwohl ich eher an "Hilfe:" gedacht hatte. Ich bin aber einerseits noch nicht fertig, und andererseits überarbeite ich die Anleitungen noch einmal. Es ist gerade etwas überkompliziert, um dem Nutzer so viel Arbeit wie möglich mit Blender zu ersparen, aber ich denke, ein bisschen kann man dann schon erwarten. Außerdem hat es mir irgendwie die UV-Mappings zerhauen, deswegen muss ich an alle Vorlagen nochmal ran. Ich melde mich dann, wenn ich fertig bin. – Fusseel 14:45, 25. Jul. 2017 (UTC)


So, ich denke, jetzt habe ich es.

Also, die ganze Sache mit meiner Anleitung war nämlich so gedacht, da ja langsam aber sich das große Texturenupdate naht, allen Autoren die Möglichkeit zu geben, mitzuhelfen, ohne sich dieses teilweise recht komplexe Thema selbst erarbeiten zu müssen. Außerdem finde ich sowieso, dass es zu diesen speziellen Ansichten viel zu wenige Infos gibt, da gibt es halt immer ein paar Nutzer, die diese hochladen, aber wie sie konkret erstellt werden wird nirgendwo verraten. Vor allem am Anfang hat mich das persönlich sehr interessiert und letzten Endes bin ich dann nur dazu gekommen, indem ich mir fast alles selbst erarbeitet habe. Dann denke ich auch, dass es an der Zeit ist, sich hinsichtlich der Ansichten vom englischen Wiki abzusetzen. Einerseits besteht eine viel zu große Abhängigkeit und andererseits sind die Ansichten dort nicht wirklich einheitlich, was ich mir schon irgendwie wünschen würde und daher, da sowieso jetzt bald fast alles erneuert werden muss, es für angebracht finde, genau das umzusetzen.

Also, die Anleitung kann hier gefunden werden. Es geht zuerst um Blockrendern, dann Kreaturen und Objekt sowie am Schluss um ganze Szenen (Bauwerke/Blockstrukturen). Um die besagte Einheitlichkeit zu erreichen, habe ich mal in diesem Abschnitt einige Vorgaben festgesetzt, die sich aus meiner eigenen Arbeit mit den Rendern ergeben haben. Die Vorgaben sind ziemlich konkret, aber genau das ist nötig, damit bspw. beim Stamm im Steckbrief auch mal ein einzelner Block erneuert werden kann, ohne gleich sechs neu Render machen zu müssen, was momentan der Fall wäre.

Ich würde mich besonders freuen, wenn mal jemand, der vielleicht noch nicht so viel Erfahrung mit Blender hat, sich die Zeit nimmt und die entsprechende Anleitung mal ausprobiert. Benötigt werden momentan:

  • Neuer Render der meisten Stufen (obere Textur momentan um 90° verdreht)
  • Neuer Render aller Glasscheiben (auch die obere Textur ist falsch)
  • Render von Blumentöpfen mit Inhalt

Die Vorlagen dazu sind alle im Artikel zu finden, weitere Vorlagen folgen auch noch, sobald sie benötigt werden. Alle Vorlagen liegen übrigens in einer Cloud, die ich privat niemals nutze. Deswegen besteht auch keine Gefahr, dass ich sie aus Platzmangel oder dergleichen mal lösche und sie dem Wiki nicht mehr zur Verfügung stehen.

Wie bereits in meiner Antwort auf Sumpfhütte angesprochen fände ich es wirklich ganz schön, wenn die Anleitung, wenn sie dann mit der Einarbeitung eures Feedbacks zu 100% fertig ist, nicht auf meiner Benutzerseite versauert oder in Anleitungen/ verschwindet, sondern irgendwo verfügbar wird, wo jeder Autor und vielleicht auch Leser leichten Zugriff hat. Denn wie gesagt, diese Render und Ansichten generell sind für die meisten ein großes Mysterium, und das somit endgültig für alle aufzuklären wäre mein eigentliches Ziel. – Fusseel 20:36, 27. Jul. 2017 (UTC)

Hervorragende Arbeit! Endlich ist die Abhängkeit vom engl. Wiki nicht mehr nötig. Als die Kaninchen ins Spiel kamen, habe ich im engl. Wiki um Babykaninchenbilder gebeten. Keine Reaktion. Dort wissen auch nur eine Handvoll Leute, wie das geht. Jetzt können wir selbst und nach unseren eigenen Vorgaben diese Ansichten erstellen. - Verschiebe deine Seite doch einfach jetzt nach "Hilfe:Genormte Ansichten", verlinke sie mit einem passenden Icon, das du dir ausdenkst, auf der Hilfe-Startseite "Hilfe:Übersicht" und baue sie in die Navbox "Vorlage:Navbox-Hilfe" ein. Verbesserungen und Feedback können auch dort noch vorgenommen werden, das ist ja im Wiki so üblich. -- Sumpfhütte 08:44, 28. Jul. 2017 (UTC)
Habe es verlegt und eingetragen. Da bin ich mal auf die Tester gespannt. – Fusseel 17:59, 28. Jul. 2017 (UTC)

Bindestrich bei Editionen[]

Abschnitt Geräusche[]

In den Artikeln zu Kreaturen gibt es ja diesen Abschnitt "Geräusche". Ich finde es sowieso etwas fraglich, wen tatsächlich interessiert, was die Kreaturen für Geräusche machen und dazu funktioniert der Audioplayer auch bei mir weder am Desktop noch auf irgendeinem Mobilgerät, aber das sei mal dahingestellt. Schlimmer ist die Gestaltung des Abschnittes, da er mit seiner sehr geringen Bedeutung momentan einfach eine riesige Menge Platz wegnimmt. Da sich der Inhalt auf die linke Seite konzentriert, entsteht rechts gerade auf einem großen Bildschirm ein riesiger, leerer Freiraum. Die kleine Erklärungsbox zu den einzelnen Geräuschen ist zudem auch nicht sonderlich gut untergebracht. Daher habe ich mal eine neue Designvorlage ausgearbeitet, die diese Probleme behebt und vor allem für eine kompaktere Darstellung sorgt. Sie kann hier angesehen werden. Wenn niemand etwas dagegen hat würde ich sie dann gerne demnächst überall einführen. – Fusseel 18:50, 25. Sep. 2017 (UTC)

Die vielen Beschriftungen "1. Geräusch, 2. Geräusch, ..." entfallen => gut. Waagerechte statt senkrechte Ausrichtung => okay. Tooltipps statt Erklärbox => Möglicherweise mobil nicht lesbar? Die Erklärbox könnte bei der waagerechten Ausrichtung auch unter der Tabelle stehen. Auch einfach nur die Texte ohne Box. -- Sumpfhütte 09:09, 26. Sep. 2017 (UTC)
Das stimmt, die Tooltips sind in der mobilen Ansicht nicht einsehbar. Dann packe ich deren Inhalte mit in den kurzen Einleitungstext zum Abschnitt. Ich will diese Erklärungsbox sehr gerne vermeiden, denn der ganze Hintergedanke bei dieser Umgestaltung ist, diesen unbedeutenden Abschnitt "Geräusche" so kompakt wie überhaupt möglich zu gestalten. Die Erklärungsbox nimmt da im Verhältnis zum Wert ihrer Informationen einfach zu viel Platz weg, zumal die einzelnen Begriffe auch ohne Erklärung verständlich sind. – Fusseel 19:59, 27. Sep. 2017 (UTC)
Du hast recht, die Erklärung ist redundant. Aber ohne Erklärung blieben die Überschriften bisher für Neulinge unverständlich. Wie wäre es, die Erklärung in die Überschriften zu nehmen und dafür den Zusatztext komplett wegzulassen? Also statt der erklärungsbedürftigen Substantive: "Nichtstun", "Verletzung", "Tod" und "Schuss" die Verben: "tut nichts", "wird verletzt", "stirbt", "schießt"? -- Sumpfhütte 11:31, 28. Sep. 2017 (UTC)
Das finde ich super, ich setze es gleich beim Ghast um. – Fusseel 11:46, 28. Sep. 2017 (UTC)

Sitenotice schließen[]

Durch irgendeine Änderung (MediaWiki? Wir?) hat die MediaWiki:sitenotice bei mir jetzt einen [Schließen]-Zusatz, der bewirkt, dass mein Browser bei jeder einzelnen Wiki-Seite wackelt, weil dieser Zusatz erst fehlt und dann hinzugefügt wird. Wie kann ich das abschalten (mit CSS)? -- Sumpfhütte 11:39, 26. Sep. 2017 (UTC)

Ich kenne mich damit jetzt nicht aus, aber dieser [Schließen]-Zusatz war schon immer da. Wird daher aus meiner Sicht wohl an einer persönlichen Einstellung liegen. Was mich auch nervt ist, wenn man da drauf klickt, das man die Sitenotice nicht mehr wieder öffnen kann. -- Nethonos 11:47, 26. Sep. 2017 (UTC)
Schließen konnte man sie schon immer, nur war sie vorher einfacher zu entfernen. Seit neustem ist allerdings ein !important nötig. Um eine geschlossene Notiz wieder zu öffnen muss man einmal seine Cookies löschen, ob sie bei einer Änderung der Notiz automatisch wieder erscheint weiß ich jetzt aber nicht.
/* siteNotice schließen weg */
.globalNoticeDismiss
{
    display: none !important;
}
Dies in einer .css entfernt das Schließen und den zusätzlichen Platz der erst später erscheint.   HorseHead MarkusRost (Diskussion) 11:55, 26. Sep. 2017 (UTC)
Funktioniert. Danke :-) -- Sumpfhütte 12:45, 26. Sep. 2017 (UTC)

Geräusche entfernen?[]

Ich bin dafür den Abschnitt "Geräusche" in allen Artikeln zu entfernen, hier sind meine Argumente:

  • Falsch: einige Geräusche werden durch das Spiel selbst noch verändert, "pitch" und "volume" sind möglich. Gerade durch "pitch" klingen die Geräusche z. T. ganz anders als die Quelldateien, bestes Beispiel: Papagei ahmt andere Kreaturen nach; die Werte für die Abänderung werden entweder in einer externen .json Datei, oder direkt im Code mittels playSound() vergeben.
  • Unvollständig: in sehr vielen Artikeln fehlen einige der Sounds, gelegentlich sogar ziemlich viele, bei einigen Artikeln fehlen sie auch ganz. Beispiele: vier bei Zombie, zwei bei Shulker, drei bei Kuh, 16 bei Pferd, 13 bei Dorfbewohnerzombie, 48 bei Papagei, ...
  • Irrelevant: es handelt sich nur um ganz kurze Töne, es sind keine wirklichen Informationen, die den Leser interessieren; durch die isolierte Darstellung sind die Töne außerdem gänzlich aus dem Kontext des Spiels gerissen
  • Teilweise Funktionslos: keine Funktion unter iOS; nur eingeschränkt unter macOS (Standardbrowser Safari nicht, Google Chrome schon); Android ja; Windows mit Chrome, weitere keine Informationen

Anstatt sich jetzt daran zu setzen und diese ganzen Probleme zu beheben, bin ich dafür, dieses Projekt für gescheitert zu erklären und den Abschnitt überall zu löschen. Er ist einfach viel zu irrelevant und meiner Meinung nach die benötigte Aufmerksamkeit nicht Wert. Es gibt genügend andere Artikel, die wirklich relevant sind und eine Überarbeitung benötigen (z. B. Blöcke und Kreaturen). Das engl. Wiki hat ebenfalls vor einer ganzen Weile damit aufgehört, überall die Geräusche einzufügen, dem sollten wir uns endlich anschließen. Etwas muss auf jeden Fall geschehen, in diesem halbfertigen Zustand können die Abschnitte nicht bleiben. – Fusseel 12:35, 1. Okt. 2017 (UTC)

So ist das mit dem Spiel: Anfangs war ein Aspekt noch klein und übersichtlich, aber mit der Zeit ufert es aus (Add-ons, Geräusche, Realms). Wir haben das Wiki schon an verschiedenen Stellen zurückgebaut, um übersichtlich und aktuell bleiben zu können. Ich bin auch hier für einen Rückbau. Aber ganz löschen würde ich die Geräusche nicht, denn ich finde den akustischen Aspekt bei den Kreaturen sehr informativ. Daher würde ich für jede Kreatur das erste Idle-Geräusch als "typisches Geräusch" stehen lassen (vielleicht im Steckbrief?), weil der Leser damit ein aktustisches Merkmal bekommt, an dem er die Kreatur im Dunkeln, oder wenn er sie sonstwie nicht sieht, erkennen kann. -- Sumpfhütte 14:30, 1. Okt. 2017 (UTC)
Das ist wirklich ein sehr guter Kompromiss, für so ein einzelnes Geräusch ist der Steckbrief dann der beste Ort. Deine Argumentation dahinter ist auch sehr schlüssig. – Fusseel 8:33, 3. Okt. 2017 (UTC)
Wir entfernen gerade einen großen Teil der Geräusche, die ungenutzten Geräusche würde ich dann heute Abend löschen. Angesichts der Anzahl dieser, eventuell auch mit dem Bot (@Sumpfhuette?)   HorseHead MarkusRost (Diskussion) 10:03, 9. Okt. 2017 (UTC)
Prima :-) -- Sumpfhütte 15:03, 9. Okt. 2017 (UTC)
Alle Kreaturen-Geräusche müssten nun im Steckbrief oder ungenutzt sein. Jetzt bräuchte mein Bot bloß noch die Rechte zum Löschen der 480 Sound-Dateien.   HorseHead MarkusRost (Diskussion) 18:03, 9. Okt. 2017 (UTC)
Erledigt Alle 480 Sound-Dateien sind nun gelöscht.   HorseHead MarkusRost (Diskussion) 19:04, 9. Okt. 2017 (UTC)

Die Schleime, Magmawürfel und Eisengolems haben jetzt im Wiki kein Geräusch. Man kann sie aber sofort anhand ihres typischen Bewegungsgeräusches identifizieren, auch wenn man sie nicht sieht (was gerade bei Schleimen in Höhlen wichtig zu wissen wäre). Daher würde ich "Bewegung" als typisches Geräusch nehmen, wenn "Nichtstun" geräuschlos ist. - Und bei Hühnerreitern würde ich analog zum Spinnenreiter die Geräusche Huhn + Zombie einsetzen. - Sonderfall Creeper: Als typisches Geräusch fällt einem sofort das Zischen ein. Auch der Papagei imitiert den Creeper (entity.parrot.imitate.creeper). Die Reaktionszeit für den Spieler ist zwar nur kurz, aber wenn man das Zischen hört, könnte man immer noch schnell weglaufen. - Bleiben nur Ozelots, Riesen und Schneegolems, die akustisch nicht erkannt werden können und somit im Wiki geräuschlos bleiben. - Die Definition in der Steckbrief-Doku müsste dann so angepasst werden, dass jedem Autoren bei zukünftigen Kreaturen klar ist, was als "Geräusch" aufgenommen wird. -- Sumpfhütte 06:08, 10. Okt. 2017 (UTC)

Da stimme ich zwar zu, allerdings sind die Geräusche nicht immer wirklich zur Identifikation geeignet.
  • Der Eisengolem ist nicht an einem einzelnen Schritt zu erkennen. Das Geräusch eignet sich also nicht wirklich.
  • Beim Hühnerreiter ist das Problem, dass die Babyzombies das Zombiegeräusch nur höher machen. Dies wird erst direkt im Spiel geändert und ist daher nicht als eigene Sounddatei enthalten. Das normale Zombiegeräusch würde also nicht stimmen. Man müsste ein Babyzombiegeräusch erstellen.
  • Der Creeper hat als eigene Sounds nur Verletzung und Tod, nicht aber das Zischen vom Zünden. Dieses teilt er sich mit TNT. Trotzdem finde ich, dass sich das Zischen zum Identifizieren eignet.
  • Die Schleime sind an ihren Hüpfgeräuschen aber tatsächlich gut zu erkennen, da sie ja auch nicht stehenbleiben können.
  HorseHead] MarkusRost (Diskussion) 07:08, 10. Okt. 2017 (UTC)
Das sehe ich eigentlich auch so. Eisengolem ist nicht so gut möglich, Creeper, Schleim und Magmawürfel kann man machen. Beim Hühnerreiter schaue ich mal, ob ich etwas hinbekommen. Da braucht man ja gleich für alle vier Reiter einen eigenen Sound. – Fusseel 07:13, 10. Okt. 2017 (UTC)
Die gewünschten Geräusche sind jetzt überall eingefügt. – Fusseel 16:03, 10. Okt. 2017 (UTC)

Versionsvorlagen[]

Ich wollte die Versionsvorlagen ({{Education}}, {{Konsolenedition}}, {{Pi Edition}}, {{PlayStation}}, {{Bedrock Edition}}, {{Switch}}, {{Wii U}}, {{Xbox}}) vereinheitlichen (wie en:Template:Exclusive) dabei ist mir aufgefallen, dass die meisten der Vorlagen ungenutzt sind ({{PlayStation}}, {{Switch}}, {{Wii U}}, {{Xbox}}) und nur die Vorlage:Pi Edition eine Kategorie zuweist.

Da in der Kategorie:Pi Edition nur zwei alte Bedrock Seiten vorhanden sind würde ich diese entfernen und die Vorlage nur noch mit Java Edition, Bedrock Edition, Konsolenedition und Education Edition erstellen. Wie wäre eure Meinung dazu?   HorseHead MarkusRost (Diskussion) 13:11, 8. Okt. 2017 (UTC)

Ich wäre dafür; dann wäre es genauso wie im englischen Wiki. Die ganzen alten Konsoleneditionen sind ja sowieso gleich, da muss man nicht das Betriebssystem unterscheiden. Früher waren die Editionen für Xbox 360 und Playstation 3 noch unterschiedlich, da gabs dann eben zwei Vorlagen dafür; und dann wurde eben für jede neue Plattform eine neue Vorlage erstellt. Das ist jetzt nicht mehr so, man kann die Editionen auf vier Gruppen reduzieren: Bedrock, Java, Legacy Console und Education. | violine1101 (Diskussion) 13:20, 8. Okt. 2017 (UTC)
Alles zusammenzuführen ist nötig, aber meiner Meinung nach kann man aus der Vorlage noch mehr machen. Statt einfach nur oben diesen kleinen Vermerk zu haben würde ich die Artikel lieber einfärben/umranden (entweder beides oder nur umranden). Das Konzept ist dann auch für einzelne Abschnitte und sogar Sätze anwendbar, was ja momentan nicht so gut möglich ist. Majr aus dem engl. Wiki hat die Umsetzung hier demonstriert. Da der Fokus dieses Wikis auf Java liegt, finde ich es ziemlich gut, wenn die externen Informationen noch einmal richtig herausstechen. Das Farbschema kann man dann so im gesamten Wiki durchsetzen, dass man Inhalte einer bestimmte Edition immer direkt anhand einer Farbe identifizieren kann. Natürlich müssen die Farben gut gewählt sein, damit sie nicht stören. Das Konzept wurde hier noch einmal von Majr weiter ausgebaut. Vielleicht kann man dafür sogar in der Sidebar oder am Seitenende überall noch eine kleine Legende einfügen.
Ich finde auf jeden Fall, dass das Wiki durch so eine Einfärbung noch einmal deutlich strukturierter werden würde. Momentan verschwimmen manche Editionen nämlich gelegentlich. Was meint ihr dazu? – Fusseel 17:55, 8. Okt. 2017 (UTC)
Hm. Ich habe mir Majrs Beispiele angeschaut. Ich finde das eine unnötige Spielerei. Der Einsatz dieser Vorlage würde das Wiki wieder einen Schritt komplizierter machen, was für die langfristige Wartung des deutschen Wikis (wenige Autoren, wenig Zeit) keine gute Idee ist. Daher bevorzuge ich immer einfache, wartungsfreie Lösungen. In diesem Fall ist es völlig ausreichend, wenn es drei Überschriften gibt: "Java Edition", "Bedrock Edition", "Konsolenedition", zu denen man über das Inhaltsverzeichnis schnell und leicht navigieren kann. -- Sumpfhütte 13:29, 9. Okt. 2017 (UTC)
Zu MarkusRosts Frage: Ich stimme violine1101 zu, nur "Konsolenedition" statt "Legacy Console". -- Sumpfhütte 13:33, 9. Okt. 2017 (UTC)


MC Java LogoMC Bedrock LogoKonsoleneditionMC Education Logo 1.0
Nur in der Java Edition, Bedrock Edition, Konsolenedition und Education Edition.

Ich würde es wohl etwa so aussehen lassen, allerdings sind die Bilder alle in verschiedenen Größen und die Seitenverhältnisse sind auch verschieden. Mag mir da vielleicht jemand Bilder in der passenden Größe hochladen? Außerdem bin ich mir noch nicht sicher, wie man die Vorlage am besten nennt.   HorseHead MarkusRost (Diskussion) 10:11, 20. Nov. 2017 (UTC)

"Vorlage:Exklusiv" wie im engl. Wiki? => {{exklusiv|Java|Bedrock}} -- Sumpfhütte 13:30, 20. Nov. 2017 (UTC)

Steckbriefe: "Einführung" und "Kategorie" entfernen[]

Ich würde gerne in den Steckbriefen "Einführung" und "Kategorie" entfernen. Unter Einführung ist immer nur ein Link auf den Geschichtsabschnitt, da kann man genauso über das Inhaltsverzeichnis gehen, wo man eher nach so etwas sucht. Für "Technischer Block" kann der Parameter zumindest in Vorlage:Block und Vorlage:Blockobjekt optional verfügbar bleiben. Kategorie finde ich einfach nicht wichtig, um einen Platz im Steckbrief zu haben. Zumal diese vom Wiki vergeben werden und nicht irgendwie von Mojang festgelegt wurden, wodurch sie im Spiel nicht von Bedeutung sind. Hat jemand etwas gegen diese Entfernungen? – Fusseel 20:50, 14. Okt. 2017 (UTC)

Geschichte ist für die meisten Leser weniger wichtig. Außerdem steht "Geschichte", wie du sagst, im Inhaltsverzeichnis. Die Kategorie gibt aber durchaus einen nützlichen Mehrwert: Mit einem Klick kommt man zu einer übersichtlich strukturierten und mit Sprites versehenen Navigationsbox. Das sollte bleiben. -- Sumpfhütte 16:33, 16. Okt. 2017 (UTC)

Befehle mit /Vor 1.13[]

Eventuell sollten wir mit 1.13 für den Befehl /execute, den Befehl /scoreboard und den Befehl /xp jeweils eine Unterseite mit /Vor 1.13 erstellen, da sich ihre Syntax und Funktion stark ändert.   HorseHead MarkusRost (Diskussion) 19:01, 8. Nov. 2017 (UTC)

Ich finde den Vorschlag auch gut. Dann könnte man beide Artikel jeweils parallel bearbeiten und man hätte die alte Syntax zum Nachschlagen noch zur Verfügung. -- Nethonos 19:05, 8. Nov. 2017 (UTC)
Wie wäre eine Sammelseite für diese 3 Befehle als Unterseite von "Befehl"? -- Sumpfhütte 07:11, 9. Nov. 2017 (UTC)
Wenn es eine Sammelseite wäre (Befehle/Entfernte), dann sollen dort wohl alle entfernten Befehle hin, nicht nur die drei? Dann würde die Seite sehr groß und lang werden, weil die Syntax und die Beschreibung bei manchen Befehlen sehr lang ist und die entfernten Befehle würden dann vermutlich nicht in der Navigationsbox unter Befehle auftauchen?
Als Beispiel für die einzelnen Befehle mit dem Zusatz „/vor 1.13“ hätten wir im Prinzip ja schon den Befehl /achievement, der als veraltet markiert wurde und wie die anderen entfernten Befehle in der Navigationsbox auftauchen. -- Nethonos 08:43, 9. Nov. 2017 (UTC)
Okay, separat pro Befehl ist besser. Ich habe mir mal die Änderungen angeschaut. Veränderungen von geringem Umfang wie bei /scoreboard und /xp haben wir aber bisher nie gesondert aufgeführt. Ich würde sagen, nur /execute rechtfertigt eine "vor 1.13"-Seite. -- Sumpfhütte 09:25, 9. Nov. 2017 (UTC)
Stimmt, die Änderungen von /scoreboard sind kaum bis garnicht nennenswert, da einfach die beiden Befehle /tag und /team ausgelagert wurden. Aber die Syntax vom Befehl /xp ändert sich ja drastisch. Da finde ich, wäre ein Artikel zur alten Syntax weiterhin passend.
Die Befehle /enchant, /stats, /testfor, /testforblock, /testforblocks, /toggledownfall entfallen und werden nach dem Erscheinen der Vollversion 1.13 in der Navigationsbox unter „entfernt“ aufgeführt. Das bedeutet das dort sowieso viele alte Befehle aufgeführt werden, die man dann aber einsehen kann. Mit dem Sammelartikel wäre es also auch dann leider sehr viel auf einmal. -- Nethonos 09:42, 9. Nov. 2017 (UTC)
Ja, entfernte Befehle sollten wie andere entfernte Dinge (wie bspw. die verschlossene Truhe) weiter im Wiki vorhanden sein, aber eben als veraltet markiert werden. Wie schon gesagt wurde, die Änderungen von /scoreboard und /xp bzw. /experience dürften sich sehr leicht in der Geschichtsbox zusammenfassen lassen, im Gegensatz zu /execute. Ich finde, am besten wäre ein weiterer Unterabschnitt unter "Geschichte" für /execute, das muss nicht unbedingt auf eine Extraseite – die Befehlsseiten sind ja nicht sonderlich lang. | violine1101 (Diskussion) 17:47, 9. Nov. 2017 (UTC)
Die Befehlsseiten sind zwar nicht sehr lang, allerdings ist der Befehl /execute bereits jetzt einer der längeren Befehle. Mit 1.13 wird /execute noch deutlich länger und komplizierter werden, da dann die ganzen Unterbefehle, Bedingungen und Aneinanderkettungen hinzukommen. Dadurch dürfte die Seite etwas unübersichtlich werden und ein großer Geschichtsabschnitt mit einer anderen Syntax und Beschreibung ist dabei nicht unbedingt hilfreich.   HorseHeadMarkusRost (Diskussion) 17:54, 9. Nov. 2017 (UTC)
Advertisement