Das offizielle Minecraft Wiki twittert hier: Wiki-Twitter  –  Chatte im Wiki-Discord  –  Noch keinen Server gefunden? Es gibt einen Wiki-Server

Minecraft Wiki Diskussion:Gemeinschaftsportal/Archiv 17

Aus Minecraft Wiki
Wechseln zu: Navigation, Suche
Bücherregal.png
Dies ist das Archiv der Gemeinschaftsportaldiskussion für Januar bis Juli 2018. Bitte bearbeite diese Seite nicht.
Neue Fragen können auf der aktuellen Diskussionsseite gestellt werden.

Englische Bezeichnung in der Einleitung[Bearbeiten]

Vor einiger Zeit haben wir mit großem Aufwand aus allen Kreaturen-, Block- und Gegenstand-Artikel die englische Bezeichnung rausgenommen ("Kies, engl. Gravel, ist ...") mit der Begründung, dass wir das deutschsprachige Wiki sind und man nur auf den Interwikilink klicken muss, um zum englischen Text zu kommen. Ist es sinnvoll, dies bei den Bauwerken und Biomen trotzdem einzutragen? Falls ja, würde ich gerne eine einfache Regelung finden, die verhindert, dass ein übereifriger Neuling damit beginnt, überall den engl. Begriff einzutragen. -- Sumpfhütte 15:43, 6. Jan. 2018 (UTC)

Ich persönlich bin kein Freund der englischen Bezeichnung in der Einleitung. Allerdings könnte ich mich zumindest bei den Biomen und Bauwerken damit abfinden, da es für diese keine offizielle deutsche Bezeichnung gibt.   HorseHead.png MarkusRost (Diskussion) 16:32, 6. Jan. 2018 (UTC)
Genau, das war der Hintergedanke dabei. Bei Biomen und Bauwerken ist der englische Begriffe halt auch die einzige offizielle Bezeichnung, weswegen es schon Sinn ergibt diesen aufzuführen. Wenn englischer Begriff und deutsche Übersetzung natürlich fast identisch sind ist das überflüssig, wie bei "Taiga". – Fuzs 17:55, 8. Jan. 2018 (UTC)
Bei einigen Bauwerken gibt es offizielle Bezeichnungen in der Angepasst-Welt. -- Sumpfhütte 19:01, 8. Jan. 2018 (UTC)
Das habe ich wiedermal vergessen. Dann ergibt die englische Bezeichnung wirklich nur bei den Biomen Sinn und dort ist sie schon überall. – Fuzs 19:22, 8. Jan. 2018 (UTC)

Dezimale IDs von Blöcken in 1.13[Bearbeiten]

Im Wiki wurden bereits in vielen Steckbriefen von Blöcken und dergleichen die dezimalen IDs entfernt, sodass nur noch der ID-Name zurückbleibt. Allerdings zweifle ich daran, denn obwohl die Metadaten tatsächlich weg sind scheint es in 1.13 weiterhin dezimale IDs zu geben. Im Gegensatz zu den ID-Namen haben sich allerdings alle dezimalen IDs geändert (außer Luft :P). Sie sind jetzt genau das 16-fache der vorherigen ID, um Platz für die Metadaten zu machen, die die dazwischenliegenden Plätze beanspruchen. Beispiele:

  • Stein: 1 --> 16
  • Andesit: 1:5 --> 21
  • Roter Sand: 12:1 -->193

Alle 1.687 dezimalen IDs habe ich in 18w01a in wm.class gefunden. Es wäre auf jeden Fall super, wenn sich das nochmal jemand vornimmt, da es solch eine Zuordnung für Gegenstände wiederum nicht mehr zu geben scheint, selbst in der Item.java (anl.class in 18w01a) sind alle dezimalen IDs weg. Deswegen bin ich nicht so sicher, ob in wm.class wirklich die neuen dezimalen IDs sind, oder ob das damit am Ende nichts zu tun hat. – Fuzs 17:09, 9. Jan. 2018 (UTC)

Numerische IDs werden weiterhin verwendet, und zwar in den Datenpaketen zwischen Server und Client, weil sie kürzer sind, als ID-Namen. Der Datengenerator liefert alle Blöcke und Gegenstände mit ihren IDs. Diese sind fortlaufend durchnummeriert und ändern sich mit jeder Version. Die IDs, die du gefunden hast, könnten zur internen Konvertierung 1.12->1.13 gehören. Man kann ja 1.12-Welten mit 1.13 laden. Diese IDs werden sich nie ändern, denn der 1.12-Datensatz an IDs und Metadaten ändert sich nicht mehr. -- Sumpfhütte 19:35, 9. Jan. 2018 (UTC)

svg-Fehler[Bearbeiten]

Seit zwei Wochen werden Datei:Android.svg und Datei:Flag_of_the_United_Kingdom.svg als Text angezeigt, wenn sie in einem Artikel eingebunden sind. Curse kennt das Problem, aber noch keine Lösung, außer sie durch png-Dateien zu ersetzen. -- Sumpfhütte 17:54, 2. Feb. 2018 (UTC)

Datei:Flag_of_the_United_Kingdom.svg ist bei mir wieder zuverlässig da, seit dem ich die Seite vor zwei Tagen manuell aktualisiert habe. Das Android Logo fehlt aber weiterhin. – Fuzs 18:06, 2. Feb. 2018 (UTC)

Seiten zu den Versionen[Bearbeiten]

Aktuell bin ich am überlegen, ob wir vielleicht mit dem EN-Wiki gleichziehen und für (fast) jede Version eine eigene Seite erstellen sollten.
Warum? Ganz einfach: Aktuell sind die meisten Seiten einfach viel zu überfüllt und werden dadurch unübersichtlich.
Was meint ihr dazu? ---- BohneFJS(Diskussion|To Do-Liste) 18:43, 3. Feb. 2018 (UTC)

Ich fände das schlecht. Der Vorteil der jetzigen Lösung ist, dass man auf der Seite suchen kann, wenn man wissen will, wann ein bestimmtes Feature hinzugefügt wurde. Im engl. Wiki muss man sich durch viele Seiten klicken, was äußerst nervig ist. -- Sumpfhütte 10:56, 4. Feb. 2018 (UTC)
Das gibt es im englischen Wiki auch, siehe hier. Die Seite wird automatisch aus den ganzen Unterseiten generiert, macht also nicht einmal zusätzliche Arbeit und ist selbst so schon übersichtlicher als unsere riesigen Tabellen. – Fuzs 12:03, 4. Feb. 2018 (UTC)
Ich bin auch der Meinung wie @Sumpfhütte:, denn die jetzige Lösung ist einfach besser, weil man nicht durch die Artikel hindurchstöbern muss um an die Neuerungen zu kommen, aber auch weil man mit einer Bearbeitung Zugriff zu allen Entwicklungsversionen hat. Außerdem muss das jemand auch immer aktuell halten und ich finde das so am allerbesten, dafür das man nicht wie im englischen Wiki über eine riesige Autoren-Gemeinschaft verfügt. -- Nethonos 12:32, 4. Feb. 2018 (UTC)
Die von Fuzs genannte Variante im engl. Wiki kannte ich nicht. Sehr interessant. Aber wieder mal ein Lua-Skript, es gibt im dt. Wiki fast keine Person, die so etwas anpassen kann. Zum Glück ist dieses spezielle Skript nicht allzu lang, das geht noch. Solange es beide Versionsvarianten gibt, wäre ich einverstanden. Die Fehler sollten aber weiterhin eingeklappt sein. -- Sumpfhütte 13:32, 4. Feb. 2018 (UTC)
Dass man sich bei der Lösung des englischen Wikis durch 1000 Seiten durchklicken muss, habe ich auch schon bedacht. Wie wäre es, wenn wir alle jetzigen Versionsseiten einfach so stehen lassen und dort eine Auflistung aller Versionen machen? Wenn der Leser wissen will, was z.B. in der Bedrock Version Alpha 0.15.0 hinzugefügt wurde, kann er dies mit nur einem Klick auf dieser Seite herausfinden.
Bei der aktuellen Lösung würden glaube ich nur die wenigsten auf einer überfüllten Seite nach der gewünschten Version suchen. Es gibt zwar ein Inhaltsverzeichnis, ist für leistungsschwache Geräte jedoch trotzdem kein Vorteil, da die Seite sonst viel zu lange zum Laden braucht. ---- BohneFJS(Diskussion|To Do-Liste) 17:28, 4. Feb. 2018 (UTC)
Eine Auflistung aller Versionen gibt es bereits auf jeder Versionenseite oben rechts. Dort auf die Pfeile klicken (Vorlage:VersionsgeschichteNav). -- Sumpfhütte 17:44, 4. Feb. 2018 (UTC)
Ich habe mir die Auflistung jedoch etwas anders vorgestellt. Und zwar ungefähr so wie im englischen Wiki (siehe hier). ---- BohneFJS(Diskussion) 17:55, 4. Feb. 2018 (UTC)
Ich bitte euch das nochmals zu überdenken, denn das ist ein irrsinniger Aufwand, dies alles erst einmal auf die Beine zu stellen (alle Snapshots auf jeweils einer Seite kopieren, wie im engl. Wiki) und zu dem haben wir nicht genug Autoren, die bei eventuellen Fehlern hunderte von Seiten durcharbeiten können. Ich hab mir in letzter Zeit viel Arbeit gemacht, gerade die 1.13-Snapshots wieder auf Vordermann zu bringen, da helfen verstreute Seiten wenig. Ich persönlich bin absolut gegen eine Zerstreuung die das Ziel hat, den Inhalt dieser Sammelseiten auf viele Seiten zu verteilen. Was ich mir aber gut vorstellen könnte, wäre wenn es eine Vorlage geben könnte, die die Möglichkeit bieten würde, dass man nur den jeweiligen einzelnen Snapshot-Inhalt aus einer Sammelseite sich anschauen könnte. Dann hätte man zum einen eine Einzelansicht und zum anderen hätten wir immer noch die Möglichkeit die Sammelseiten in Bezug auf die Versionsgeschichten mit wenig Aufwand aktuell zu halten. Ich möchte mich eigentlich nicht in den Vordergrund rücken, aber wenn ich die letzten Monate nicht für Ordnung gesorgt hätte, dann wäre jetzt vermutlich die Hälfte wohl immer noch nicht übersetzt und daher möchte ich mir nicht unnötig Mehraufwand antun, denn letztlich muss das jemand pflegen und das mache ich ja gerne, solange es einfach und auf einer Seite bleibt. Es ist nur meine Meinung, aber das wollte ich gesagt haben. -- Nethonos 20:57, 4. Feb. 2018 (UTC)

Ich bin ja schon immer für die Übernahme des Versionslayouts aus dem englischen Wiki gewesen. Ich halte es für tausendmal übersichtlicher und einfacher zu bearbeiten als das momentan benutzte. Und wenn man nur Informationen zu einer bestimmten Version haben möchte, muss man nicht die ganze Seite laden. Die Möglichkeit, alle Entwicklungsversionen zu einer Version gleichzeitig einzusehen, geht ja nicht verloren.
Ich finde, das lässt sich auch mit wenigen Leuten durchsetzen, und meiner Meinung nach ist es den Aufwand wert. Das ganze muss ja auch nicht von heute auf morgen umgestellt werden, man kann ja zuerst mit den Versionen zur 1.13 loslegen (eine nach der anderen auslagern) und dann mit denen von der 1.12 weitermachen. Dann gibt es eben eine Weile lang für die alten Versionen das alte Format und für die neuen Versionen das neue Format, bis alles umgestellt ist.
@Nethonos: Eventuell könnte ich es auch auf den Versions-Sammelseiten per Helferlein ermöglichen, dass man mehrere einzelne Versionsseiten gleichzeitig bearbeiten kann. | violine1101 (Diskussion) 22:11, 4. Feb. 2018 (UTC)

Und ich könnte auch sagen, das ich „schon immer das so belassen wollte”. Ich finde das jetzige Layout ganz in Ordnung, das im englischen Wiki besitzt einfach keine Tabelle und die Versionsvermerke sind oben rechts angeordnet, daran empfinde ich jetzt nichts was „besser” wäre, es ist einfach nur anders. Aber wenn es nur um das Layout und nicht um das Verstreuen der Seiten geht, kann man bestimmt neue Möglichkeiten probieren, um diese Auflistung der Inhalte „schöner” zu gestalten, denn das ändert ja nichts am Pflegeaufwand. -- Nethonos 14:14, 6. Feb. 2018 (UTC)
Also ich bin ja genau wie Violine1101 schon immer für einzelne Seiten. Aber ich erkenne auch, dass das Argument von Nethonos, das viele einzelne Seiten nicht von so wenigen Autoren optimal instant gehalten werden können, am wichtigsten ist. Wir schaffen es ja bei Weitem nicht einmal, die einzelnen, grundlegenden Artikel über Blöcke/Gegenstände/Kreaturen inhaltlich aktuell zu halten, da kann man so ein Megaprojekt gleich vergessen. Das angekündigte Tool zur parallelen Bearbeitung klingt natürlich verlockend, aber ich bezweifle sehr, dass es für mehr als kleine Ersetzungsaufgaben eine brauchbare Lösung darstellt. Deswegen sieht mein Vorschlag so aus:
  1. Alles bleibt so, wie es ist, und wird zukünftig (im Hintergrund) genauso wie jetzt weitergeführt. Also die Inhalte in Tabellen, zu jeder Vollversion eine eigene Seite, ...
  2. Die Leser hingegen bekommen zukünftig Einzelseiten präsentiert, ähnlich denen im engl. Wiki, mit einer Infobox oben rechts und sonst nur reinem Inhalt. Diese Einzelseiten werden hier, genau anders herum als im engl. Wiki, aus den jetzigen und auch zukünftig weitergeführten Sammelseiten generiert.
  3. Die Aufteilungsarbeit übernimmt ein eigenes Modul, sodass im Quelltext einer Seite wie z. B. en:17w47a einfach nur {{Versionsseite|17w47a}} stehen muss.
  4. Das Modul übernimmt den jeweiligen Inhalt aus der Sammelseite. Dafür kann es z. B. nach === 17w47a === suchen und ab da, bis vielleicht |- alles übernehmen (natürlich mit einer Prüfung, ob eine neue Tabelle zwischenzeitlich eingeführt wird, damit es z. B. bei 16w32a nicht schief geht).
  5. Sämtliche Zusatzinhalte zu einer Version, also zugehörige Vollversion, Versions-ID, Banner vom Blogpost, Veröffentlichungsdatum, Link zum Blog, Link zu den Downloads werden von dem Modul nicht (!) aus den Tabellen ausgelesen. Das wäre meiner Meinung nach viel zu fehleranfällig, da es zu speziell programmiert werden müsste. Diese Informationen bezieht das Modul zum Erzeugen von Einzelseiten aus einem weiteren Modul, was als eine Art Datenbank dient. Auch die Tabellen können zukünftig auf diese Datenbank zugreifen, anstatt, dass alles direkt eingetragen wird.
Das ist mein Vorschlag, ich hoffe, ich habe wirklich alles bedacht. Im Vergleich zu einer tatsächlichen Aufteilung, deren Umsetzung als auch Wartung wir nicht stemmen können, finde ich den Aufwand minimal und den Vorschlag daher für uns sehr realistisch. Eventuell müssen einmalig alte Sammelseiten angepasst werden, damit das Modul alles ohne zu viele programmierte Ausnahmefälle lesen kann, aber auch dieser Aufwand ist nichts gegen eine komplette Aufteilung. – Fuzs 16:32, 6. Feb. 2018 (UTC)
@Fuzs: das klingt richtig gut. Jetzt fällt mir auch ein, das es so was ähnliches bereits gibt. Es wurde bei den Fortschritten so gehandhabt, das eine Sammelseite alle Fortschritte beinhaltet und die einzelnen Fortschritte durch die Vorlage:Fortschritte auf die einzelnen Seiten für Blöcke/Gegenstände/Kreaturen eingebunden werden können. -- Nethonos 17:00, 6. Feb. 2018 (UTC)
Technisch gesehen wäre das ein viel größerer Aufwand als die Infos einer einzelnen Version auf eine einzelne Seite auszulagern und dann diese auf einer Sammelseite per Modul zu sammeln (so wie im englischen Wiki: en:1.13/Development versions, schau mal in den Quelltext). So könnte ich einfach das Modul aus dem englischen Wiki übernehmen, andernfalls müsste ich dieses Modul erst einmal komplett neu schreiben. Und die Beschreibungen zu den Versionen zusammenzusammeln, ist nicht so trivial, wie das bei den Fortschritten ist. | violine1101 (Diskussion) 17:28, 6. Feb. 2018 (UTC)
Der Aufwand ist mir komplett bewusst, zur Umsetzung habe ich mir schließlich ziemlich konkrete Gedanken gemacht. Dass wir das Modul des engl. Wikis nicht nutzen können musst du doch aber langsam mal einsehen. Wir sind einfach zu wenige, und selbst wenn es für ein halbes Jahr klappt, verwahrlosen die Seiten dann doch. Mein vorgeschlagenes Konzept ist zumindest meiner Meinung nach die beste Möglichkeit, um hier im Wiki irgendwie zu einzelnen Seiten zu kommen.
@Nethonos: Violine1101 hat schon recht, so ganz wie bei den Fortschritten klappt es nicht. Mein Anreiz war auch, dass bei den bisherigen Seiten wirklich gar nichts geändert werden muss, um den Aufwand bei der Umstellung minimal zu halten. – Fuzs 18:02, 6. Feb. 2018 (UTC)
@Fuzs: abgesehen von dem Thema, bitte wahre deinen Ton gegenüber anderen. Jeder hat eine Meinung und das sollte man respektieren. Wenn das jetzt wie ein Oberlehrer wirkt dann entschuldige ich mich dafür. -- Nethonos 18:06, 6. Feb. 2018 (UTC)
Es tut mir ausgesprochen leid. – Fuzs 18:38, 6. Feb. 2018 (UTC)
Kein Ding, deine Idee mit den Fortschritten war ja äußerst naheliegend.
Ich sehe es eher so: Entweder ich baue ein paar Monate an einem neuen Modul und wir binden dieses Modul auf allen Snapshot-Seiten ein, oder wir übernehmen das Modul aus dem englischen Wiki (mit ein paar kleinen Anpassungen) und müssen nur noch die einzelnen Changelogs auf einzelne Seiten copy-pasten. Da geht die zweite Variante meines Erachtens nach schneller. Ich würde sagen, egal wie wir's machen, der Wartungsaufwand im Nachhinein bleibt da in etwa gleich groß, es ändert sich ja nur, wo man die Versionen bearbeitet. Dass man auch mehrere Versionen auf einmal bearbeiten kann (so wie jetzt), daran arbeite ich gerade. | violine1101 (Diskussion) 18:54, 6. Feb. 2018 (UTC)

Ich finde das es gravierende Unterschiede zwischen den beiden Vorgehensweisen der Snapshot-Verteilung gibt bezüglich des Arbeitsaufwandes:
=>Vorgehen: A nach dem Vorbild aus dem englischen Wiki

  • Vorlagen oder Module für Vereinigung von Snapshot-Seiten erstellen (geringer Aufwand für Programmierer)
  • Helferlein für gleichzeitiges Bearbeiten erstellen (großer Aufwand für Programmierer)
  • Zeitintensive Arbeiten bzgl. der Einzelseiten die mehrere Autoren zwangsläufig beschäftigen (großer Aufwand für Autoren)

=>Vorgehen: B nach dem Vorbild der Fortschrittsvorlage

  • Vorlagen oder Module für Aufspaltung einer Sammelseite erstellen (großer Aufwand für Programmierer)
  • Einmalige Änderung der Snapshot-Weiterleitungen von Weiterleitung zu {{Versionsseite|17w47a}} (Kaum Aufwand für Autoren, da sogar ein Bot das bearbeiten könnte)

Meiner Ansicht nach ist die Vorgehensweise nach dem englischen Wiki (A) viel aufwändiger und zeitintensiver als die Vorgehensweise der Fortschrittsvorlage (B), denn der Unterschied liegt eventuell im Detail: Während bei Vorgehen A die meiste Arbeit auf den Schultern der Autoren ausgetragen wird, würde man bei der Vorgehensweise von B fast sämtliche Arbeit dem Programmierer überlassen. Das heißt, die normalen Autoren bekommen von dem ganzen nichts mit und das Wiki braucht nicht mal eine monatelange Umstellungsphase. Außerdem kann ich mir nicht vorstellen, das die Vorlage für das Vorgehen von B so exorbitant schwerer sein soll. Mit folgenden Beispiel: Man könnte doch HTML-Tags wie <Snapshot-18w05a> vor und danach einbauen, ich habs testweise in der Vorschau probiert, es macht keine Probleme. Das sehe dann vielleicht so aus: <Snapshot-18w05a>|- |{{spielbar|18w05a|... </Snapshot-18w05a>. Das ließe sich extrem leicht überall einbauen, weil ja die Anzahl der Sammelseiten sehr überschaubar ist. Ich würde euch bitten das mal zu versuchen, denn ich sehe keinen wirklichen Vorteil in dem Vorgehen A, außer das es für den Programmierer einfacher ist. -- Nethonos 07:33, 7. Feb. 2018 (UTC)

Du übersiehst bei Vorgehen (B), dass die Sammelseiten wahrscheinlich ebenfalls komplett überarbeitet werden müssten. Es reicht nicht, einzelne Abschnitte in HTML-Tags zu setzen, die funktionieren nämlich dank MediaWiki nicht, wenn sie nicht HTML-konform sind. Schau mal hier: <test>Hallo</test> oder <Snapshot-18w05a>Test</Snapshot-18w05a>, keine Ahnung was da bei dir in der Vorschau schief gelaufen ist. Und außerdem würde die Tabelle dadurch zerstört werden. Daher müsste die Syntax der Versions-Sammelseiten sowieso wahrscheinlich grundlegend geändert werden.
Außerdem kommt noch bei (B) hinzu, dass man den Quelltext einer Versionsseite nur auf der Sammelseite bearbeiten kann. Und man müsste diese Einzelseiten sowieso noch alle einmal bearbeiten, es muss ja nicht nur die Vorlage eingebunden werden, sondern auch bspw. Interwikilinks oder die Infobox hinzugefügt werden. Es kommt hinzu: Dann müssten die Einzelseiten und die Sammelseiten gewartet werden, und nicht nur die Einzelseiten. Dann können wir es auch gleich bei den Weiterleitungen belassen.
Zu (A) noch: Ein großer Vorteil hier ist auch, dass die Einzelseiten nicht so lange laden würden wie bei (B). Bei (B) müsste erst einmal die ganze Sammelseite geladen werden und dann der passende Abschnitt gefunden werden. Bei (A) geht das Laden (und auch das Speichern) von den Einzelseiten daher erheblich schneller. Außerdem ist das Erstellen des Helferleins für (A) jetzt nicht ansatzweise so kompliziert wie das Modul bzw. die Vorlage für (B), zumindest meiner Ansicht nach. | violine1101 (Diskussion) 19:35, 7. Feb. 2018 (UTC)
Die sogenannten "HTML-Tags" waren nur Beispiele von mir und sind komplett funktionslos weshalb MediaWiki sie nicht irgendwie zerschießt wie man das manchmal bei anderen sieht, daher meine Vermutung das man vielleicht mit sowas arbeiten könnte, aber wie gesagt ist nur ein Beispiel gewesen. Zum Thema Sammelseiten überarbeiten, ja die Sammelseiten müssten bestimmt angepasst werden damit eine Vorlage diese korrekt auslesen kann, aber das ist verkraftbar in Bezug auf ihre Anzahl und ihre Größe (ab 1.10 nur noch kleine Versionen). Das Layout bzw. die Tabelle kann ja nach besten Wissen geändert werden, das könnte man separat von dieser Diskussion nochmals besprechen. Wenn man nach dem Vorgehen B vorgeht, könnte man doch auch genauso gut die Interwikis und Infobox in der Sammelseite eintragen, je nach Layout, wie eben grad genannt. Dann hätte man nur eine Quelle wo man alles ändern müsste. Das Laden einer Seite ist zwar immer vorhanden, aber es ist verkraftbar. -- Nethonos 15:57, 9. Feb. 2018 (UTC)

Tut mir leid, falls das jetzt ungelegen kommt, aber ich möchte das Thema wieder augreifen, da (so wie ich das verstanden habe) noch keine Lösung gefunden wurde, mit der alle einig sind. Eventuell könnten wir eine Umfrage machen, bei der abgestimmt wird, wie wir das mit den Versionen machen könnten? ---- BohneFJS(Diskussion) 14:07, 25. Feb. 2018 (UTC)

Ja, vielleicht machen wir hier erstmal ein Meinungsbild, damit wir sehen können, wie wir weiter vorgehen.
Ich für meinen Teil sehe immer noch nicht, welchen Vorteil Vorgehen B gegenüber Vorgehen A haben soll. | violine1101 (Diskussion) 15:08, 25. Feb. 2018 (UTC)
Ich kann mit den Einzelseiten überhaupt nichts anfangen und brauche sie nicht. Dass das engl. Wiki eine Zusammenfassung hat, hatte ich erst aus dieser Diskussion erfahren. Aus der engl. Wikiseite ist das nicht ersichtlich, das sollte - wenn es passiert - hier besser gemacht werden. Man muss auf der Seite "18w08b" erstmal auf "1.13" klicken, was ich nie gemacht habe und dann auf "View all". Dann kommt die Zusammenfassung, aber die Fehlerbehebungen sind nicht eingeklappt, was ich schlecht finde. Außerdem gibt es kein Datum, keine Downloadlinks, kein Bloglink, keine Versions-ID, kein Bannerbild. Das alles finde ich schlecht. Fazit: Ich brauche es nicht, aber wenn es unbedingt sein soll, dann so ähnlich wie es jetzt ist und nicht wie im engl. Wiki. -- Sumpfhütte 18:59, 25. Feb. 2018 (UTC)
Diese Einzelseiten haben auch den Nachteil, das sie sehr zahlreich sein würden, nach meinen Berechnungen wären das mehr als 800 neue Seiten (Java und Bedrock) für ein Wiki das aktuell 1.162 Artikel besitzt (fast eine Verdopplung). Das bedeutet im Klartext, eine immer schwindendere Autorenschaft muss immer noch mehr Artikel pflegen und wenn man sich dann auch noch sowas antut, ich glaube das wäre der Todesstoß. Das bedeutet aber auch, möchte man eine grundlegende Änderung durchführen kann man jedesmal sich paar freie Wochen suchen gehen, falls kein Bot zur Hand ist. Andererseits hätten wir auch immer eine gefüllte letzte Änderungsseite. Zudem gibt es zahlreiche "Bugfix"-Snapshots und Versionen, welche kaum "Inhalt" bieten, was auch nicht wirklich wünschenswert wäre. Der Vorschlag B hat den reizenden Vorteil, das er das Wiki als solches nicht großartig ändert und mit wenigen Autoren bewältigt werden kann, denn der Zustand bleibt fast gleich. Aber ich finde auch den jetzigen Zustand, wie er jetzt ist, recht gut gewappnet für die Zukunft. -- Nethonos 20:23, 25. Feb. 2018 (UTC)
Ich habe es jetzt nicht nachgerechnet, aber dass sehr viele Seiten betroffen sind/erstellt werden müssen ist auf jeden Fall so. Daher denke ich, dass für eine so massive Änderung eine einfache Mehrheit nicht ausreichen sollte. – Fuzs 00:23, 26. Feb. 2018 (UTC)
Mir gefällt grundsätzlich die aktuelle Lösung am besten. Sollte es aber umgestellt werden, könnte ich mich auch damit anfreunden. Ich wäre aber eher für Lösung (A) (wie im englischen Wiki eine Sammelseite, die aus den Einzelseiten besteht), auch wenn dies mehr Arbeit bei der Umstellung wäre. Den Einwand von @Sumpfhuette: sehe ich nicht so, da wir schließlich die Einbindungen an unsere Bedürfnisse anpassen können. Lösung (B) (eine Sammelseite aus der sich die Einzelseiten, ähnlich zu Vorlage:Fortschritt, herauslesen) finde ich da nicht ganz so schön. Der größte Punkt dafür war, alle Seiten gleichzeitig bearbeiten zu können und @Violine1101: ist ja derzeit dabei ein Helferlein zu erstellen, um mehrere Seiten gleichzeitig bearbeiten zu können.   HorseHead.png MarkusRost (Diskussion) 11:24, 26. Feb. 2018 (UTC)
Nein, es ist eher einer von mehreren gleichwertigen Punkten, wie man oben nachlesen kann. Ein Helferlein finde ich grundsätzlich auch gut, auch wenn es nur im MC-Wiki standardmäßig dann zu nutzen sein wird, aber auch damit hätten wir die anderen Sachen nicht optimal für die Zukunft gelöst. Ein fast doppelt so großes zukünftiges Wiki sollte jedem zu denken geben, der das Wiki auch in Zukunft pflegen möchte. In vielen anderen sprachigen MC-Wikis sind sie damit auch schon überfordert, das zu stemmen. Und es wäre echt blöd wenn wir das gleiche Problem hätten, wie wir es teilweise schon bei den Bedrock-Versionen derzeit erleben. -- Nethonos 15:42, 26. Feb. 2018 (UTC)
Stimmt. Nicht alles, was machbar ist, ist auch wartbar. Wer passt in fernerer Zukunft das Helferlein an, wenn es angepasst werden muss? Bei den Wiki-Vorlagen scheint mir das für einen Neuling einfacher zu sein als bei Lua oder JavaScript. Wir sollten das Wiki kompakt und einfach-wartbar halten. Es wird ja durch neue Update-Inhalte schon automatisch größer. -- Sumpfhütte 17:22, 26. Feb. 2018 (UTC)

Umfrage[Bearbeiten]

Sollten die Versionen auf Einzelseiten ausgelagert werden?

Nein
, alles soll so bleiben wie bisher

Ja
, wie im englischen Wiki (A)

Ja
, aber nicht wie im englischen Wiki (B)

So geht's doch auch: Mit #dpl (in Vorlage:Fortschritte gefunden). Ich habe dpl mal auf meiner Testseite eingebaut. Wenn man nun die Snapshot-Weiterleitung "18w08a" testweise (ohne zu speichern) durch die Vorlage {{Benutzer:Sumpfhuette/test|18w08a}} ersetzt, sieht die Vorschau doch schon wie gewünscht aus. Das ist ohne großen Programmieraufwand ausbaufähig. Vorteil: Wiki-Syntax (kein Lua oder JavaScript) und wir müssten nur auf allen Entwicklungsversionsseiten die Sections einsetzen, wie ich es testweise für 18w08a gemacht habe.

Wenn die Vorlage fertig ist (u.a. PAGENAME einsetzen), könnte ein Bot alle Snapshot-Weiterleitungen durch die Vorlage ersetzen. Ruft man dann "18w08a" auf, erzeugt die Vorlage den Abschnitt 18w08a in einer Tabelle plus Einleitung und Navbox. Das würden wir erstmal nur für die Java-Snapshots ab Vollversion 1.0 machen, denn es das ist der Fokus des Wikis und erst ab 1.6 (?) wurde die Versionshistorie so richtig lang (= "unübersichtlich"). -- Sumpfhütte 18:48, 26. Feb. 2018 (UTC)

Das ist tatsächlich deutlich einfacher, als ich erwartet hatte. Die Lösung ist damit meiner Meinung nach wohl auch die beste und einfachste. Man müsste sich dann nur noch um Kleinigkeiten kümmern, wie eine Navbox pro Vollversion um von einem Snapshot einfach zum Nächsten zu kommen. Ansonsten wäre {{VersionsgeschichteNav}} auch ganz praktisch für die kleinen Seiten, dort sollten aber weiterhin nur die bisherigen Sammelseiten enthalten sein. Außerdem könnte man eventuell auch die Entwicklungsversionen als Unterseiten erstellen: Versionen/Vollversion 1.13/Entwicklung/18w08a Das wird dann zwar doch ein ziemlich großer Titel, aber man würde durch den Link am Beginn der Seite auch einfach zu der Sammelseite kommen.   HorseHead.png MarkusRost (Diskussion) 19:19, 26. Feb. 2018 (UTC)
Prima, dann bedeutet das doch viel weniger Aufwand. Wenn die Programmierung der Vorlage fertig ist, kann ich mich gerne daran setzen, das sollte denke ich leicht zu machen sein. Die Idee von @MarkusRost: mit den Unterseiten finde richtig gut, weil wir dann immer genau an Hand des Seiten-Titels erkennen können welche Edition gemeint ist und ein Bot eventuell alle Seiten anlegen könnte. Natürlich kann man sagen, das man "18w08a" und "1.2.10 build" leicht unterscheiden kann, aber es hätte dann eine Struktur, die sich auch nicht ändern müsste, falls Mojang mal auf neue Gedanken kommt und die Snapshots anders benennt. -- Nethonos 19:30, 26. Feb. 2018 (UTC)

"Ich kann mit den Einzelseiten überhaupt nichts anfangen und brauche sie nicht."

=> Ich für meinen Teil kann mit den Sammelseiten überhaupt nichts anfangen und brauche sie nicht.

"Dass das engl. Wiki eine Zusammenfassung hat, hatte ich erst aus dieser Diskussion erfahren. Aus der engl. Wikiseite ist das nicht ersichtlich, das sollte - wenn es passiert - hier besser gemacht werden. Man muss auf der Seite "18w08b" erstmal auf "1.13" klicken, was ich nie gemacht habe und dann auf "View all". Dann kommt die Zusammenfassung, aber die Fehlerbehebungen sind nicht eingeklappt, was ich schlecht finde. Außerdem gibt es kein Datum, keine Downloadlinks, kein Bloglink, keine Versions-ID, kein Bannerbild. Das alles finde ich schlecht."

=> Kann man ja alles zur Sammelseite hinzufügen, wo ist das Problem? Wie ich gesagt habe, kann man ja die Vorlage aus dem englischen Wiki abändern.

"Diese Einzelseiten haben auch den Nachteil, das sie sehr zahlreich sein würden, nach meinen Berechnungen wären das mehr als 800 neue Seiten (Java und Bedrock) für ein Wiki das aktuell 1.162 Artikel besitzt (fast eine Verdopplung). Das bedeutet im Klartext, eine immer schwindendere Autorenschaft muss immer noch mehr Artikel pflegen und wenn man sich dann auch noch sowas antut, ich glaube das wäre der Todesstoß."

"Ein fast doppelt so großes zukünftiges Wiki sollte jedem zu denken geben, der das Wiki auch in Zukunft pflegen möchte. In vielen anderen sprachigen MC-Wikis sind sie damit auch schon überfordert, das zu stemmen."

=> Der Inhalt wird ja nicht mehr. Es ist dieselbe Menge an Inhalt, die gepflegt werden muss. Außerdem benutzt jedes, ich wiederhole, jedes Minecraft Wiki außer dem deutschen inzwischen das Versionssystem des englischen Wikis. Ich wage zu behaupten, dass das deutsche Wiki nicht unbedingt das inaktivste unter den Minecraft Wikis ist.

"Andererseits hätten wir auch immer eine gefüllte letzte Änderungsseite."

=> Warum? Es kommt selten vor, dass man jede einzelne Entwicklungsversion gleichzeitig überarbeitet. Schon jetzt werden die Entwicklungsversionsseiten ja normalerweise als einzelne Artikel (in diesem Fall Abschnitte) behandelt.

"Vorschlag B hat den reizenden Vorteil, das er das Wiki als solches nicht großartig ändert und mit wenigen Autoren bewältigt werden kann, denn der Zustand bleibt fast gleich."

=> Vorschlag A kann ebenfalls mit wenigen Autoren bewältigt werden, der Zustand bleibt fast gleich.

"Aber ich finde auch den jetzigen Zustand, wie er jetzt ist, recht gut gewappnet für die Zukunft."

"Wer passt in fernerer Zukunft das Helferlein an, wenn es angepasst werden muss? Bei den Wiki-Vorlagen scheint mir das für einen Neuling einfacher zu sein als bei Lua oder JavaScript."

=> Vorteil von Vorschlag A: Wenn was nicht funktioniert, einfach im englischen Wiki nachfragen. Das Helferlein ist ja nur ein Zusatz.

Hier noch ein Punkt:

Das Tabellendesign ist hässlich. Es ermutigt den Leser nicht, länger auf der Website zu bleiben. Es ist unfreundlich zum Bearbeiten. Ein Neuling kann einfacher eine Einzelseite bearbeiten, mit dem Bonus, dass er nicht zufällig das Tabellenlayout zerstört.

Wenn wir wollen, dass Leser das deutsche Wiki nutzen, um einen Überblick über Änderungen in den Snapshots zu bekommen, müssen wir das englische Layout nutzen. Die Tabelle ist einfach nicht ansprechend.

Fazit: Bevor ihr Vorschlag (B) einbaut, lasst bitte alles so bleiben, wie es ist. Danke. | violine1101 (Diskussion) 21:09, 26. Feb. 2018 (UTC)

Ich stimme dir in fast allen Punkten zu: Es gibt Fans von Sammelseiten und Fans von Einzelseiten, also sollten wir beiden etwas bieten; Das Layout nach unseren Wünschen zu gestalten, ist prima; Die Inhaltsmenge wird tatsächlich nicht mehr ansteigen als beim Anlegen von Weiterleitungen.
Nachdem ich jetzt eine so einfache Lösung gefunden habe ist mein größtes Problem (schon immer gewesen) die barocke Programmierung des engl. Wiki. Ich bin ein Fan von Einfachheit und Übersichtlichkeit. Warum ein Helferlein programmieren, wenn es auch ohne geht? Warum ein Lua-Skript, wenn es auch ohne geht? Warum 20 Parameter einbauen, wenn wir nur 2 brauchen? Das muss alles gepflegt bzw. an zukünftige Anforderungen angepasst werden. Wenn der Tag kommt, an dem es im dt. Wiki keinen Lua-/JavaScript-/CSS-Auskenner mehr gibt, wird an diesen Dingen nichts mehr gemacht werden und das Wiki verkommt. Ich weiß das, weil ich es im Laufe der Jahre selbst erlebt und viel Zeit in den Wiederaufbau gesteckt habe (2013).
Daher mein Vorschlag: Weg mit der Tabelle auf der Sammelseite, z.B. so => Benutzer:Sumpfhuette/test. Dann wäre das Erzeugen einer Einzelseite ein Einzeiler! Nämlich dieser (Wieder hier testweise einsetzen):
 {{#dpl: |title=Benutzer:Sumpfhuette/test |include=#18w08a }}
Aus diesem Einzeiler eine Vorlage zu bauen, die einen Header und eine Navbox hinzufügt, wäre sehr einfach. -- Sumpfhütte 08:06, 27. Feb. 2018 (UTC)
MarkusRost experimentierte mit einer Navigation und schrieb "die angrenzenden Versionen wäre gut darzustellen, nur wie? :/" - Ich würde die Navigation einfacher und übersichtlicher machen: Nämlich wie alle unsere Navigationen als Box, die sämtliche Snapshots einer Version im Überblick enthält plus die Sammelseite plus die Vollversionsseite. Die Pfeile haben den Nachteil, dass es keinen Überblick gibt, wo man in der Snopshot-Historie steht und wie viele Snapshots es eigentlich in der Version gibt. Das könnte so aussehen (Layout kann beliebig geändert werden):
Vollversion 1.13 Alle Entwicklungsversionen
18w08b ▪︎ 18w08a ▪︎ 18w07c ▪︎ 18w07b ▪︎ 18w07a ▪︎ 18w06a ▪︎ 18w05a ▪︎ 18w03b ▪︎ 18w03a ▪︎ 18w02a ▪︎ 18w01a ▪︎ 17w50a ▪︎ 17w49b ▪︎ 17w49a ▪︎ 17w48a ▪︎ 17w47b ▪︎ 17w47a ▪︎ 17w46a ▪︎ 17w45b ▪︎ 17w45a ▪︎ 17w43b ▪︎ 17w43a
Den Vorschlag mit den Snapshot-Einzelseiten als Unterseite finde ich prima. Aus dem Seitentitel (z.B. "Versionen/Vollversion 1.13/Entwicklung/18w08a") könnte die Vereinzelungs-Vorlage dann bequem die Vollversion ermitteln (z.B. 1.13). Nun würden wir bei der Vorlage für jede Vollversion eine eigene Unterseite anlegen, die alle Links enthält (z.B. "Vorlage:Entwicklungsversionenvereinzelung/1.13"). Die Vorlage würde dann ihre leere Navigationsbox mit der passenden Unterseite füllen. -- Sumpfhütte 10:20, 27. Feb. 2018 (UTC)
Eine Navbox mit allen Entwicklungsversionen einer Vollversion wäre sowieso nötig. Diese würde ich aufgrund ihrer Größe nach unten über {{Navbox-Entwicklung}} packen, sonst hat man oben zu viele Hinweise bevor der Inhalt beginnt. Allerdings finde ich auch, das eine einfache Navigation zu den benachbarten Versionen weiter oben durchaus hilfreich sein kann (wie im englischen Wiki). Bei längerer Überlegung erscheint mir dies aber doch zu kompliziert im Vergleich zum Nutzen. Anders als im englischen Wiki sind unsere Versionen auf Unterseiten. Daher gibt es dort direkt eine Navigation zu den höheren Seiten. Dort ist dann sowohl die Vollversion, als auch die Sammelseite verlinkt. Wer noch mehr Navigation will muss dann halt doch runterscrollen.   HorseHead.png MarkusRost (Diskussion) 10:32, 27. Feb. 2018 (UTC) Buch und Feder.png
Also ich will erstmal anmerken, dass ich das neue Design der Sammelseite für sehr gelungen halte. Es verschafft dem Inhalt viel mehr, und auch sehr benötigten Platz, also wie im engl. Wiki, verzichtet aber nicht auf wichtige Zusatzelemente, wie das Bild, Download, ... was im engl. Wiki leider der Fall ist. Aber natürlich geht es hier in erster Linie nicht darum, daher zu den Einzelseiten: Auch wenn es die Sache ein wenig komplizierter macht, auf den Einzelseiten fände ich eine Infobox genau wie im engl. Wiki ideal. Mehr Aufwand auf jeder Einzelseite beschert das nicht, es muss nur eine Vorlage her, die den oberen Seitenteil aus der Sammelseite jeweils entsprechend zerpflückt.
Was die Navigation angeht, so würde ich dem Leser beide Optionen geben, also sowohl eine sehr simple, wo es möglich ist, zu angrenzenden Versionen zu springen, aber auch eine Auswahl über alle verwandten Entwicklungsversionen. Beides befindet sich in der Fusszeile vom Steckbrief, standardmäßig wird nur die einfache Variante angezeigt, durch ausklappen verschwindet diese und man sieht alle verwandten Versionen. So hat man alles direkt oben am Seitenanfang, sieht aber normal nur eine sehr überschaubare Zahl an Navigationselementen. – Fuzs 10:48, 27. Feb. 2018 (UTC)
Wenn wir alle Sammelseiten der Java-Vollversion ändern (Tabelle raus), sind das nur 13 Seiten, die geändert werden müssen. Bei der Gelegenheit kann man dort die "Vorlage:Spielbar" durch eine Steckbrief-Vorlage nach dem Vorbild aus dem engl. Wiki (aber etwas verändert) ersetzen: Bild, Bloglink, Datum, Version-ID, Downloads, Navigation. Die Einzelseiten würden dann wie im engl. Wiki aussehen. Aber da die Steckbriefe alle in der Sammelseite enhalten sind, hat die Vereinzelung extrem leichtes Spiel: der dpl-Befehl extrahiert einfach den kompletten Snapshot-Absatz aus der Sammelseite. Vorteil: Keine komplexe Allgemeinlösung für den Steckbrief in der Vereinzelungsvorlage. -- Sumpfhütte 11:16, 27. Feb. 2018 (UTC)
Wenn die Vorlage:Spielbar ersetzt wird, sind dann in der neuen Vorlage auch alle Funktionen der Vorlage:Spielbar enthalten? Wie beispielsweise ob man den Snapshot im Launcher noch auswählen kann? Denn nach dem eine neue Vollversion erschienen ist (mit Snapshots), ändert sich dieser Zustand in allen älteren Snapshots und man muss dort ja den Unterschied irgendwie einsehen können. Zudem wollte ich noch fragen, wie das mit dem Erscheinungsbild der neuen Vorlage auf den 13 Sammelseiten sein wird, dort wird doch bestimmt nicht das gleiche Aussehen benötigt, vielleicht könnte man dort die Vorlage:Spielbar noch verwenden, in dem man die Parameter der neuen Vorlage dort einschleust? -- Nethonos 12:02, 27. Feb. 2018 (UTC)
{{Spielbar}} in den Sammelseiten zu belassen halte ich auch für besser, Steckbriefe sind dafür einfach zu groß. Die Vorlage bietet ein so schön minimalistisches Design, das auch bei ganz kleinen Snapshots keine Probleme machen wird (alles aufschiebt usw.). Angepasst werden muss {{Spielbar}} meiner Ansicht nach aber nicht, damit ein Steckbrief die Parameter auslesen kann. Mit ein paar Tricks könnte das klappen, solange wir nicht an irgendwelche Beschränkungen des Wikis stoßen. Ich habe auf jeden Fall schon eine Idee, die ich später mal noch versuchen werde. – Fuzs 12:12, 27. Feb. 2018 (UTC)

Eventuell mag ja jemand eine passende Steckbriefvorlage auf seiner Benutzerseite erstellen und dann auch schon testweise auf Benutzer:Sumpfhuette/test einbinden. Beim Erstellen des Steckbriefes sollte aber beachtet werden, dass er nicht zu groß wird. Auf der eigenen Seite stört ein großer Steckbrief nicht, doch bei der kurzen Abschnitten auf der Sammelseite (wie z.B. Benutzer:Sumpfhuette/test#18w07c) würde ein ewig langer Steckbrief nur stören.

Liste aller aktuellen Testseiten

  HorseHead.png MarkusRost (Diskussion) 12:13, 27. Feb. 2018 (UTC)

Um das Steckbrief-Thema einfach zu halten würde ich vorschlagen, so wie ich es aus der Programmierung kenne, eine "Übervorlage" zu erstellen die alle Parameter die die Vorlage:Spielbar und die neue Vorlage benötigt einliest. Wenn man sich dann auf der Sammelseite befindet, erkennt das diese Vorlage und holt "Spielbar" hervor, wenn es man sich auf der Einzelseite befindet holt sie die neue Vorlage hervor. Was meint ihr dazu? Man hätte dabei den Vorteil, das man Fehler nur an einer stelle suchen und ausmerzen müsste. -- Nethonos 12:48, 27. Feb. 2018 (UTC)
Ich habe auch von violine1101 gehört, dass das bisher Diskutierte in seinem Sinne wäre und daher mit der Umsetzung begonnen. Layout-Anpassungen sind auch später noch möglich. Zum Steckbrief: Fuzs hat vier Konzepte vorgestellt. Nr. 3 zeigt alle Snapshots einer Vollversion im Überblick, weitere Snapshots brauchen wir hier nicht, das wird schnell sehr unübersichtlich. Nr. 2 ist ist zwar ein Hingucker, aber gerade die Ersetzung irritiert das Auge. Nr. 4 ist zu kompliziert. -- Sumpfhütte 19:01, 1. Mär. 2018 (UTC)
Mir persönlich gefällt die Auflistung aller Entwicklungsversionen direkt im Steckbrief nicht. Der Steckbrief soll für alle Versionen von 1.0 bis 1.13 verwendet werden. Für die Übersicht aller Entwicklungsversionen einer Vollversion fände ich eine einfach Navbox am Ende der Seite besser. Schließlich muss man jede neue Entwicklungsversion eintragen, dies ist in einer Navbox, die nur zwischen den Versionen unterscheidet, besser, als in einer eh schon unübersichtlichen Steckbriefvorlage, welche auch noch erkennen muss, ob sie sich auf einer Unterseite befindet. Ich hatte hier bereits Navboxen für 1.13 und 1.12 vorbereitet.   HorseHead.png MarkusRost (Diskussion) 19:07, 1. Mär. 2018 (UTC)
Bearbeitungskonflikt: Ich kann auch mit der Nr.3 am meisten was anfangen, denn die Nr.2 und Nr.4 besitzen beide unkonventionelle Aufklappmenüs, die doch nirgends sonst im Wiki anzutreffen sind und somit etwas verwirrend. Die Nr.1 besitzt keine Auflistung aller Snapshots, weswegen ich diese auch nicht wählen würde. Aber sonst gute Arbeit @Fuzs:. -- Nethonos 19:11, 1. Mär. 2018 (UTC)
Die Nr. 1 besitzt durchaus eine Auflistung und zwar als Link "Zur Versionsübersicht" auf die Navbox am Seitenende. Nur fand ich diese Navbox zu umfangreich, weil sie nicht nur 1.13, sondern auch 1.12 bzw. wahrscheinlich alle Vollversionen anzeigt. Für die Navigation innerhalb der 1.13-Snapshots reicht aber eine 1.13-Navbox, daher hatte ich Nr. 3 gewählt. Momentan versuche ich, eine Navbox mit dem #dpl-Befehl automatisch zu generieren. Wenn das klappt, wäre Nr. 1 (separate Navbox) die beste Lösung. -- Sumpfhütte 07:38, 2. Mär. 2018 (UTC)

Meine Beispiel-Navbox war eine Vorlage, die aber immer nur die Versionen für eine Vollversion anzeigt: {{Benutzer:MarkusRost/Test/Modul|Vollversion 1.13}} Ich war auch schon am Überlegen die Liste per #dpl aus z.B. einer Kategorie aufzufüllen, allerdings verursacht die Sortierung Probleme. sie ist alphabetisch und funktioniert nicht, da die Pre-Versionen dann vor den Entwicklungsversionen aufgelistet werden. Man muss die Liste also vermutlich per Hand füllen. Allerdings habe ich da gerade noch eine Idee, die ich vorher testen müsste.   HorseHead.png MarkusRost (Diskussion) 07:53, 2. Mär. 2018 (UTC)

@Sumpfhuette: Die neuen Namen verursachen nur zusätzliche Probleme und sind für den Leser verwirrend, Ich habe eine Idee, wie man das Problem mittels eines Parameters in {{NeuerInhalt}} lösen könnte.   HorseHead.png MarkusRost (Diskussion) 08:39, 2. Mär. 2018 (UTC)
Ich komme langsam zu dem Schluss, dass besser alles so geblieben wäre wie es vorher war. @Sumpfhuette: ich hatte gesagt, dass ich mir die Diskussion zu diesem Zeitpunkt noch nicht durchgelesen hatte, aber mit dem tabellenlosen Layout einverstanden bin.
Ich finde, ihr habt alles viel komplizierter eingebaut als notwendig. Hätte man einfach die Vorlagen aus dem englischen Wiki genommen, müsste man jetzt nicht mit neuen Vorlagen rumbasteln. Ich denke, ich halte mich jetzt aber mal aus der Diskussion entgültig raus. Ich werde in Zukunft für die Versionsgeschichte einfach das englische Wiki benutzen. | violine1101 (Diskussion) 09:27, 2. Mär. 2018 (UTC)
Wir alle haben gemeinsam die Qualität des dt. Wikis stetig verbessert. Auch wenn mal was dabei ist, was einem nicht so gut gefällt, klappt die Qualitätssteigerung doch ziemlich gut. Ich schaue ja auch immer wieder mal ins engl. Wiki :-) Durch die Diskussion haben wir eine simple Lösung für eine Vereinzelung unserer bereits existierenden Sammelseite gefunden, während im engl. Wiki die Sammelseite aus den Einzelseiten erzeugt wird. Sobald ich mit dem Anpassen der neuen Vorlagen fertig bin, sage ich Bescheid. -- Sumpfhütte 10:30, 2. Mär. 2018 (UTC)
@Sumpfhütte: Werden die Seiten wie Versionen/Vollversion 1.13/Entwicklung/18w08a jetzt doch nicht verwendet? Es war doch prima so... -- Nethonos 12:01, 2. Mär. 2018 (UTC)
Nein, die werden nicht benötigt. Da habe ich leider ziemlich viel überflüssigen Änderungsspam erzeugt, aber naja, "
drüber". Es gibt eine noch einfachere Lösung, ohne viele neue Seiten anzulegen. Und die Navigation zur Oberseite war zwar nett, aber mit einem Klick im Steckbrief oder der Navbox ist man genausogut da. -- Sumpfhütte 12:07, 2. Mär. 2018 (UTC)
Verstehe, dann bin ich mal auf die fertige Vorlage gespannt. Die ganzen Snapshot-Weiterleitungen würden dann sicherlich von einem Bot abgearbeitet werden, um nicht so viel "Spam" zu erzeugen. Die Einrichtung der Sammelseiten würde ich gerne übernehmen, wenn ihr damit einverstanden seid. -- Nethonos 12:15, 2. Mär. 2018 (UTC)
Die Links auf die Sammelseiten könnten grundsätzlich immer mit Abschnittsweiterleitungen ausgestattet sein, denn dann wird man immer zur entsprechenden Version hingeführt (1.12.2 => Abschnitt). Bei den anderen Sammelseiten würde ich das dann zusammen mit den "Vereinzelungen" auch mit einbauen, da dort noch nicht diese Ordnung herrscht. -- Nethonos 17:13, 2. Mär. 2018 (UTC)
Wo genau ist dir das aufgefallen? Ansonsten wäre ich jetzt fertig und du kannst übernehmen :-) -- Sumpfhütte 19:00, 2. Mär. 2018 (UTC)
@Sumpfhütte: unter Vorlage:Navbox-Entwicklungsversion, bei den Links zu den Sammelseiten. Dort würde ich vorschlagen diese immer auf (Beispiele) "#Vollversion 1.12" und "#Vollversion 1.12.2" leiten lassen, damit man beispielsweise bei einem Snapshot von 1.12.2 auch zu dem Abschnitt "Vollversion 1.12.2" gelangt. Falls das nicht notwendig ist, ist auch ok. Auf jeden Fall gute Arbeit! -- Nethonos 19:11, 2. Mär. 2018 (UTC)

Wirklich große Klasse, was ihr da in so kurzer Zeit ausgearbeitet habt! Das Konzept wurde einfach toll und vor allem sehr praktisch umgesetzt, besonders gefällt mir die Navbox der Entwicklungsversionen, das Design ist wirklich ansprechend und übersichtlich. Ich habe noch ein paar kleine designtechnische Änderungsvorschläge/ Fragen, die ich lieber kurz vorher absprechen möchte, bevor ich an eurer Arbeit herumfusche:

  1. Bloglink wieder in den Titel des Steckbriefes in Klammern (spart eine Zeile im Steckbrief, je kürzer, desto besser!)
  2. Warum "plainslinks" für die Downloads im Steckbrief? Es sollte eigentlich immer erkenntlich sein, wenn man über einen Link das Wiki verlässt, nur z. B. bei der Hauptseite ist es wirklich nachvollziehbar, da es zu sehr aus dem Gesamtbild heraussticht.
  3. Downloads im Steckbrief auf "Client", "(json)" und "Server" kürzen, dass es .jars sind ist klar, macht es einfach nochmal kürzer und schöner
  4. Vorherige/ nächste Navigation im Footer des Steckbriefes raus, der Link zur Navbox macht diese wirklich überflüssig, zumal ein Leser, der die Versionen nacheinander durchgehen will sowieso die Sammelseite nutzt (es geht dabei wieder vor allem ums Platz sparen!)
  5. In Navbox-Entwicklungsversion Begriff "Sammelseite" jeweils raus, der zweizeilige Text nimmt wieder zu viel Platz weg und nur "X.XX-Entwicklung" ist genauso verständlich.

Fuzs 22:05, 2. Mär. 2018 (UTC)

Ich finde den Bloglink eigentlich so auch ganz gut, würde ich so lassen. Die Download-Links sind deshalb komplett angegeben, da sie sich im laufe der Entwicklung geändert haben und die Vorlage für alle Versionen funktionieren soll, daher diese Art der Linkangabe. Die Vorher-Nachher-Angabe ist in der Tat etwas unnötig und vorallem am arbeitsintensivsten, wenn das entfallen würde, hätten wir einiges an Mehraufwand gespart. Die Angabe "Sammelseite" würde ich auch rausnehmen, da mit dem restlichen Titel auch bereits alles klar sein sollte. -- Nethonos 23:57, 2. Mär. 2018 (UTC)
Wenn der Bloglink wie alle anderen Eigenschaften eine Zeile hat, ist auch für Neulinge besser erkennbar, was gemeint ist. Wir haben auch in anderen Steckbriefen Links, aber nie ist der Titel verlinkt. (Überhaupt ist Titel- bzw. Überschriftverlinkung schlechter Stil (Wikipedia)). - "Vorherige/ nächste Navigation raus" => Ja! Bei neuen Snapshots daran zu denken, den Eintrag im vorigen anzupassen, ist sehr umständlich. - Mehrfach "Sammelseite" ist bei mehreren Versionen wirklich unschön. Stattdessen muss irgendwo (Steckbrief oder Navbox?) noch ein Link hin "Text ändern". Oder vllt. so? => @MarkusRost: Könnte der Bot alle Stellen, in denen die Vorlage "Entwicklungsversionsvereinzelung" eingesetzt ist einen Kommentar hinzufügen "Änderungen bitte auf der Sammelseite vornehmen". Ist "Sammelseite" überhaupt verständlich? -- Sumpfhütte 14:12, 3. Mär. 2018 (UTC)
Ob "Sammelseite" jetzt unschön oder gar unverständlich, darauf wollte gar nicht hinaus. Mir ging es nur darum, dass es zu viel Platz wegnimmt. Darum geht es mir generell, aber der Einwand zum Bloglink ist natürlich nachvollziehbar. – Fuzs 14:53, 3. Mär. 2018 (UTC)
@Sumpfhütte: gibt es nicht zufällig eine Möglichkeit, dass wenn man eine einzelne Snapshotseite bearbeiten will, man auf der Sammelseitenbearbeitung in der Snapshotversion landet (Abschnittsbearbeitung)? Beispielsweise kann im Technik Wiki auf den großen Sammelseiten (wie Technik/Befehle, Technik/Redstone ...) auch in den einzelnen Artikeln Bearbeitungen durchführen, in dem man rechts neben der ausklappbaren Technik auf "Bearbeiten" klickt, oder in dem man die Technik ausklappt und dort einzelne Abschnitte Bearbeiten kann. Vielleicht kann man das ja irgendwie übertragen? -- Nethonos 07:51, 4. Mär. 2018 (UTC)
@Sumpfhütte: Die Plainlinks können ruhig alle Raus, aber bei Vorlage:Spielbar´, dort wo der Blog-Link mit dem hochgestellten Blog erscheint, würde ich es wieder einbauen, denn der Pfeil erscheint ja nicht in der gleichen Ebene wie das hochgestellte "Blog". -- Nethonos 08:11, 4. Mär. 2018 (UTC)
Nachdem ich auch von MarkusRost und violine1101 gehört habe, dass die vorher/nachher-Navigation zwar nett, aber nicht unbedingt notwendig sei, habe ich sie entfernt, weil der Aufwand und die Fehleranfälligkeit bei der Eingabe zu groß sind. Plainlinks sind auch raus, auch beim Blog in der Vorlage:Spielbar, denn der Link ist ja nicht nur das hochgestellte "Blog" (das dient nur zur Erklärung), sondern der ganze Snapshot-Name. Die Sammelseite ist jetzt im Einzelseiten-Steckbrief verlinkt, passend zum Link "Einzelseite" im Sammelseiten-Steckbrief. Die Navbox wurde entsprechend entschlackt. - @Nethonos: Den Bearbeiten-Menüpunkt im Wiki würde ich nicht umbiegen wollen. Die sicherste Variante, dass jeder die Editiermöglichkeit findet, wäre ein Kommentar unter der Einbindung der Vorlage:Entwicklungsversionsvereinzelung: "Änderungen bitte auf der Sammelseite vornehmen", siehe 18w08a. -- Sumpfhütte 08:20, 4. Mär. 2018 (UTC)
@Sumpfhütte: ich meinte nicht "umbiegen" sondern auch "anbieten", sprich wenn du auf der Sanpshot-Seite 18w08a bist, könntest du oben wo Lesen, Bearbeiten, Versionen etc. steht normal bearbeiten (keine Änderung dort), wenn du aber beispielsweise auf den neuen Abschnitt (Test) in 18w08a auf "Bearbeiten" klickst, könnte man direkt auf die Sammelseite gelangen. Mein Test jedoch zeigt, das er den Abschnitt nicht findet...-- Nethonos 08:29, 4. Mär. 2018 (UTC)
In den 1.7 Snapshots gibt es jetzt mehrere "Reuploads" wie sollen wir die behandeln? Einfach entfernen oder separat auflisten? -- Nethonos 10:16, 10. Mär. 2018 (UTC)
Nach weiterem Nachforschen ist mir diese Bearbeitung hier aufgefallen, daher gehe ich stark von aus, das man Reuploads mit dem Original verbindet und als eine Version angibt, was ja auch einfacher ist. -- Nethonos 11:03, 10. Mär. 2018 (UTC)

Ich würde solche Korrekturen auch als nur eine Version auflisten (die Downloadlinks sind ja auch gleich). Das die Version einmal leicht geändert wurde, kann man ja bei den Änderungen mit erwähnen.   HorseHead.png MarkusRost (Diskussion) 11:27, 10. Mär. 2018 (UTC)

Ja, das ist nur eine Version. Die darf dann auch nur einen Absatz bekommen, damit sie korrekt vereinzelt wird. Die drei Spielbar-Boxen bei z.B. 13w36b sind sogar falsch, denn man kann nur den letzten Reupload spielen, die anderen sind nicht downloadbar. -- Sumpfhütte 13:45, 10. Mär. 2018 (UTC)
Es sind noch zwei Probleme hinzugekommen: Zum einen werden die ersten Snapshots einer Entwicklungsreihe mit der Navbox aus der Sammelseite ausgestattet (17w43a, 12w03a und etc.), wenn es keinen Abschnitt nach der letzten Entwicklungsversion gibt und zum anderen wird bei allen 1.1-Snapshots die 1.10-Entwicklung als Navbox angezeigt (11w47a und etc.). Wenn jemand weis was man da machen muss, wäre nett wenn er es korrigieren könnte. -- Nethonos 17:40, 20. Mär. 2018 (UTC)
Das Problem mit 1.1 und 1.10 sollte jetzt behoben sein. Was die Navbox bei den ersten Entwicklungsversionen betrifft bräuchten wir dort einen weiteren Abschnitt als Grenze. Bei einigen Sammelseiten gibt es Einzelnachweise, die diese Funktion gut erfüllen.   HorseHead.png MarkusRost (Diskussion) 18:38, 20. Mär. 2018 (UTC)
Das Problem mit der doppelten Navbox (und Interwikilinks) könnte man mit einer if-Zeile lösen, wie testweise in 1.13-Entwicklung eingebaut. Eine Vorlage wäre dafür eigentlich nicht nötig, weil zuviel formaler Overhead, oder? -- Sumpfhütte 11:30, 21. Mär. 2018 (UTC)
Ich wäre dafür, das man die Programmierung in dafür vorgesehenen Vorlagen belässt und den Inhalt auch nur in Artikeln einbaut. Sonst muss man als Bearbeiter auch sich damit zurecht kämpfen (oder der Bot). -- Nethonos 11:50, 21. Mär. 2018 (UTC)
Ich denke nicht das dafür eine Vorlage nötig ist. Eine Vorlage müsste genauso um die Navbox und Interwikilinks hergebaut werden und wäre daher genau "verwirrend" wie der direkte Code. Letzterer ist ja hierbei auch nicht sonderlich komplex.   HorseHead.png MarkusRost (Diskussion) 12:06, 21. Mär. 2018 (UTC)
Naja, wir binden die Vereinzelung nur dort ein, wo eine Entwicklungsversion benutzt wird, sprich wir werden stehts ganz unten eine Navbox-Entwicklung haben, daher würde ich vorschlagen, falls das geht zusätzlich zum Abschnitt-Detektor auch noch einen Navbox-Entwicklungs-Detektor einbauen, das sollte doch durch ein einfaches "Oder" möglich sein oder nicht? -- Nethonos 12:11, 21. Mär. 2018 (UTC)
Das geht nicht, die dpl-Funktion kann so etwas nicht. Sie extrahiert immer genau einen Abschnitt. Daher der Vorschlag von MarkusRost, über jede Navbox (und die Interwikilinks) einen neue Abschnitt zu setzen, z.B. "Navigation". Das wär zwar ungewöhnlich würde das Problem aber genauso lösen. Entweder überall ein Navigation-Abschnitt oder überall die if-Klammer, was fändest du besser? -- Sumpfhütte 18:55, 21. Mär. 2018 (UTC)
Das fände ich deutlich besser. Ich denke mal das ist nicht weiter Absprache-bedürftig, falls jemand dennoch anderer Meinung ist, werde ich es im schlimmsten Fall rückgängig machen. Ich setze mich mal ran. -- Nethonos 20:38, 21. Mär. 2018 (UTC)
Dadurch das nur in drei der insgesamt 14 Snapshot-Sammelseiten keine "Einzelnachweise" als Abschnitt unter den Snapshots existiert, musste minimal etwas bearbeitet werden. -- Nethonos 21:02, 21. Mär. 2018 (UTC)

Tooltip ausschalten[Bearbeiten]

Weiß jemand, wie ich in meiner common.css (oder common.js?) den Suchfeld-Tooltip "Minecraft Wiki durchsuchen [Alt+Umschalt+f]" ausschalten kann? Der Text liegt immer genau auf den ersten Suchvorschlägen und macht sie damit unlesbar. -- Sumpfhütte 11:07, 15. Feb. 2018 (UTC)

$("#searchInput").attr('title', "");
Diese Zeile zur common.js hinzugefügt müsste den Tooltip verbergen.   HorseHead.png MarkusRost (Diskussion) 11:20, 15. Feb. 2018 (UTC)
Ah, wie angenehm :-) Danke! -- Sumpfhütte 11:30, 15. Feb. 2018 (UTC)

YouTube Kanal[Bearbeiten]

Hat das Wiki einen YouTube Kanal oder so? Es geht nämlich darum, Beweise zu sichern, dass gewisse Versionen tatsächlich existiert haben, z. B. "0.26 SURVIVAL TEST", die einzige (!) jemals veröffentlichte Survival Test 0.26 Version. Neben dem Blog von Notch, der manchmal etwas ungenau/ verwirrend sein kann, wie man an den ganzen falschen Einträgen für z. B. Classic 0.24 hier im Wiki (auch im engl.) sieht, gibt es nur eine einzige Quelle dafür, dass diese Version tatsächlich existiert hat, nämlich dieses Video. Sonst keine Screenshots und nichts und es wurde wirklich lange gesucht. Wenn das Video einmal verschwindet, sieht es ziemlich schlecht aus und daher wäre es recht wichtig, es auf irgendeine Weise zu sichern. Das ist natürlich kein Einzelfall, es gibt noch einige weitere Videos, die ähnlich wichtig für bestimmte Versionen sind. Oder hat jemand eine andere Idee, wie man so ein Video sichern kann? Mit der Wayback Machine geht es übrigens nicht. – Fuzs 15:24, 24. Mär. 2018 (UTC)

Sehr interessante Idee! Das Wiki hat nur einen MediaFire-Account, aber noch keinen YT-Account. Darf man denn so einfach Videos kopieren? -- Sumpfhütte 18:18, 24. Mär. 2018 (UTC)
Hmm, da hatte ich noch nicht so ganz dran gedacht, da mir die Sicherung der Quellen erstmal im Vordergrund stand. Aber natürlich muss man damit vorsichtig sein. Speziell dieses YouTube Video nutzt die Standard-YouTube-Lizenz. Demnach ist zwar eine Weiterverarbeitung untersagt, eine unveränderte Verbreitung mit Nennung das Urhebers kann aber wohl nur direkt durch den Urheber selbst unterbunden werden. Immerhin würden die Videos auf der Plattform bleiben, was es etwas leichter macht.
Aber vielleicht können wir die entsprechenden Videos auch nur herunterladen und auf Mediafire / Mega speichern, so dass wir die Quellen auf jeden Fall haben, und falls es im Wiki an diesen Stellen zu Streitigkeiten kommt könnte man nachschauen. So würden sie zumindest nicht wieder von uns veröffentlicht werden. – Fuzs 21:15, 24. Mär. 2018 (UTC)
Der MediaFire-Account, den ich kenne, gehört zum Technik Wiki genauso wie der nicht genannte YouTube-Account, daher würde ich es vorziehen erstmal abzuklären, falls sie für dieses Vorhaben benutzt werden sollten, wo die Wirkungsbereiche dieser Accounts liegen (bisher nur Technik Wiki), falls sie in Betracht bezogen werden. Andernfalls könnte man auch schauen das man extra Accounts fürs MC Wiki erstellt. Oder hab ich was verpasst und es gibt bereits einen eigenen MediaFire-Account fürs MC Wiki? -- Nethonos 21:24, 24. Mär. 2018 (UTC)
Also wenn es einfach nur ums Abspeichern geht werde ich sowieso Mega verwenden, da MediaFire im Vergleich dazu keinen einzigen Vorteil bietet. Was wäre denn der YouTube Kanal des Technik Wikis und was für Inhalte befinden sich darauf? Die Kopien der Videoquellen um die es hier geht wären dann sowieso nicht gelistet, so dass sie nur über die Quellenangabe im Wiki aufzufinden wären. – Fuzs 22:23, 24. Mär. 2018 (UTC)
@Nethonos: Ach ja, stimmt. Als das Technik Wiki gegründet wurde, ist der MediaFire-Account vom Wiki zum Technik Wiki übergegangen. - Ansonsten: Das Wiki betreibt bisher noch keine professionelle Quellensicherung. Beispielsweise werden Links als Quelle angegeben, die auf Texte führen, die nach einiger Zeit verschwunden sein können (veralteter Link). Dann werden die Links im Artikel gelöscht und man muss die Info einfach so glauben. Nur in Einzelfällen habe ich mal einen Screenshot vom Text einer Quellen-Website gemacht und als Sicherung ins Wiki hochgeladen. Screenshots der relevanten Stellen aus Videos sind auf jeden Fall eine Möglichkeit, die Beweise auch öffentlich zu machen, z.B. was Survival Test 0.26 betrifft. -- Sumpfhütte 06:49, 25. Mär. 2018 (UTC)
Ja, der Account wurde übertragen. Die Sicherung der Quellen mittels Bilder ist auch eine gute Lösung, ansonsten könnte man aber auch mal schauen ob man wirklich einen Youtube-Account dafür braucht, schließlich ist Gamepedia Teil von Twitch, vielleicht könnte man auch mit seinem Wiki-Account solche Quellen speichern, ich mein man muss ja nicht immer zur Konkurrenz laufen :-) -- Nethonos 11:14, 25. Mär. 2018 (UTC)

Das ist zwar eine Idee, Twitch zu nutzen, aber wir wissen trotzdem noch nicht so recht, wie das mit der Lizenz aussieht. Daher ist es wohl wirklich am besten, die Videos erstmal zu sichern, aber nicht wieder zu veröffentlichen, und den Beleg für das Wiki mit einem Screenshot zu erbringen. Bei Unklarheiten kann ein Autor dann nachschauen. Mit dem Technik Wiki müssen wir die Sache auch nicht vermischen, ich will sowieso sehr gerne einen Mega Account nutzen, da es viel besser als MediaFire ist, vor allem was die Downloadgeschwindigkeit und Werbung angeht. – Fuzs 19:03, 25. Mär. 2018 (UTC)

Ich bin auch der Meinung das man die beiden Wikis Account-technisch nicht vermischen sollte. Dann kann auch alles weitere separat in dem MC Wiki geplant werden, wie und welche Accounts man anlegt, nutz und etc. -- Nethonos 19:24, 25. Mär. 2018 (UTC)
Die Mega-Cloud gehört dem umstrittenen Kim Dotcom und war in den Schlagzeilen wegen dem Vorgänger, der wegen Urheberrechtsverletzungen gesperrt worden war. In der Wikipedia steht: "Am 30. Juli 2015 distanzierte Kim Dotcom sich öffentlich von MEGA. Er sagte, das Unternehmen habe „unter einer feindlichen Übernahme durch einen chinesischen Investor gelitten, nach dem in China wegen Betrugs gefahndet wird“ und dass er nicht glaube, „dass eure Daten bei Mega noch sicher sind.“ - Bei Chip-Online heißt es: "Handeln Sie illegal, wenn Sie Dateien in der Mega-Cloud speichern? Nein. Die Speicherung einer Datei als private Kopie, ohne Umgehung eines Kopierschutzes, ist grundsätzlich zulässig. Allerdings dürfen Sie das Material nur alleine nutzen und keinem Dritten zugänglich machen." - Mega kommt also als Wiki-Account nicht infrage. -- Sumpfhütte 06:46, 28. Mär. 2018 (UTC)
Deine Kritikpunkte teile ich jetzt nicht ganz. Der Auszug von Chip ist etwas aus dem Kontext genommen, dort ist die Rede von urheberrechtlich geschütztem Material. Sowieso ist das kein Mega spezifisches Thema, sondern betrifft alle Cloud Dienste gleichermaßen. Der Unterschied bei Mega ist nur, dass sie selbst nicht wissen, was die Nutzer abspeichern, während andere Anbieter hineinsehen können. Dass Mega von einem kriminellen Chinesen gehalten wird ist auch nicht mehr, dessen Anteile wurden alle vom neuseeländischen Staat beschlagnahmt, womit dieser Hauptanteilseigner ist. Dass die gespeicherten Inhalte nicht mehr sicher sein sollen kann ich nicht nachvollziehen, da Mega nachweißlich keinen Zugriff hat. Bezieht sich dies mehr darauf, dass der Dienst auch mal plötzlich vom Netz genommen werden kann, so wie damals Megaupload, so ist dies ein Risiko, dass man bei jedem Anbieter eingeht.
Alles in allem finde ich bei Mega die Sicherheit, Geschwindigkeit und Werbefreiheit sehr wichtig. In dieser Kombination bekommt man dies bei keinem anderen Anbieter geboten. Das sind dann auch genau die Punkte, weswegen ich absolut gegen MediaFire bin, gerade die Werbung ist eine Katastrophe und vor allem für junge Nutzer gefährlich. Die kostenfreien 50 GB bei Mega sind natürlich auch nicht zu verachten.
Wenn das aber nicht reicht, um die Bedenken zu überkommen, bin ich für eine Alternative offen, solange sie werbefrei ist und genügend Speicherplatz (nicht weniger als 10 GB) bietet. Dropbox, OneDrive und iCloud fallen daher schonmal weg, Google Drive mit 15 GB und die Magenta Cloud der Telekom mit 10 GB und EU Recht als Grundlage sind dann wohl die besten Optionen. – Fuzs 08:38, 28. Mär. 2018 (UTC)
Das waren dann wohl etwas ältere Infos bezgl. Mega, die ich gefunden hatte. Aktuell bleibt aber das Lizenzproblem, und das betrifft - wie du richtig sagst - alle Dienste gleichermaßen, wie auch z.B. die Bilder im Wiki. Bisher hat sich noch nie jemand über Copyright-Verletzungen beschwert, aber Lizenzrechte sind ein schwieriges Thema. Ich könnte mir daher ein nicht-öffentliches Archiv vorstellen: Im Wiki gibt es eine neue Seite "Minecraft Wiki: Datenarchiv", die alle archivierten Dateien auflistet mit Link zum Original (Videos und alte MC-Versionen, die (noch) nicht bei Mojang stehen Es wird ja bei Mojang jmd. speziell für den Launcher eingestellt, vllt. werden irgendwann weitere Versionen offiziell zur Verfügung stehen). Zusätzlich und zur Sicherheit werden die Dateien in einem neuen Wiki-Cloud-Account (Mega oder vergleichbar) gespeichert, der nur für Admins und dich zugänglich ist. Dadurch bleiben die kopierten Originaldaten privat. Das Problem haben wir im Technik Wiki nicht, weil die Inhalte von Nethonos und Co. selbst produziert wurden. Was meinen die anderen Admins dazu? -- Sumpfhütte 09:06, 28. Mär. 2018 (UTC)
Ich war sowieso mittlerweile davon ausgegangen, dass das Archiv nicht öffentlich zugänglich sein wird. Daher u. a. auch der zuvor geäußerte Vorschlag, die gefundenen, aber nicht im Launcher zugänglichen Spielversionen mit zu speichern. So eine Archivseiten ist als Übersicht wirklich am besten, einzelne Bilder hochzuladen ist vergleichsweise zu viel Aufwand und bei wirklichem Interesse sowieso nicht ausreichend. Ich habe mit so einem Archiv schonmal angefangen, jeder Eintrag besteht aus drei Dateien, du kannst dir das mal in Discord ansehen.
Wo hast du eigentlich die Information bezüglich der Einstellung einer Arbeitskraft speziell für den Launcher? Das wäre wirklich interessant. – Fuzs 09:57, 28. Mär. 2018 (UTC)
Aktuelle Job-Ausschreibungen von Mojang, davor eine für den Launcher.   HorseHead.png MarkusRost (Diskussion) 10:17, 28. Mär. 2018 (UTC)
Ich würde Google Drive vorziehen, da ich damit bisher am meisten zutun hatte. Außerdem hat dort eh schon fast jeder einen Account (durch Google/YouTube) und man kann somit gut einstellen, wer welche Dateien auch ändern oder nur sehen können soll. Desweiteren kann man gut nachverfolgen, wer wann was geändert hat.   HorseHead.png MarkusRost (Diskussion) 10:38, 28. Mär. 2018 (UTC)

Artikel mit zu vielen gleichzeitig behandelten Inhalten aufteilen[Bearbeiten]

Ich würde ganz gerne einige Artikel, die momentan sehr viele verschiedene Inhalte gleichzeitig behandeln, aufspalten, um so eine bessere Übersichtlichkeit gewähren zu können. Auch wenn danach manche der einzelnen Artikel vielleicht nicht ganz so lang sein werden, wie man sich das sonst so wünscht, ist doch die Übersichtlichkeit am wichtigsten. Teilweise ist es nämlich jetzt in den einzelnen Abschnitten manchmal schon nicht ganz klar, um welchen der mehreren Inhalte es genau geht. Teilweise ist auch, wie z. B. bei der Melone, der gesamte Artikel allein durch die ganzen Steckbriefen ziemlich voll. Betroffen wären von diesem Unternehmen:

  • Weizen in Weizen und Weizenkörner
  • Rote Bete in Rote Bete und Rote-Bete-Samen
  • Melone in Melone, Melonenscheibe und Melonenkerne
  • Kürbis in Kürbis und Kürbiskerne
  • Netherziegel in Netherziegel und Netherziegel (Gegenstand)
  • Ton in Ton und Tonklumpen
  • Schnee in Schnee und Schnee (Schicht)

Die Pflanzen sind dann jeweils bei dem Gegenstand einzuordnen, durch den sie platziert werden, also z. B. die Weizenpflanze bei den Weizensamen. Hat jemand etwas gegen diese Aufteilung? Vielleicht fehlen auch noch ein paar Seiten, habe jetzt nicht so ganz genau überall nachgeschaut, wo es nötig wäre. – Fuzs 23:06, 2. Apr. 2018 (UTC)

Hm, "Ton und Tonklumpen" zu trennen wäre wie "Diamant und Diamantblock", also okay. Dasselbe gilt dann auch für Schnee und Schneeschicht, wobei es für 1.13 neue Namen gibt: Schneeblock und Schnee. Da es mit 1.13 auch für die ganzen Pflanzenblöcke offizielle Namen gibt, wäre es besser, mit dem Thema "Aufteilung" noch ein paar Wochen zu warten. -- Sumpfhütte 12:03, 3. Apr. 2018 (UTC)
Dass die technischen Blöcke nun auch offiziell benannt sind, ist irgendwie an mir vorbei gezogen, aber das ist prima. Da stellt sich dann nur die Frage, ob diese auch separat abgehandelt werden sollten, was ich mir aber in den meisten Fällen etwas schwierig vorstelle, so ganz ohne Anknüpfung an den Gegenstand, der sie platziert. Wir sollten das aber auf jeden Fall einheitlich gestalten, denn momentan ist es verschieden gelöst. Bei Pflanzen sind Gegenstand und technischer Block (noch) gemeinsam, z. B. Redstone und Redstone-Kabel sowie Faden und Stolperdraht sind aber getrennt. Eine von beiden Seiten muss angepasst werden.
Aufschieben würde ich die Aufteilung aber nicht, wir haben bereits alles, was wir brauchen. Die offiziellen Übersetzungen sind schließlich fertig, und die Entwickler sind mit dem Inhalt des technischen Updates auch durch, zumindest, was das hier betrifft. – Fuzs 14:33, 3. Apr. 2018 (UTC)
Nicht so voreilig, die Übersetzungen können sich immer noch ändern. Ich würde auch lieber auf die Veröffentlichung der 1.13 warten. Da kann dann alles angerissen werden. -- Nethonos 16:23, 3. Apr. 2018 (UTC)
Den Grund für die Übersetzung aller Blöcke vermute ich in dem neuen Feature der Übersetzungsanzeige, wenn man bei Eingabe eines Befehls mit der Maus über die Blockliste fährt. Es fehlen aber noch einige Blöcke (Mojang ist informiert), daher würde ich die paar Wochen noch warten, damit wir evtl. doppelten Aufwand sparen. - Der Artikel "technische Blöcke" wird mit 1.13 gelöscht, der Inhalt ist schon auf die entsprechenden Artikel verteilt. - Ich würde "Faden" und Redstone (heißt mit 1.13 "Redstone-Staub") mit Stolperdraht und Kabel zusammenfassen. Dann haben wir einheitlich immer Block und Erzeuger-Gegenstand zusammen, genauso wie bei den Objekten (Boot, Loren, Enderkristall). In der neuen Gegenstand#ID-Namen-Liste zeigt die letzte Spalte solche Erzeuger-Gegenstände an. -- Sumpfhütte 16:48, 3. Apr. 2018 (UTC)

Erledigt. -- Sumpfhütte 11:54, 9. Aug. 2018 (UTC)

Umbenennung des Menüleisten-Links Übersetzungsprojekt in Übersetzungs-Projekt[Bearbeiten]

Bei mir steht im Menü links:

Übersetzungsproje
kt

Das sieht extrem ha-e-ssl-ic-h aus, nicht? Lösung: Trennung mit dem Binde-Strich. –5.146.54.81 16:49, 1. Mai 2018 (UTC)

Ich habe ein weiches Trennzeichen eingebaut, somit sollte der Bruch nun an der richtigen Stelle sein.   HorseHead.png MarkusRost (Diskussion) 17:07, 1. Mai 2018 (UTC)

Minecraft Fehlermeldung.[Bearbeiten]

Hallo zusammen,

Ich habe mir heute auf (Minecraft.net) das spiel gekauft, aber leider stütz das spiel beim spielen ab und kommt nur die Fehlermeldung

The game crashed whilst initializing game Error: org.lwjgl.LWJGLException: Pixel format not accelerated

Ich weiß einfach nicht mehr weiter habe es neu installiert aber ohne erfolg neben bei kommt noch ein Nativelog damit kenne ich mich überhaupt nicht aus.

( Nativelog details )

...

Using new launcher as self upgrade has been detected.

...

Running launcher!

Launcher ended with 0


Hier habe ich mal den link geschickt villeicht hilft euch das weiter.

https://paste.ubuntu.com/p/Y3rcfCh3kB/


Hoffentlich kennt ihr das problem uns so könnt ihr mir helfen :) danke schon mal vorraus wenn fragen noch offen sind einfach raus damit :) -- Shavidzi 23. Mai 2018‎, 18:34

"Pixel format not accelerated" könnte ein Grafikproblem sein. Du scheinst keine Grafikarte sondern nur den Intel Chip G45/G43 zu haben. Scheint mir nicht genug zu sein, siehe Mindestanforderung des Spielherstellers Mojang. -- Sumpfhütte 17:52, 23. Mai 2018 (UTC)
Tatsächlich liegt der Grafikchip Intel G45 (10 Jahre alt!) unterhalb der Minimalanforderungen. Nichtsdestotrotz kannst du versuchen, den Intel-Grafikchip-Treiber zu updaten, deine momentane Version 8.x.x.x ist zu alt und bietet keine bzw. fehlerhafte OpenGL-Unterstützung. Hilfreich ist hier eine Hilfeseite von Mojang. --Kumasasa (Diskussion) 19:34, 23. Mai 2018 (UTC)

.

Blockvarianten[Bearbeiten]

Nur langjährige Spieler werden verstehen, warum die neuen entrindeten Stämme im Kreativinventar und in der Debug-Welt ganz vorne bei den Stämmen einsortiert sind. Dasselbe gilt z.B. für Granit, Diorit und Andesit, die vorne beim Stein stehen. Was haltet ihr von einem Hinweis auf "Blockfamilien" in den Block-Steckbriefen? Aus der Debug-Welt (oder der Datengeneratorliste) sind sie alle ablesbar, über die Definition müssten wir uns also keine Gedanken machen. Doch wie könnte man sie einheitlich und elegant abbilden? Wie wäre ein neues Steckbrief-Feld "Blockfamilie"? Das könnte z.B. bei Stein, Granit, Diorit und Andesit die Icons aller Familienmitglieder auflisten. Ich würde dabei Tooltips verwenden und die Namen weglassen, sonst wird die Liste wieder zu groß - und eingeklappt sollte sie keinesfalls werden. In der mobilen Ansicht funktioniert das zwar nicht, aber man kann nicht alles haben. Beispiel:



. Was meint ihr dazu? -- Sumpfhütte 06:15, 29. Jul. 2018 (UTC)

Den Vorschlag finde ich gut. Was mir noch spontan von offizieller Seite einfällt, wären die Aliasgruppen. Allerdings sind diese leider bei weitem noch nicht vollständig wie man sich das wünschen würde und so könnte man sie noch nicht 1:1 für diese Blockfamilien verwenden. -- Nethonos 10:40, 29. Jul. 2018 (UTC)
Hat sich erledigt. Ich habe eben in im Discord-Chat erfahren, dass es keine Blockfamilien gibt, sondern dass jeder Entwickler neue Blöcke einordnet, wo er will, meist am Ende. Damit bleibt alles, wie es ist: Wnn es sinnvoll erscheint ("Stein", "Schiene" "Holz"), dann machen wir eine Begriffsklärung wie bisher. -- Sumpfhütte 16:55, 29. Jul. 2018 (UTC)