Diskussion: Gemeinschaftsportal

Archiv
Januar - März 2011 April - Juni 2011 Juli 2011 - Juli 2012 August - November 2012 November 2012 - März 2013 März - Juni 2013 Juni - August 2013 September - Dezember 2013 Januar - März 2014 April - August 2014

Kategorien in den Steckbriefen

Mir fällt besonders bei den Item-Steckbriefen auf, dass als Kategorie oft einfach nur "Item" dort steht. Dabei kann man dort viel mehr draus machen. Im englischen Wiki wird dort bspw. zwischen Rohmaterialien oder weiterverarbeiteten Materialien (wo direkt der Typ angeben wird (also bspw. Färbemittel)) unterschieden. Wir sollten uns auf etwas einheitliches und sinnvolles einigen, damit der Punkt einen wirklichen Sinn erfüllt. --eagle3000 ^{(D ~ B)} 19:51, 1. Nov. 2013 (UTC)

Es sieht tatsächlich so aus, als ob man viel damit machen könnte. Aber die Vergangenheit hat gezeigt, dass dieser Weg der Kategorisierung auf Dauer nicht praktikabel ist. Wenn man einen Eintrag in der Steckbrief-Kategorie macht, wird automatisch eine Wiki-Kategorie im Kategorienbaum angelegt bzw. gefüllt. Das wurde aber nicht konsequent durchgeführt, weil irgendwann niemand mehr in den Kategorienbaum geschaut hat bzw. gar nicht wusste, dass der Steckbriefeintrag diese Auswirkung hat. Entsprechende Anleitungen werden leider nicht immer gelesen. Die Folge war eine unübersehbare Anzahl von Kategorien, die teilweise nur mit einem einzigen Item oder Block gefüllt waren. Viele Kategorisierungen wurden begonnen, manche sogar doppelt unter anderem Namen. Da gab es das Boot unter "Fahrzeuge" und die Lore unter "Fahrzeug". Bei neuen Blöcken und Items wurde nicht mehr im Kategorienbaum nachgeschaut und die Trichterlore wurde unter "Lore" kategorisiert. Die so angelegten Kategorien waren unvollständig und damit nutzlos. Mit viel Aufwand habe ich mich durch unseren stark verwilderten Kategorienbaum gekämpft und ihn aktualisiert und zurechtgestutzt. Das jetzige Konzept sieht so aus, dass die Kategorisierung nur über die Navigationsbox stattfindet. Wir haben jetzt weniger Wiki-Kategorien, aber trotzdem die volle Möglichkeit zur Einteilung und Gruppierung: nämlich ganz einfach über die Gruppierung der Navigationsbox (z.B. ganz aktuell die neue Gruppe "Blumen"). Der entscheidende Vorteil ist die Übersicht. Man muss nicht in den Kategorienbaum schauen und man sieht in der Navigationsbox gleichzeitig auch die Nachbargruppen auf einen Blick. Seit ein paar Monaten läuft das so, und es funktioniert: die Navigationsboxen sind aktuell. Es gibt sogar immer mal wieder einen Vorschlag zu einer Umgruppierung, was zeigt, dass die Leser hinschauen. Zum Kategorienbaum gab es noch keine einzige Anmerkung in den letzten Monaten. Unter diesem Gesichtpunkt wäre ich eher dafür, die Zeile "Kategorie" aus den Steckbriefen zu entfernen und die Kategorien "Block" und "Item" je nach Steckbriefart zu vergeben. -- Sumpfhütte 21:06, 1. Nov. 2013 (UTC)

Ob es ein Block oder ein Item ist, ist meist auf den ersten Blick erkennbar. Auch ohne den Hinweis im Steckbrief. Wenn man diesen Punkt entfernt, wird das wohl wenigen fehlen. Was man aber machen könnte um den Punkt beizubehalten wäre hier nochmals die "Navbox-Kategorie" zu nennen oder was noch etwas mehr Sinn machen würde: Die Einteilung im Inventar des Kreativ-Modus. Ist nur die Frage, ob man sowas braucht.--.zip ^{de.MinecraftWiki-Admin Diskussion} 23:58, 1. Nov. 2013 (UTC)

Ich hätte mal lieber nachgucken sollen, bevor ich mich aufrege :-) Es ist bereits so, dass die beiden Steckbriefe Vorlage:Block und Vorlage:Gegenstand die Kategorie:Block und die Kategorie:Gegenstand vergeben, ohne Beachtung, was bei "type" eingegeben wurde. Es war nur nicht oder sogar fehlerhaft dokumentiert. Uff - damit sind meine Bedenken hinfällig.
Bleibt die Frage von eagle3000: "Wir sollten uns auf etwas einheitliches und sinnvolles einigen, damit der Punkt einen wirklichen Sinn erfüllt." In der Vorlagendoku von "Block" steht als Ausfüllanweisung für "type": "Solider Block, Solide, Block, oder Flüssig". Bei der Vorlage "Item" gibt es keine Ausfüllanweisung. Die Vorlage "Block" hat aber noch eine Spezialität: wenn der Typ "flüssig" eingegeben wurde - und nur dann - erscheinen die beiden neuen Einträge "Fließgeschwindigkeit" und "Geschwindigkeit beim Durchqueren".
Falls wir den Typ beibehalten (um die Verwechslung zu vermeiden, auf die ich gerade hereingefallen bin, habe ich die Beschriftung für "type" von "Kategorie" auf "Typ" geändert), sollten wir uns auf eine feste Menge von Typen einigen und in der Vorlage abfragen: wenn ein dort ein falscher Typ eingetragen wird, kommt eine rote Warnung. Das wäre eine Hilfe beim Ausfüllen des Steckbriefes. -- Sumpfhütte 08:20, 2. Nov. 2013 (UTC)

Finde die Idee gut, sich auf bestimmte Typen zu einigen und diese dann auf alle Einbindungen anzuwenden. Eventuell sind auch weitere besondere Einträge bei bestimmten Typen (wie bei Flüssigkeiten) sinnvoll. --eagle3000 ^{(D ~ B)} 18:40, 18. Nov. 2013 (UTC)

Hast du schon Ideen? Mach doch mal einen Vorschlag für eine übersichtliche Anzahl von Block- und Item-Typen... -- Sumpfhütte 20:34, 18. Nov. 2013 (UTC)

@Sumpfhütte, Eagle3000: Die Diskussions zwischen euch beiden ist wohl eingeschlaften. Vielleicht lässt sich das mit einem neuen Anlauf klären. --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 11:03, 26. Apr. 2014 (UTC)

Gerne. Aber wie man jetzt nach ein paar Tagen sieht, scheint eagle3000 im Moment keine Zeit dafür zu haben... -- Sumpfhütte 20:46, 6. Mai 2014 (UTC)

Unter "Kategorie" fände ich eigentlich die Einteilung des Kreativmodusinventars passend (wobei manche Blöcke/Items da auch fragwürdig platziert sind). Also gibt es dann die Kategorien "Baumaterial", "Dekoration", "Redstone", "Beförderung", "Verschiedenes", sowie "Nahrung", "Werkzeug", "Kampf", "Brauen" und "Werkstoffe". Allerdings gibt es dann auch nicht einordbare Blöcke, das wäre dann die "wikieigene" Kategorie "Technischer Block" (Alle nur durch Befehle erhaltbare Blöcke, z.B. Ackerboden, Befehlsblock, Doppelte Stufe, etc). Natürlich ist das nicht das gleiche wie zuvor, aber man hat eine grobe Einteilung, wofür der Block/der Gegenstand benutzt wird bzw. benutzt werden kann. | violine1101^(Diskussion) 20:34, 7. Sep. 2014 (UTC)

@Violine1101: Da wären wir dann schon zu zweit. Den Vorschlag habe ich ja weiter oben auch schon gemacht. Ich möchte auch nochmal meine Frage wiederholen: Brauchen wir diese Kategorisierung/Typisierung überhaupt? Kategorien werden im Wiki mit den Navboxen vergeben. Und welchen Mehrwert hat der Nutzer, wenn diese Kategorie oder die des Kreativmodus-Inventars im Steckbrief angezeigt wird? Zum schnellen Finden im Inventar gibt es die Suchfunktion. Ich wäre dafür, diesen Parameter zu entfernen --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 21:32, 7. Sep. 2014 (UTC)

Da wir ausgiebige Navigationsboxen haben, und Kategorien (selbst in der großen Wikipedia) selten den Lesern dienen, sondern meistens den Autoren (oder Botbetreibern) - meinerseits kann das auch entfallen. --Caleb Blackhand 07:08, 8. Sep. 2014 (UTC)

Auch ich brauche keine Kategorisierung in den Steckbriefen. Die Navboxen finde ich perfekt - insbesondere wenn einige Blöcke oder Gegenstände zu zwei Kategorien gehören. Dann zeigen wir einfach beide Navboxen. Und die Navboxen haben den Vorteil, dass man schön übersichtlich Unterkategorien bilden kann, wie z.B. für die Blumen: Navbox-Dekoration/Pflanzen/Blumen. -- Sumpfhütte 10:13, 8. Sep. 2014 (UTC)

Ich meinte damit, dass man, falls man die Kategorien wieder einführt, man dies am besten in der oben beschriebenen Art und Weise tut. Natürlich benötigt man die Kategorien nicht unbedingt, ich wollte nur einen Vorschlag machen, welche Kategorien für mich in Frage kämen, .zip's Vorschlag oben habe ich übersehen, sorry. Allerdings würde ich mich für eine Information "Kreativ-Modus-Kategorie" (o.ä.) im Steckbrief einsetzen, da sie Minecraft- oder Kreativmodus-Neulingen die Orientierung erleichtern kann. | violine1101^(Diskussion) 10:33, 8. Sep. 2014 (UTC)

Die Kreativmodus-Kategorien sind leider unbrauchbar. Mojang selbst hat sogar schon eine Suchfunktion eingebaut, weil man viele Blöcke und Gegenstände nicht dort findet, wo man sie vermuten würde. Bestes Beispiel: die völlig unbrauchbare Kreativmodus-Kategorie "Verschiedenes". Wir haben im Wiki darüber vor ca. einem Jahr ausführlich diskutiert, mit dem Ergebnis, dass wir mit unseren Navboxen dem Wiki-Leser eine bessere Orientierung geben. Daher: falls Kategorien, dann bitte nicht die Kreativmodus-Kategorien, sondern die Navbox-Kategorien. Weil es aber Blöcke und Gegenstände gibt, die zu zwei Kategorien gehören, müsste das Feld die Eingabe mehrerer Navbox-Kategorien erlauben. Das ist aber alles gar nicht nötig, weil wir die Navboxen bereits am Ende des Artikels haben. Und sie erzeugen automatisch eine Kategorie für den Kategorienbaum. Und sie sind übersichtlicher, weil sie den Block/Gegenstand zusammen mit den anderen seiner Kategoriengruppe zeigen. Und sie sind flexibler, weil man Unterkategorien bilden kann, z.B. "Blumen". Daher halte ich eine solche Kategorisierung in den Steckbriefen für unnötig. -- Sumpfhütte 11:13, 8. Sep. 2014 (UTC)

Deine Argumente sind berechtigt, und ich denke, dass keiner die Kategorisierung wirklich vermisst. Von daher für mich auch eine mögliche Lösung, die Kategorisierung in den Steckbriefen entgültig zu vergessen. Damit wäre das Thema dann erledigt und gelöst. | violine1101^(Diskussion) 17:19, 8. Sep. 2014 (UTC)

Ich habe hier mal unsere Vorlage:Block mithilfe der englischen aktualisiert und gleichzeitig übersetzt. Den Parameter type habe ich entfernt und die beiden Einträge, die davon abhängen entsprechend abgeändert. Dabei ist mir aufgefallen, dass man zwischen Blöcken und Gegenständen differenzieren muss.

Vorlage:Gegenstand: Bisherige Diskussion. Auf der einen Seite, würden Kategorien vielleicht doppelt genannt werden. Was wir allerdings bis jetzt nicht bedacht haben: Die Steckbriefe dienen ja mehr oder weniger dazu, dem Leser auf einem Blick die wichtigsten Informationen zu bieten. Beachten sollte man auch, dass der Steckbrief vermutlich für Nutzer von Smartphones interessant ist, da er sofort nach Seitenaufruf angezeigt wird, während der restliche Text eingeklappt ist und erst mal nicht sichtbar ist. Der Steckbrief füllt den gesamten Bildschirmbereich aus. Unter dem Gesichtspunkt, finde ich es vertretbar, dort eine Kategorie zu nennen. Dann weiß der Nutzer gleich, um was es sich handelt (Nahrung, Werkstoff, Brauzutat etc.) und ob es für ihn evtl von Wert ist. Die Navboxen helfen Smartphone-Besitzern in der Richtung gar nicht weiter, weil die dort relativ schlecht dargestellt werden. Zumindest bei meinem Gerät. Sich eine extra Kategorie für z. B. das Papier aus der Nase zu ziehen, sollte aber auch nicht der Sinn sein. Es ist weder Nahrung, noch für das Brauen wichtig, was eine eindeutige Zuordnung wäre. Ich würde deswegen vorschlagen, für Gegenstände einen eigenen Eintrag "Nutzen" anzulegen, wo dann alle Nutzungsarten aufgelistet werden. Beim Brot wäre dass dann "Nahrung", beim Weizen "Brot, Züchten, Strohballen" oder beim Papier "Buch, Karte", um einige Beispiele zu nennen.
Vorlage:Block: Die aktuelle Einteilung in solide, unsolide und flüssige Blöcke halte ich für nützlich. Das im Hinblick darauf, was "Wasserfest" ist, und mit was man lieber nicht versucht, z. B. Lava zu stoppen. Ich finde, diese Information sollte auf den ersten Blick sichtbar sein. Auch hier könnte ein Eintrag "Nutzen" nützlich sein, um auf herstellbare Blöcke und Gegenstände hinzuweisen. Zwei weitere Informationen, die ich wichtig finde, sind die Dimensionen und Biome, wo der Block anzutreffen ist. Diese beiden Einträge habe ich in meinen Entwurf eingefügt. --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 16:37, 9. Sep. 2014 (UTC)

Die Information über die Smartphone-Nutzer wirft ein neues Licht auf die Sache. Laut Navbox ist das Papier übrigens ein "Werkstoff". Bisher enthalten die Steckbriefe nur eindeutige Informationen. Das Ausfüllen eines Eintrages "Nutzen" würde dagegen der Kreativität des Autors überlassen: Soll man bei Netherwarzen als Nutzen "Hühner" oder "Hühnerzucht" oder "Tierzucht" schreiben? Und man darf dann nicht vergessen, das wieder zu löschen, wenn ein Nutzen - wie jetzt mit der 1.8 geschehen - wieder entfällt. Warum nicht einfach die Überschrift der jeweiligen Navbox(en) verwenden. Da hat sich schon jemand eine Kategorisierung überlegt, die kann man doch übernehmen. -- Sumpfhütte 20:06, 9. Sep. 2014 (UTC)

@Sumpfhütte: Ich hätte ich auch nichts dagegen, die Navbox-Kategorien nochmals zu verwenden. Das geht jedoch an der Idee vorbei, die ich oben erläutert habe. Unter "Nutzen" würden alle Nutzen verlinkt werden. Der mobile Nutzer sieht also gleich, für was der Gegenstand benötigt wird und hat auch einen weiterführenden Link zur Verfügung. Man kann ja verschiede Parameter definieren (Nutzen1=Tierzucht, Nutzen2=Nahrung etc.) Alle anderen Angaben würden nicht angezeigt werden. Nach Updates sollten die Artikel sowieso überarbeitet werden. Der Steckbrief wäre dann halt ein weiterer Punkt, auf den man achten müsste, was aber meiner Meinung nach zumutbar ist. So oft fallen Funktionen ja nicht weg. Und wenn doch, weiß man ja, wo man suchen muss. -- 17:08, 15. Sep. 2014‎ Xzipx

Nicht kategorisierte Bilder (== nicht lizenzierte Bilder)

Moin. Ich habe mir mal Liste nicht kategorisierter Bilder angesehen - fast 2.400 Stück derzeit. Das Problem: Wenn gar keine Kategorie drin ist, dann ist auch keine Lizenz drin. Mein Vorschlag: Ich lasse meinen Bot drauf los, mit der folgenden Vorgabe: Wird ein Bild nur in Artikeln eingesetzt (und zwar in solchen, die nicht zu einem Mod gehören), dann setze {{Lizenz-Mojang}} ein (denn wir erlauben in den normalen Artikeln ja nur unmodifizierte Bilder), ansonsten {{Lizenz-Unklar}}. Die Bilder mit Lizenz-unklar müssen dann mal per Hand angegangen werden, aber einen gewissen Anteil kann der Bot dann schon mal erschlagen. Alternativ kann ich auch direkt alle Bilder durchgehen und auf eine Lizenz-Vorlage prüfen - so finden wir auch unlizenzierte Bilder, die dennoch eine Kategorie haben. Ob der Bot nun 2.400 Bilder oder 6.162 Bilder abklappert... --Caleb Blackhand 11:58, 25. Feb. 2014 (UTC)

Guter Vorschlag. Ich würde alle Bilder abklappern. Ich vermute dabei, dass der Fall "Bild mit Kategorie aber ohne Lizenz" nur sehr selten vorkommt. 2400 "Bilder ohne Kategorie (und ohne Lizenz)" ist dagegen sehr viel, ein Drittel aller Bilder! Ich würde die Nicht-Mod-Bilder jedoch nicht pauschal mit der "Mojang-Lizenz" versehen, weil auch Fotos von Mitarbeitern, Grafiken, gifs etc. dabei sein können. Wenn es möglich ist, könnte man die Abmessung abfragen: Ein Standard-Screenshot ist 960 × 620 Pixel groß und vom Typ "png". Nur bei diesen Nicht-Mod-Bildern würde ich pauschal sagen, dass es Mojang ist. -- Sumpfhütte 12:33, 25. Feb. 2014 (UTC)

Ich vermute auch, dass es nicht viele Bilder mit Kategorie und ohne Lizenz gibt, aber man weiss ja nie. Das mit den Fotos etc. stimmt - die Lösung mit dem Größentest gefällt mir auch. Und wenn in den restlichen Bildern noch manuell Mojang-Lizenzen verteilt werden müssen, stört das auch nur begrenzt. Dass ich uns / mir da einiges an Arbeit heranhole (Lizenzen abprüfen macht keinen wirklichen Spass, aber nun ja) - bekannt. Notwendig isses aber auch. --Caleb Blackhand 12:41, 25. Feb. 2014 (UTC)

Frage an einen MediaWiki-Profi: früher wurde beim Hochladen eines Bildes automatisch die Mojang-Lizenz vorgegeben, jetzt korrekterweise keine. Es gibt bereits eine Prüfung beim Hochladen, z.B. wenn die Dateiendung fehlt. Könnte man eine weitere Prüfung hinzufügen, wenn die Lizenz fehlt? Was müsste man dazu tun? -- Sumpfhütte 13:04, 25. Feb. 2014 (UTC)

Eventuell kann der Missbrauchsfilter da helfen - wenn im zu speichernden Bild-Text nicht mindestens eine Vorlage enthalten ist, die mit {{Lizenz- beginnt, dann sollte er meckern. WENN man beim Upload den Filter überhaupt brauchen kann.

Was anderes: Das mit der Bildgröße ist ..... unbrauchbar. Anscheinend sind 960x620 kein Maßstab für Screenshots, jedenfalls habe ich in einem Testlauf unter 2712 Bildern (er war fast durch) nicht ein einziges Bild mit diesen Maßen gefunden, was ich mit der Lizenz versehen könnte. Ich glaube, das Problem müssen wir ein wenig anders angehen. --Caleb Blackhand 16:50, 25. Feb. 2014 (UTC)

Am besten wir erledigen das von Hand. Wenn sich mehrere beteiligen, geht das auch entsprechend schnell. Das kann ja auch nebenbei laufen. Ein wirkliches Problem in dem Sinne ist es ja nicht. --.zip ^{de.MinecraftWiki-Admin Diskussion} 16:58, 25. Feb. 2014 (UTC)

Ich denke auch. Also lasse ich den Bot laufen, der schiebt allen Bildern ohne Lizenz die Lizenz-unklar unter, und wir versuchen dann manuell (oder teilautomatisch) die Kategorie wieder leerzuräumen? --Caleb Blackhand 17:01, 25. Feb. 2014 (UTC)

Ja, würde ich so machen. --.zip ^{de.MinecraftWiki-Admin Diskussion} 17:20, 25. Feb. 2014 (UTC)

Sodale, der Bot ist durch. Unter Spezial:Nicht_kategorisierte_Dateien stehen noch ein paar Admin-pflichtige Bilder, die ohne Lizenz sind, den Rest (schlappe 2.814 Dateien) findet man in der Kategorie:Unlizenzierte Bilder. --Caleb Blackhand 08:32, 27. Feb. 2014 (UTC)

Kleiner Service für all jene, die beim Umlizenzieren helfen wollen: Ich habe ein Script geschrieben, was eine Lizenz in die Seite einträgt und die Zusammenfassung vorbelegt. Einbinden kann man dieses Script in der eigenen common.js mit importScript('Benutzer:CalebBlackhand/BildLizenzen.js');. --Caleb Blackhand 16:45, 27. Feb. 2014 (UTC)

Upsala, wo ist die 2. Hälfte meines Posts abgeblieben? Wie man einbindet steht da, aber wie man's benutzt nicht. ;)

Kurzanleitung: Bild "bearbeiten" und dann aus der Drop-Down-Navi (Pfeil rechts oben) die gewünschte Lizenz aussuchen. Hat man sich verklickt - egal, einfach die richtige anklicken. Und dann speichern. --Caleb Blackhand 17:23, 27. Feb. 2014 (UTC)

Darf ich fragen welche Browser ihr benutzt und ob das Scipt da funktioniert? Bei mir hat das Script nämlich zuerst im IE funktioniert, in Chrome und Firefox ging es noch nie. Jetzt funktioniert es aber seltsamerweise selbst im IE nicht mehr. Minoredit, Watchlist und Summary werden bei allen dreien noch geändert, aber der Seitentext bleibt gleich. Browserdaten löschen hat diesmal auch nix genützt. Ich habe das Script zwar minimalst abgeändert, aber daran liegt es nicht, das Problem hatte ich mit dem Original auch schon. -- Elike98 ^Diskussion 11:55, 28. Feb. 2014 (UTC)

Ich habe das Script in Firefox und Opera im Einsatz, alles okay. Kleiner Hinweis (den ich immer vergesse, weil ich den kram aus habe): Das Script funktioniert vmtl. nicht, wenn dieser RichText-Editor aktiv ist. Ich habe ein einfaches Eingabefenster ohne Symbolleisten etc., damit funktioniert das. Also keine "Erweiterte Bearbeiten-Werkzeugleiste aktiviere" oder "Assistenten zum Einfügen von Links und Tabellen sowie die Funktion „Suchen und Ersetzen“ aktivieren" aus den Beta-Funktionen im Reiter Bearbeiten, und gesetzter Haken bei "Nicht an Funktionsexperimenten teilnehmen" im Reiter Aussehen der eigenen Einstellungen. --Caleb Blackhand 12:16, 28. Feb. 2014 (UTC)

Danke schön, jetzt funktioniert´s :) -- Elike98 ^Diskussion 13:50, 28. Feb. 2014 (UTC)

Die 2000 sind geknackt :D -- Elike98 ^Diskussion 17:45, 1. Mär. 2014 (UTC)

Ich glaube, wir sollten uns nochmal einigen, wie wir das mit den Lizenzen der Mod-Bilder handhaben. Bei einigen Mod-Bildern wurde jetzt schon Lizenz-Mojang verteilt. Die letzte Diskussion darüber habe ich leider nicht mehr gefunden. Laut Minecraft-EULA gehören die Mods den Erstellern. Eigentlich müssten wir für jede Mod die Erlaubnis der Autoren einholen und uns nach der Lizenz erkundigen..., oder? --.zip ^{de.MinecraftWiki-Admin Diskussion} 10:41, 4. Mär. 2014 (UTC)

Fast, ja. Die Mod-Bilder, die ich getaggt habe, waren aus 100%-Mojang-Strukturen zusammengesetzt - Dass ein Mod z.B. einen Gletscher aus bestehenden Blöcken generiert, ist zwar eine großartige Leistung, ohne Frage - die Texturen und das Bild sind aber trotzdem Mojang. Gleiches gilt für besondere Redstone-Schaltungen (RedPower2 AND-Modul zum Beispiel) - das war fast ausschließlich Mojang-Artwork und Modelle, die Änderung am Komparator zur AND-Achaltung war vernachlässigbar gering.

Bei den Bildern, wo neue Objekte (Mobs, Zusatz-Blöcke mit eigenen Texturen etc.) auftauchen bzw. primär abgebildet sind, wäre die Mojang-Lizenz vmtl. fehl am Platz. Aus genau dem Grund sind auch sämtliche RedPower2-Gridbilder noch unlizenziert. --Caleb Blackhand 10:46, 4. Mär. 2014 (UTC)

Oh, ich dachte, alle, bei denen z.B. Gras im Hintergrund ist, gehören zur Lizenz Mojang und hab die jetzt eingetragen. ´tschuldigung! -- Elike98 ^Diskussion 10:49, 4. Mär. 2014 (UTC)

Hier ist die gesuchte Diskussion: Datei Diskussion:RoachMo.png -- Sumpfhütte 10:55, 4. Mär. 2014 (UTC)

Ahh, Danke. Darauf bezug nehmend: Keine festgelegte Lizenz heißt automatisch Lizenz-Copyright? Haben wir dann überhaupt das Recht, die Dateien zu verwenden? --.zip ^{de.MinecraftWiki-Admin Diskussion} 11:03, 4. Mär. 2014 (UTC)

Kommt auf den Uploader an. Ja, ich weiss, tolle Aussage - wenn ein Mod-Autor das hochlädt, dann isses als "Copyright" okay (sofern wir annehmen, dass der Mod-Autor die Rechte an den Bildchen hat). Ist's irgend ein User, dann wird es fraglich.

Nun schlage ich mal nicht vor, dass wir ein System wie das OTRS-Team der Wikipedia auf die Beine stellen - aber drüber nachdenken, wie wir das mit den Lizenzen anstellen, müssen wir schon. Die einfachste Lösung wäre, einige Mods radikal zu entbildern, wenn im Mod oder auf deren Seite keine Lizenz erwähnt wird. --Caleb Blackhand 11:11, 4. Mär. 2014 (UTC)

Noch eine Frage zu den Lizenzen: Ich hab den Bildern der Skin-Pakete jetzt mal die Lizenz-Mojang angehängt. Stimmt das so, oder bezieht sich die nur auf die reinen Spielinhalte und die Screenshots? -- Elike98 ^Diskussion 11:42, 4. Mär. 2014 (UTC)

Skins sind wie Mods: wenn es um eine neue Textur geht, die nicht von Mojang kommt, ist auch nicht Mojang der Urheber, also gilt auch nicht die Mojang-Lizenz. @Elike98: bitte prüfe nochmal deine Arbeit und ändere ggf. die Lizenzen bei Skins und Mods.
Ich sehe das so: Wenn der Urheber eine spezielle Angabe zur Bild-Lizenz macht, dann wird diese verwendet. Wenn er keine Angabe macht (häufigster Fall), würde ich ihm standardmäßig das Copyright zusprechen. Das heißt nicht, wir müssen die Bilder entfernen, sondern das heißt, Wiki-Leser dürfen die Bilder nicht verändern oder aus unserem Wiki auf andere Seiten hochladen. Falls ein Urheber nicht möchte, dass sein Bild im Wiki verwendet wird, hätte er auf seiner Seite explizit sagen müssen. Wenn er das nachträglich macht, kann er sich jederzeit ans Wiki wenden und wir nehmen das Bild wieder raus (so wie z.B. die Seite über Ez mit Bild, die im engl. Wiki darum gebeten hatte). Solange wir ihm das Copyright zusprechen und er sich nicht beschwert, würde ich das Bild drin lassen. -- Sumpfhütte 11:57, 4. Mär. 2014 (UTC)

Ok, mach ich. Was die Skins betrifft: Ich hab eigentlich vor allem die offiziellen Skin-Pakete für XBox 360 gemeint. -- Elike98 ^Diskussion 11:59, 4. Mär. 2014 (UTC)

Mir fallen immer wieder die vielen Dateien mit MsUpload auf, die keine Lizenz haben. Könnte man diese Extension nicht einfach abstellen? Dann müssten alle die Seite Spezial:Hochladen verwenden, wo man direkt zum Angeben einer Lizenz aufgefordert wird, was uns in Zukunft viel Nachlizenzieren ersparen würde. Und aufwendiger ist das Einfügen von Dateien meiner Ansicht nach dann auch nicht, weil man die Dateiseite dann nicht mehr extra bearbeiten muss, um die Lizenz einzufügen. Oder? -- Elike98 ^Diskussion 16:14, 19. Mär. 2014 (UTC)

Ja, ja, ja, ja, ja, ja, ja, ja, aus damit..... ;)

Ich persönlich könnte auf dieses Plugin gut verzichten. Drag&Drop-File-Upload.... Hmmnunja.... welche Probleme das macht, sieht man ja. --Caleb Blackhand 16:20, 19. Mär. 2014 (UTC)

Hier steht, dass man "LocalSettings.php" ändern müsste. Ich vermute, das kann nur Curse, oder? (Und die wollen alle Wikis gleich haben). -- Sumpfhütte 20:28, 19. Mär. 2014 (UTC)

Ich kenne mich nicht genau damit aus, was diese Erweiterung alles hinzufügt oder ändert, aber bei mir ließ sich wenigstens der "Dateien hier ablegen"-Balken mit der Zeile

DIV#upload_container {display:none !important;}

in den common.css ausblenden. Diese Lösung ist zwar sicherlich weder effizient noch "schön", aber auf jeden Fall besteht mindestens eine Möglichkeit, den Balken wegzukriegen, falls man die Erweiterung nicht abstellen kann. -- Elike98 ^Diskussion 15:22, 20. Mär. 2014 (UTC)

Wäre es möglich, diese Systemnachricht abzuändern, sodass eine diesbezügliche Meldung angezeigt wird? -- Elike98 ^Diskussion 14:54, 11. Apr. 2014 (UTC)

Was genau soll dann angezeigt werden? --.zip ^{de.MinecraftWiki-Admin Diskussion} 10:07, 15. Apr. 2014 (UTC)

So nach der Art "Bitte denke daran, zu jedem Bild, das du hochlädst, eine Lizenz anzufügen, indem du auf der zugehörigen Dateiseite die passende Vorlage einsetzt." -- Elike98 ^Diskussion 10:29, 15. Apr. 2014 (UTC)

@Elike98: Erledigt Tut mir wirklich leid, dass das so lange gedauert hat.--Xzipx ^{de.MinecraftWiki-Admin Diskussion} 19:44, 27. Jul. 2014 (UTC)

@Xzipx: Kein Problem, vielen Dank. Hoffentlich hilft´s :D -- Elike98 ^Diskussion 19:59, 27. Jul. 2014 (UTC)

Es nähert sich das Ende. Spezial:Nicht kategorisierte Dateien ist leer (bzw. sieht gelegentlich mal Einzelbilder), und Kategorie:Unlizenzierte Bilder hat weniger als 7050 Restposten. Leider sind da noch viele Fotos von Mojang-Mitarbeitern bei, bei denen leider keine Quelle angegeben wurde, was das korrekte Lizenzieren erschwert. Radikal-Lösung (hier möglich, in der Wikipedia wäre das nicht drin): Ich setze bei den Fotos einfach überall "Lizenz Copyright". Spricht da aus irgendjemandes Sicht was dagegen? Ansonsten müsste ich die Bilder wirklich einfach mal löschen. Ja, die sind aus dem englischsprachigen MC-Wiki kopiert, dort aber genauso Quell- und Lizenzlos - genau das ist mein Problem. --Caleb Blackhand 10:02, 24. Aug. 2014 (UTC)

Die meisten Bilder stammen von den öffentlichen LinkedIn- oder Facebookseiten der Mojangsters. Einige wurden von mir aus einem offiziellen Mojang-MIneCon-Video geschnitten, das wäre also Mojang (falls ich das nicht eingetragen haben sollte). Lizenz-Copyright gilt aber natürlich auch für Mojang, also wäre das eine perfekte Wahl für die Mitarbeiterfotos. -- Sumpfhütte 10:41, 24. Aug. 2014 (UTC)

Von dir sind da keine mehr bei, sonst hättest du schon einen Kommentar auf deiner Diskussionsseite gefunden. Okay, dann mache ich mich da gleich mal dran. Die Skins werden auch noch lustig, aber da schau ich danach mal. Wir sind nah dran, die kompletten Bilder durchlizenziert zu haben (und damit mal wieder deutlich weiter als die en-Kollegen) --Caleb Blackhand 10:48, 24. Aug. 2014 (UTC)

Großbaustellen: Hilfe bei Physikalische Mechanismen

Wie ihr sicherlich mitbekommen habt, bin ich grad an drei Megaprojekten beschäftgt: Redstone-Schaltkreise, Schienenverkehr und Physikalische Mechanismen. Wobei Anleitungen/Mechanismen als Hauptseite für diese drei Mechanismen fungiert, welche auch eine Baustelle ist. Ich wollte fragen ob jemand die Baustelle Physikalische Mechanismen übernehmen könnte ? Da ich noch sehr lange bei den beiden Tehmen Redstone-Schaltkreise sowie Schienenverkehr vieles am bearbeiten bin, würde die Seite Physikalische Mechanismen ca. 2 Monate oder noch länger so verweilen wie sie grade ist. Deshalb wäre ich dem jenigen dankbar, wenn er diese Seite übernehmenen würde, da auf dieser Seite keine Animationen benötigt werden wie bei den anderen beiden, würde ich auch behaupten das diese leichter zu bearbeiten ist. Askon (Diskussion) 12:18, 15. Jun. 2014 (UTC)

Wir haben eine eigene Seite für Projekte, wo sie vorgestellt werden. Du hast mit einer kleinen Diskussion begonnen und nur die Seite "Redstone-Schaltkreise" verbessert. Ohne weitere Vorstellung eines Konzeptes wurde da aber immer mehr reingepackt und nun heißt das ganze "Megaprojekt". Uff. Ich habe längst den Überblick verloren, was aus der Änderung der Seite "Redstone-Schaltkreise" geworden ist und hoffe, du hast ihn noch. Im Rahmen der Arbeit an den "Redstone-Schaltkreisen" kam auch der "Schienenverkehr" mit dazu. Als ich vorschlug, den bei den "Redstone-Schaltkreisen" zu integrieren, erfuhr ich von dir, dass da größeres geplant sei. Ui! Aber was eigentlich? Wie groß? Und sind die "Redstone-Schaltkreise" jetzt fertig? Offenbar nicht, wie du sagst. Und irgendwie hast du dann mit "Physikalische Mechanismen" angefangen. Wieder ohne Projektvorstellung. Jetzt erfahren wir, dass das ein drittes Megaprojekt ist. Ächz. Hast du vor, die restlichen Anleitungen dort zu bündeln? Gibt es danach überhaupt noch Anleitungen? In der Einleitung schreibst du, das sind "Kombinationen von Komponenten", aber gibt es eigentlich auch "nicht-physikalische Mechanismen"? Du hast jetzt vorgeschlagen, dass du erst einmal die "Redstone-Schaltkreise" und den "Schienenverkehr" fertigstellst. Das finde ich prima und gut überlegt. Das Projekt "physikalische Mechanismen" würde ich zurückstellen (nach dem Motto "eins nach dem anderen") und dann, wenn es in ca. zwei Monaten soweit ist, von dir nochmal gerne vorgestellt haben, damit wir alle verstehen, was deine Idee dabei ist. -- Sumpfhütte 12:58, 15. Jun. 2014 (UTC)

Ok dann beschreibe ich am besten mal den Stand der Dinge und was ich mir dabei gedacht habe. Redstone-Schalkreise ist fast fertig. Das bedeutet, alle Komponenten des Rechners werden noch von mir fertiggestellt. Danach ist Redstone-Schaltkreise fertig. Je mehr ich aber die Seite Redstone-Schalkreise unter Bearbeitung nahm, umso mehr konnte man immer besser zwischen Redstone-Mechanismen und Nicht-Redstone-Mechanismen unterscheiden. Deshalb gibt es jetzt auch eine Seite die diese Mechanismen beinhaltet -> Physikalische Mechanismen.

Der Schienenverkehr soll von meiner Seite aus alle Komponenten eines Bahnhofes beinhalten, Eingleisig wie auch Zweigleisig und wegen dieser Größe soll es auch eine eigene Seite sein. Weil ich aber festellen musste, dass der Schienenverkehr nicht vollständig auf Redstone-Schaltkreise basiert, verstärkt es die Beanspruchung einer eigenen Seite nochmals. Deshalb bin ich übergegengen und habe den Schienenverkehr als Hybriden Mechanimsus dargestellt. Sind damit alle Fragen bezüglich des Schienenverkehrs beantwortet ?

Das mit den Projekten kann ich ja jetzt noch hinzufügen. Wie du selbst sagtes: "aus einer kleinen Diskussion wurde am Ende ein Megaprojekt".

Zum Thema Anleitungen, hier mal eine kleine Übersicht der Dinge die bis jetzt von mir laufen:

Redstone-Schaltkreise soll alle Redstone-Mechanismen beinhalten
Schienenverkehr soll alle Bahnhöfe beinhalten
Physikalische Mechanismen soll alle Mechanismen beinhalten die nichts mit Redstone zu tun haben (Deshalb wäre davon das Gegenteil Redstone-Schalkreise und nicht "Nicht-Physikalische Mechanismen")

Alle anderen Seiten wie Dächer, Innenausstattung oder ähnliches soll weiterhin unter Anleitungen vorhanden sein. Ich habe soweit ich nicht etwas vergessen habe alle Seiten die zu den drei genannten Themen passen aus der Vorlage "Anleitungen" genommen, wodurch im Prinzip der Endzustand der Vorlage Anleitungen schon vorhanden ist.

Sind damit alle Unklarheiten beseitigt ? Askon (Diskussion) 13:26, 15. Jun. 2014 (UTC)

Ja :) Sehr nützlicher Überblick, danke. Ein Projekt hinzufügen brauchen wir vorerst nicht. Ein Wiki-Projekt wird üblichwerweise angelegt, wenn sich mehrere zusammentun, um eine große Aufgabe vorzustellen und umzusetzen. Um "Redstone-Schaltkreise" und "Schienenverkehr" kümmerst du dich aber alleine. Und vielleicht findet sich jetzt auch jemand für die Weiterarbeit an den "physikalischen Mechanismen". Wenn nicht, müssen wir Geduld haben, bis du soweit bist. Aber zumindest wissen wir jetzt, wo die Reise hingeht. -- Sumpfhütte 13:43, 15. Jun. 2014 (UTC)

Ok, wie du mir den Link zu Projekte gezeigt hast, hatte ich gedacht, dass dort alle laufenden Projekte vorzufinden sind, stattdessen kann man dort nur "ständige Projekte" und "erledigte Projekte" finden. Wo findet man den laufende Projekte? Und falls alle laufenden erledigt sind, müsste doch trotzdem so eine Seite oder zumindestens ein Abschnitt davon vorhanden sein, oder?

Und zum Thema Physikalsiche Mechanismen, mir wärs ganz lieb, wenn sich auf jeden Fall einer finden lässt :). Denn wie ich die Seite Redstone-Schalkreise überarbeiten wollte, habe ich nach und nach festgestellt das es doch viel mehr Lücken gibt als ich dachte. So zum Beispiel musste ich viele neue Seiten erstellen, weil es zu den entprechenden Themen noch überhaupt keine gab. Und ich bin ja wie geschrieben immer noch nicht fertig. Ich bin insgesamt seit mehr als einen Monat an dem ganzen dran. Deshalb bin ich auch zum Wort "Megaprojekt" gekommen. Bisher hatte ich noch kein so einschneidendes Thema gehabt was mich so lange daran hinderte die Baustellen-Vorlage wieder zu entfernen ;) . Askon (Diskussion) 14:04, 15. Jun. 2014 (UTC)

Es gibt zur Zeit keine laufenden Projekte. Das letzte war die Umbenennung von "Item", davor .zips Vorlagenprojekt. Beide sind abgeschlossen und stehen unter "erledigte Projekte". Für die Projekte gibt es keine Abschnitte, sondern jedes hat seine eigenen Seiten. Klicke einfach auf die "Projektseite" des jeweiligen Projektes. -- Sumpfhütte 17:35, 15. Jun. 2014 (UTC)

@Sumpfhütte: Ok, also jetzt verstehe ich das so langsam. Aber was ist zum Beispiel hiermit Minecraft Wiki:Projekte/Anleitungen, dieses Projekt ist dort nicht aufgeführt ? Paar Anleitungen fielen in meinen Bereich, deshalb habe ich diese auch schon als "übernommen" makiert. Oder kann es sein das dieses Projekt in Vergessenheit geraten ist ? Askon (Diskussion) 17:55, 15. Jun. 2014 (UTC)

Das Projekt steht als drittes unter "erledigt". Das heißt, dass die Projektseite nicht mehr gepflegt wird. Anhand der Versionsgeschichte sieht man, dass von Mitte 2012 bis Mitte 2013 daran gearbeitet wurde. -- Sumpfhütte 18:06, 15. Jun. 2014 (UTC)

Achso, dann hab ich es übersehn. Nun ja unter ständige Projekte bei Anleitungen steht lediglich "Englische Anleitungen übersetzen, neue erstellen und bestehende aktuell halten". Wäre ja schön wenn dieses Projekt wirklich mal beendet werden würde. Wenn man meine Seiten abzieht bleiben noch sechs Seiten übrig die überarbeitet werden müssten. Da werden sich doch hoffentlich noch paar aktive Leute finden. Askon (Diskussion) 18:21, 15. Jun. 2014 (UTC)

So, ich hab mir die Zeiten für die Bearbeitungen der Seiten nochmals angeschaut und es kommt nicht hin wie ich geplant hatte. Es waren geplant, in ca. zwei Monaten die Seite Redstone-Schaltkreise und Schienenverkehr fertiggzustellen. Nun, jetzt ist der dritte Monat zur Mitte schon abgelaufen und ich bin mit keinen der beiden Seiten vollendens fertig. Wenn ich das von der jetzigen Lage aus beurteile, wird die Seite Schienenverkehr nochmals ca. 1 - 2 Monate verschlingen. Die Seite Redstone-Schaltkreise werde ich jedoch diesen Monat mit großer Wahrscheinlichkeit fertiggestellen. Jetzt bleibt nur die Seite Physikalische Mechanismen auf der Strecke. Ich hab mich jetzt darum bemüht, genau diese Seite auf das gleiche Format zu bringen wie die beiden anderen genannten Seiten. Aber diese Seite wird fürchte ich, nochmals 3 Monate in diesen Zustand bleiben. Deshalb werde ich alle Vorbereitungen treffen, diese Seite in eine ordentliche "Stub"-Seite zu verwandeln. Dann kann jemand, der sich damit befassen möchte, diese Seite fertigstellen. Für mich haben die beiden Seiten (Redstone-Schaltkreise & Schienenverkehr) momentan die höchste Priorität. Askon (Diskussion) 08:42, 16. Jul. 2014 (UTC)

Die baldige Fertigstellung des ungeahnt groß geratenen Projektes "Redstone-Schaltkreise" ist prima! Nicht jeder Autor im Wiki hat diesen langen Atem. Und dein umfangreiches Werk wird ja auch durchaus gelesen, wie man an den Korrekturen und Diskussionen sieht. Die Konzentration auf die Fertigstellung des zweiten Projektes "Schienenverkehr" ist die richtige Entscheidung. Dass sich die "Physikalischen Mechanismen" dafür noch einige Zeit gedulden müssen, ist kein Problem. Viel wichtiger ist, dass du dich nicht verzettelst und weiterhin Spaß an der Erforschung und Dokumentation der Mechanismen hast. Gute Qualität braucht eben seine Zeit :-) -- Sumpfhütte 09:26, 16. Jul. 2014 (UTC)

Das ist natürlich schön, wenn es so gewertschätzt wird. Nun ja, und nun muss ich leider mitteilen, dass sich viele Redstone-Fallen noch in den Unterseiten von "Physikalische Mechanismen" befunden hatten. Ich kann die ja nicht einfach restlos löschen um schneller fertig zu werden. Deshalb werde die dann auch noch fertiggestellen müssen, wenn ich die Redstone-Schaltkreise zu Ende bringen will. Ordnung hat halt seinen Preis. Jedoch ist die Seitenhierarchie nun so übersichtlich und klar wie nie zuvor. Askon (Diskussion) 09:46, 16. Jul. 2014(UTC)

Jetzt ist ja wieder einige Zeit vergangen und es hat sich inzwischen auch einiges geändert. So wollte ich fragen, ob sich paar Autoren bereiterklären bei der Seite Physikalische Mechanismen mir eine wenig zu helfen? Die Seite ist in keinen schönen Zustand, sie wird vorraussichtlich weitere 3 Monate so bleiben wenn alles so läuft wie bis jetzt. Ich würde das jedoch gerne beschleunigen, weil ich aber noch mitten im bearbeiteten von der Seite Schienenverkehrsanlagen bin, wird das nicht leicht werden. Mein Vorschlag wäre, ich stelle Bilder und Animationen bereit und die jenigen die mir helfen können/ wollen, könnten dann die Texte verfassen. Mein Ziel wäre es diese Seite schneller fertig zu bekommen als es vom Zeitplan gehen würde (1 Autor braucht länger als viele). Wie wärs ? Oder wäre es besser das ganze in einem Projekt zu eröffnen ? Askon (Diskussion) 18:45, 24. Aug. 2014 (UTC)

@Askon: Ich kann mal drauf schauen und überarbeiten, was mir auffällt/einfällt. Allerdings weiß ich nicht genau, was du dir da schon für Gedanken gemacht hast. --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 20:26, 24. Aug. 2014 (UTC)

@.zip: Erstmal danke, dass du bereit wärst zu helfen. Der Ist-Zustand der Seite ist auch der Ist-Gedankenzustand von mir. Ich hab alles was ich finden konnte in diese Seite eingebunden, es müssten halt die Texte aktualisiert werden und die Bilder dazu ein wenig aufgefrischt werden. Askon (Diskussion) 21:06, 24. Aug. 2014 (UTC)

Gibt es eine Möglichkeit bestimmte Texte auszublenden, wenn diese durch das ausklappen als Unterseite besser verborgen sein sollten ? Askon (Diskussion) 16:24, 6. Sep. 2014 (UTC)

Ich denke, <noinclude> sollte da helfen. | violine1101^(Diskussion) 17:22, 6. Sep. 2014 (UTC)

Danke, ich probiere es demnächst mal aus. Askon (Diskussion) 17:29, 6. Sep. 2014 (UTC)

Minecraft für die Wii U

Minecraft wird für Wii U kommen . Mehr ist aber nicht bekannt. -- 21:33, 24. Jun. 2014‎ 83.99.102.176

Zitat: "Erscheint der Indie-Megaseller Minecraft womöglich auch für Nintendo Wii U? Die Kollegen von NintendoEnthusiast behaupten genau das. Demnach soll Minecraft gleichzeitig auf allen drei Next Gen-Konsolen, also auf PS4, Xbox One und Wii U, im Sommer 2014 erscheinen..." (mehr). -- Sumpfhütte 19:44, 24. Jun. 2014 (UTC)

Solange es von Mojang kein offizielles Statement gibt, würde ich sagen, dass wir das vorerst nicht ins Wiki aufnehmen. Notch hat darüber bereits vor einem halben Jahr getwittert:

	“	I am not aware of any plans to release a Wii U version of Minecraft.	„
		~ Notch bezüglich des Gerüchtes über eine Wii U-Version von Minecraft (Quelle)

	“	I agree a Wii U version would make sense, btw. The only reason for no current plans is we've got too much work already. I <3 Nintendo.	„
		~ Notch bezüglich des Gerüchtes über eine Wii U-Version von Minecraft (Quelle)

Übersetzung: "Ich bin mir keiner Pläne, eine Wii-U-Version von Minecraft zu veröffentlichen bewusst. / Ich stimme übrigens zu, dass eine Wii-U-Version sinnvoll wäre. Der einzige Grund für keine derzeitigen Pläne ist, dass wir bereits zu viel Arbeit haben. Ich <3 Nintendo." | violine1101^(Diskussion) 20:31, 24. Jun. 2014 (UTC)

Das wäre ja echt lustig, wenn es dann doch eine Wii U Minecraft Version geben würde. Askon (Diskussion) 20:56, 24. Jun. 2014 (UTC)

Du hast völlig recht violine1101. Einen Artikel kann es erst geben, falls es konkret werden sollte. -- Sumpfhütte 21:24, 24. Jun. 2014 (UTC)

Änderung des Wiki-Layouts (Blaue Streifen zu braune Streifen)

Hallo zusammen,
resultierend aus dieser Diskussion http://minecraft-de.gamepedia.com/Diskussion:Minecraft_Wiki#Video_auf_der_Startseite habe ich hier: http://minecraft.gamepedia.com/Minecraft_Wiki_talk:Community_portal#New_texture_for_blue_bars_and_boxes.3F die Änderung der blauen Balken im Wiki in Balken mit Erd-Textur vorgeschlagen. Leider gab es im englischen Wiki keine allzu große Zustimmung. Nachdem ich hier nochmal darauf hingewiesen habe, ist leider auch nichts mehr passiert. Vielleicht ist ein Post aber auch untergegangen. Deswegen hier nochmal: Bitte beteiligt euch bei der Diskussion im englischen Wiki, wenn ihr für eine Änderung des Layouts seid. Gruß --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 21:39, 7. Aug. 2014 (UTC)

Blockbilder umbenennen

Jetzt bei den letzten Änderungen bezüglich der Zäune, Zauntore und den Türen ist aufgefallen, dass es kein richtiges System bei den Bilddateien gibt. So sind einige englisch und andere deutsch benannt. Dann kommt hinzu, wenn sich eine Textur im Laufe der Zeit geändert hat, besitzt sie nicht gute oder ersichtliche Bezeichnungen. So zum Beispiel hat der Setzling im Laufe der Zeit viele verschiedene Texturen besessen und jedes Mal muss dann die Textur umbenannt werden und die neue muss die alte Textur überschreiben.

Mein Vorschlag wäre folgender:

1. Alle Bilddateien übersetzen. (Beispiel: wooden door -> Eichenholztür)
2. Geänderte Texturen mit einer Nummer markieren (Beispiel: Setzling Alt; Setzling -> Setzling1; Setzling2)

Askon (Diskussion) 12:01, 10. Aug. 2014 (UTC)

Alte Texturen werden häufig in der Geschichtsbox angezeigt. Ich würde bei einem Texturenwechsel die bisherige Textur verschieben nach <Name><Minecraftversion> z.B. "Eichenholztür bis 1.7.10" und die neue unter dem bisherigen Namen hochladen, also "Eichenholztür". -- Sumpfhütte 12:26, 10. Aug. 2014 (UTC)

Guter Vorschlag, dann könnte man auch erkennen wann die Textur nicht mehr aktuell war. Wie kann man allgemein so einen großen Prozess jetzt bewältigen ? Ein Projekt aufmachen oder einen Bot alle Texturen umbenennen lassen ? Askon (Diskussion) 12:31, 10. Aug. 2014 (UTC)

Hast du eine Idee, wie man die betroffenen Fälle allgemeingültig erkennen kann? Oder hast du sogar schon eine Liste der betroffenen Fälle? -- Sumpfhütte 13:16, 10. Aug. 2014 (UTC)

Allgemein hatte ich bisher die Dateien bei denen es andere Texturen gab immer in deutsch gehalten und diese dann "Alt" genannt. Wenn es aber mehrere gab hab ich dahinter eine mir bekannte Version hinten angestellt bei der die Textur noch genutzt wurde. Man müsste also allen Dateien mit den Enden "Alt" finden und die noch weiter zurückligenden Texturen sollte meines Wissens alle mindestens auf einer Seite in der Geschichtsbox zu finden sein. Eine Liste hab ich nicht erstellt. Askon (Diskussion) 13:21, 10. Aug. 2014 (UTC)

Umbenennungen mit 1.8

Mit dem nächsten Sprachpaketupdate (vermutl. mit Vollversion 1.8 oder einem Pre-Release) kommt wieder etwas Umbenennung auf uns zu. Ich sammel hier schon mal, was alles geändert werden sollte (bitte ergänzen, wenn was fehlt):

Spinnweben → Spinnennetz
Bruchsteine → Bruchstein (auch bemoost)
(evtl. Meerestempel → Ozeanmonument, Verlassene Mine → Mine und Endermite → Endermilbe; Diskussionen/Abstimmungen laufen noch)

Dazu kommen Beschriftungen im Menü (z.B. bei den Einstellungen der Angepassten Welt, Skin, ...). Bei Gelegenheit könnten später auch noch die Rezepte der Banner an die internen heraldischen Bezeichnungen angepasst werden (.zip ist da Experte ;)). -- Elike98 ^Diskussion 14:38, 25. Aug. 2014 (UTC)

@Elike98: Um das nochmal deutlicher zu machen. Spinnweben und Bruchsteine werden sich definitiv ändern, da die aktuellen Namen falsch sind. Beim roten Sandstein/Meerestempel sowie der Mine/Minenschächte/Verlassene Mine und einigen anderen Übersetzungen laufen noch Abstimmungen/Diskussionen. --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 15:05, 25. Aug. 2014 (UTC)

Jep. Eins ist mir gerade noch aufgefallen: hier wurde noch Pyramide → Wüstentempel vorgeschlagen. -- Elike98 ^Diskussion 15:16, 25. Aug. 2014 (UTC)

Ich schlage übrigens die Übersetzung Meerestempel → Meerespalast vor, da "Monument" in meinen Augen eher ein Denkmal ist und kein tempelähnliches Gebäude. Ich habe die oben genannte Übersetzung auf Crowdin vorgeschlagen. | violine1101^(Diskussion) 16:20, 25. Aug. 2014 (UTC)

Es gibt nochmal was: Der Mezger wird vermutlich in ~~Schlachter~~Fleischer umbenannt. Das entsprechende Haus in den Dörfern müsste dann in ~~"Schlachthaus"~~ "Fleischerei" oder ähnliches umbenannt werden.

~~Der goldene Apfel hat in Crowdin durch den entsprechenden Erfolg einen String und wird vermutlich "Notch-Apfel" heißen.~~

Beobachtermodus --> Zuschauermodus --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 08:15, 31. Aug. 2014 (UTC)

Wenn schon, dann "Schlachterei" (butcher shop), nicht "Schlachthaus" (slaughterhouse), das wäre zu groß für das Dorf. In der Wikipedia heißt der Beruf übrigens "Fleischer", das Haus wäre dann eine "Fleischerei". Wikipedia: "Der Fleischer (üblich in Mittel- und Ostdeutschland), auch Metzger (Süd- und Südwestdeutschland, Nordrhein-Westfalen, Schweiz, Westösterreich), Schlachter beziehungsweise Schlächter (Norddeutschland), Fleischhauer (Österreich), Fleischhacker (Ostösterreich) und Knochenhauer (veraltet) ist einer der älteren Handwerksberufe." -- Sumpfhütte 08:40, 31. Aug. 2014 (UTC)

Ich muss mich entschuldigen. Metzger wird vermutlich in Fleischer umbenannt. Ich habe es oben korrigiert. --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 09:14, 31. Aug. 2014 (UTC)

Testmodus --> Debug-Modus --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 14:01, 2. Sep. 2014 (UTC)

Nicht zu vergessen: Bruchstein. | violine1101^(Diskussion) 16:42, 2. Sep. 2014 (UTC)

~~Seelaterne --> Meereslaterne~~ -- Kumasasa (Diskussion) 16:49, 2. Sep. 2014 (UTC) -- Im Spiel heißt sie "Seelaterne" (was imho auch prima zu "Seefahrt" passt) -- Sumpfhütte 21:28, 2. Sep. 2014 (UTC)

Ja. Siehe Diskussion unter https://crowdin.com/translate/minecraft/9380/enus-de#5154019 -- Kumasasa (Diskussion) 10:07, 3. Sep. 2014 (UTC)

Ich sammle mal:

~~Spinnweben --> Spinnennetz (Manuell, Aufzählung durch Bot)~~
~~(Bemooste) Bruchsteine --> (Bemooster) Bruchstein (Manuell, Aufzählung durch Bot)~~
~~Meerestempel --> Ozeanmonumente(Manuell, Aufzählung durch Bot)~~
~~Verlassene Mine --> Mine(Bot? Falls Möglich, dabei entstehende Links [[Mine|Mine]] -->[[Mine]])~~
~~Endermite --> Endermilbe (Bot?)~~
Dorfbewohner/Häuser anpassen (Fleischer, Bauer, Geislticher) (Bot?)
~~Beobachtermodus --> Zuschauermodus (Bot?)~~ Erledigt. Kumasasa (Diskussion) 10:10, 3. Sep. 2014 (UTC)
~~Testmodus --> Debug-Modus (Bot?)~~
Pyramide --> Wüstentempel? (Manuell, Aufzählung durch Bot)

Dahinter habe ich jeweils die Art der Durchführung geschrieben, die ich annehme. Falls etwas doch (nicht) per Bot geht bitte melden. @CalebBlackhand: Auf deinen Bot dürfte dann wohl etwas Arbeit zukommen :) --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 21:49, 2. Sep. 2014 (UTC)

Dann stell ich mal den Wecker für die Schlafmütze von Bot, nachdem der letztens einfach so pennen gegangen ist. Wenn er wieder wach ist (und ich auch ;)) schau ich mir die Mengengerüste mal an. --Caleb Blackhand 22:15, 2. Sep. 2014 (UTC)

Sodale. Unter Benutzer:CalebBot/Arbeitsauftrag trudeln so langsam die ersten Listen ein. Kleine Anmerkung: Das ist nur und ausschließlich BNR, Vorlagen etc. müsste ich noch separat suchen. --Caleb Blackhand 14:10, 3. Sep. 2014 (UTC)

Der Bot hat dann noch nach Metzger, Farmer und Priester gesucht - nach den jeweiligen Häusern suche ich jetzt nicht separat, die sollten im Zusammenhand erwähnt sein, hoffe ich. Fehlt sonst noch was? --Caleb Blackhand 09:53, 5. Sep. 2014 (UTC)

Gemeinschafts-Portal oder Gemeinschaftsportal

Hallo zusammen,
zwar eine Kleinigkeit, trotzdem frage ich mal nach eurer Meinung. In der Sidebar wird "Gemeinschaftsportal" geschrieben. Die Seite heißt allerdings "Gemeinschafts-Portal". Die zusammengeschriebene Variante gefällt mir pesönlich besser. Wie seht ihr das? Link anpassen oder Seite umbenennen? --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 12:16, 27. Aug. 2014 (UTC)

Wegen des Genitivs könnte es sein, dass "Gemeinschaftsportal" sowieso die einzig richtge Variante ist, oder? Anders z.B. bei "Nether-Portal" oder "Wiki-Admin". Was sagt Sebastian Sick dazu? -- Sumpfhütte 13:00, 27. Aug. 2014 (UTC)

Ich persönlich finde "Gemeinschaftsportal" viel schöner als auseinander geschrieben. -- Elike98 ^Diskussion 13:10, 27. Aug. 2014 (UTC)

+1 für Gemeinschaftsportal! Suchti ^{Diskussion Mail} 18:33, 27. Aug. 2014 (UTC)

@Sumpfhütte, Elike98, Suchti: Das ist jetzt relativ eindeutig. Am einfachsten wird es sein, @CalebBlackhand:s Bot damit zu beauftragen. Wäre das möglich Caleb? --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 15:02, 30. Aug. 2014 (UTC)

Trivial, also 'Ja'. Sind halt nur einige Diskussionsseiten. Ich muss mal testen, ob Bots mit "Kleinigkeiten"-Edits die Benachrichtigung auslösen oder (wie in der Wikipedia) grade nicht. --Caleb Blackhand 18:49, 30. Aug. 2014 (UTC)

@CalebBlackhand: Die Gefahr dürfte eigentlich nicht bestehen, da Benachrichtigungen nur abgeschickt werden, wenn eine Signatur gesetzt wurde. Bei den Diskussionsseiten sollten auch nur die Links geändert werden, um den ursprünglichen Text jedes Autos gleich bleiben zu lassen. Wenn das geht. Wenn nicht, mache ich das per Hand. --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 07:59, 31. Aug. 2014 (UTC)

Ich kenn dieses Benachrichtigungssystem ned so gut, aber ich glaub dir einfach mal ;) Die Ersetzung geht, ich lass die Benutzerdisks unabhängig von den anderen Seiten laufen. Kein Problem. Heute Abend vermutlich. --Caleb Blackhand 09:05, 31. Aug. 2014 (UTC)

@CalebBlackhand: Hmm. Ich habe eine Nachricht, ausgelöst durch deinen Bot bekommen. Das heißt also, es reicht, wenn eine Signatur vorhanden ist. Sie muss nicht neu gesetzt werden. Na ja. Dann haben jetzt halt ein paar Leute eine Nachricht bekommen. :) --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 14:35, 1. Sep. 2014 (UTC)

Und das, obwohl der Bot extra "kleine" Änderungen macht und (laut Spezial:Gruppenrechte) das Recht nominornewtalk hat. Na ja. Ärger ich halt mit dem Bot ein paar Hundert User. --Caleb Blackhand 14:37, 1. Sep. 2014 (UTC)

Zwischenbericht: Minecraft Wiki Diskussion:Gemeinschaftsportal ist vollständig entlinkt, und an den Links auf Minecraft Wiki:Gemeinschaftsportal arbeitet der Bot grade. Alles nur noch Benutzerdisk. --Caleb Blackhand 14:48, 1. Sep. 2014 (UTC)

Und auch das ist erledigt. Der Bot geht wieder schlafen ;) --Caleb Blackhand 15:40, 1. Sep. 2014 (UTC)

@CalebBlackhand: Super, Dankeschön! --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 15:43, 1. Sep. 2014 (UTC)

Partnerschaft mit unlimitedworld.de und endlich wieder ein Wiki-Server!

Hallo zusammen,

wie ihr vielleicht schon mitbekommen habt, haben wir seit gestern einen neuen Partner und endlich wieder einen Wiki-Server! Zusammen mit dem Team von unlimitedworld.de haben wir in den letzten Wochen ein Konzept ausgearbeitet und umgesetzt.

Wer auf dem Wiki-Server spielen möchte, kann im Spiel den Befehl /wiki verwenden, der zum Wiki-Artikel des Blockes verlinkt, den man gerade anschaut oder des Gegenstandes, den man in der Hand hält oder zu einem beliebigen eingebbaren Artikel.
Wer nicht auf dem Wiki-Server spielen möchte, aber Fragen zu Minecraft (und nicht speziell zum Wiki) hat, kann sie im Wiki-Forum stellen, wo Wiki-Autoren und -Admins antworten.
Wiki-Autoren haben im Wiki-Forum einen speziellen Rang, der von der Anzahl ihrer WikiPunkte abhängt.
Redstone-Fans, die schon Askons umfangreiche Überarbeitung der Schaltkreis-Artikel geschätzt haben, können die Schaltungen, die im Wiki abgebildet sind, zusammen mit Freunden auf dem Redstone-Schaltkreisserver untersuchen. Um Unfug zu verhindern, ist für den Zugang eine Anmeldung bei den Server-Admins notwendig.
Völlig ohne Anmledung kann auf dem Testserver immer die neueste Minecraft-Entwicklungsversion getestet werden.
Um eure Zugehörigkeit zum Wiki-Server zu zeigen, könnt ihr Vorlage:Babel Unlimitedworld verwenden.

Auch in Zukunft werden die beiden Teams zusammenarbeiten um dieses Projekt auszuweiten. Wir freuen uns schon daruaf, was kommen wird. Wünsche und Ideen sind immer gern gesehen. Detailliertere Informationen bekommt ihr unter unlimitedworld.de/wiki.php. --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 10:14, 1. Sep. 2014 (UTC)

Zukünftige Versionen

Da ich diesen Text leider nicht in die Diskussion zur Hauptseite hinzufügen konnte,schreibe ich diesen hier hinn.

Wie währe es ,wenn ihr unter die Zeile : Launcher= 1.5.2 einfach Zukünftige Versionen = 1.8.x drannhängt ,oder zumindest einen Link zur 1.8-Seite.Vielleicht könntet ihr dann bei den Neuigkeiten auch das Release-Datum angeben falls es fest steht.

Z.B.

Neuigkeiten:

01.09.14- Mojang kündigte das Update 1.8 für den voraussichtlichen 02.09.14 an.

77.8.12.212 12:26, 1. Sep. 2014 (UTC)

Gute Idee! Auf den Artikel zu 1.8 kann so direkt zugeriffen werden, ohne den Umweg über die Entwicklungsversionen, an denen nicht unbedingt jeder interessiert ist. -- Sumpfhütte 14:34, 1. Sep. 2014 (UTC)

1.8-Markierungen entfernen

Liebe Autoren!

Wie ihr wisst, werden Minecraft -Neuerungen immer sofort in den passenden Artikel geschrieben. Früher wurden sie dazu mit einem Satz eingeleitet wie "Seit Beta 1.4 kann man...". Diese Texte stehen teilweise heute noch in den Artikeln, was unschön ist.

Daher haben wir für die 1.8 alle Neuerungen mit zwei Vorlagen markiert:

{{Entwicklungsversion}} bzw. {{Snapshot}}
{{Änderung}} bzw. {{ä}}

Diese Vorlagen machen einen Eintrag in der Kategorie:Zukunft. Über diese Kategorie finden wir also sämtliche Artikel mit einer solchen Vorlage und können sie wieder entfernen.

Aber bitte nicht einfach rauswerfen. Wer sie einfach nur rauswirft und dabei besonders schnell sein will, verursacht nur Mehrarbeit für die anderen. Oft müssen Sätze, Rezepte oder ganze Abschnitte an die richtige Stelle im Artikel verschoben werden. Dies bitte sorgfältig prüfen und dabei ruhig Zeit lassen. Je weniger nachgebessert werden muss, desto besser ist es. Danke schön :-) -- Sumpfhütte 08:55, 2. Sep. 2014 (UTC)

Ich habe die Texte der beiden Vorlagen etwas angepasst, um Verwirrungen in der Umstell-Zeit zu vermeiden. Sobald eine neue Entwicklungsversion erscheint bzw. der Umbau fertig ist, sollte man wieder die alten Hinweise verwenden. -- Elike98 ^Diskussion 12:01, 2. Sep. 2014 (UTC)

Was war das? Ein Vogel? Ein Flugzeug? Nein, Super-Caleb und die Wiki-Liga sind durchs Wiki gerauscht und haben in 9 Stunden das gesamte Wiki auf die Version 1.8 gehievt. Mit Hinterhergucken (es waren ziemlich genau 500 Änderungen) bin ich jetzt 2 Stunden später auch am Ende angekommen. Meine Vorlagen "Änderung" und "Menü" haben sich hervorragend bewährt und die Umstellung sehr beschleunigt. Ansonsten würden wir jetzt noch an der Abarbeitung einer Bot-Liste sitzen, die nach "Ab Version 1.8" gesucht hätte, und am Ausschneiden von Menü-Buttons. Ich bin von der Geschwindigkeit, in der diese enorme Arbeit bewältigt wurde, schwer begeistert! Vielen Dank euch allen! -- Sumpfhütte 20:32, 2. Sep. 2014 (UTC)

Falsches Neuigkeiten Datum

Seid ihr euch sicher das die 1.8 am 09.09.14 Rausgekommen ist ? Ps: Ist Nett Gemeint ;) --46.114.12.35 15:13, 2. Sep. 2014 (UTC)

Nö, des war ein Typpföhler, und was für einer. Danke für's Aufpassen, hat wieder mal keiner gesehen ;) --Caleb Blackhand 15:17, 2. Sep. 2014 (UTC)

Zeitreise

5 Jahre Minecraft-Entwicklung als Welt aufgebaut, an der 6:20 Minuten lang vorbeigezogen wird => Guckst du hier: Minecraft-Zeitreise-Video. -- Sumpfhütte 15:05, 3. Sep. 2014 (UTC)

Twitter: Von IPs angelegte Seiten

Ich finde, von IPs angelegte Seiten sollten nicht getwittert werden. Es war jetzt, seitdem der Wiki-Twitter existiert, immer (oder zumindest oft) der Fall, dass diese Seiten kurz nach dem Tweet gelöscht wurden. Ist das technisch möglich? | violine1101^(Diskussion) 18:02, 5. Sep. 2014 (UTC)

@ILeonx: das würde ich auch gerne wissen. -- Sumpfhütte 19:11, 5. Sep. 2014 (UTC)

Ich frag jetzt mal nach.

ILeon ᐸ Diskussion
Beiträge - de.Wiki Admin 19:39, 5. Sep. 2014 (UTC)

Ist leider nicht möglich.

ILeon ᐸ Diskussion
Beiträge - de.Wiki Admin 20:06, 5. Sep. 2014 (UTC)

Was ich mich bei der ganzen Sache frage ist, warum IPs überhaupt Seiten anlegen dürfen ? Sollten das denn nicht besser nur Benutzer dürfen ? Askon (Diskussion) 16:04, 6. Sep. 2014 (UTC)

Das ist die Philosophie des Wikis und wird in allen Minecraft Wikis so gehandhabt. Unnütze Seiten werden durch die Admins wieder entfernt. Das Problem ist alleine ein Problem des automatischen Twitterns, was es nur im deutschen und französischen Wiki gibt. ILeon hat ja dort nachgefragt und die scheinen offenbar einfach mit solchem Unsinn zu leben. Mir gefällt es jedoch auch nicht, wenn jeder x-beliebige anonyme Benutzer nur eine Seite mit z.B. "Hallo Omi" anlegen muss, um dies automatisch im Namen des Minecraft Wikis an 600 Leute zu twittern. @CalebBlackhand: Vielleicht hast du eine Idee, ob und wie man neue Seiten von anonymen Usern beim automatischen Twittern ignorieren kann. ILeon benutzt https://ifttt.com/wtf zusammen mit diesem Wiki-Feed. -- Sumpfhütte 08:22, 7. Sep. 2014 (UTC)

Man kann aber dennoch die getwitterten Nachrichten wieder löschen ? Dann könnte man solange das Problem an sich nicht behoben wurde, wenigstens die unnützen Nachrichten verschwinden lassen. Askon (Diskussion) 09:02, 7. Sep. 2014 (UTC)

Ich wüsste einen "Trick": Wir erstellen einen "Missbrauchsfilter" (nur für Admins einsehbar, sorry), der neue Artikel von angemeldeten Benutzern markiert (nur markiert, sonst nichts - also absolut unauffällig). Die Markierung wäre z.B. 'Tweetbare_Neuanlage' oder so etwas. Und auf diese Markierung kann man dann im Feed filtern. (Wenn man aus der Feed-URL das 'feed=atom' rauslässt, bekommt man die entsprechende Spezialseite, kann alles wünschenswerte einstellen und hinterher den feed wieder in die URL schreiben).

Direkt ohne einen Markierungs-Filter geht es leider nicht - ich kann in dem Feed nur die angemeldeten Benutzer und die Bots (selbst auch angemeldete Benutzer) ausblenden, nicht aber die anonymen IP-Editoren. --Caleb Blackhand 09:09, 7. Sep. 2014 (UTC)

@CalebBlackhand: Das sieht doch gut aus. --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 14:38, 7. Sep. 2014 (UTC)

@CalebBlackhand: Ich verwende jetzt dieses Wiki-Feed. Ist das richtig so? :)

ILeon ᐸ Diskussion
Beiträge - de.Wiki Admin 18:58, 7. Sep. 2014 (UTC)

Wenn mein mit der heißen Nadel gestrickter Filter tut, was er soll (getestet hast du ihn, ned ich ;) ) dann ja, würde ich sagen. Funktioniert ja auch schon. --Caleb Blackhand 21:41, 7. Sep. 2014 (UTC)

Yay! - und Danke! -- Sumpfhütte 09:55, 8. Sep. 2014 (UTC)

Versionsgeschichte aller Minecraft Editionen

Momentan sind in den meisten Artikeln nur die Versionsgeschichten der PC-Version und der Pocket Edition vorhanden. Das heißt Xbox 360, Xbox One, PS3, PS4, PSVita und Pi fehlen. Als Wiki sollten wir aber alle Versionsgeschichten einbauen. Wenn wir jetzt aber für jede Edition einen eigenen Kasten einbauen, wirkt der Artikel viel zur Überladen mit Vorlagen. Gibt es irgendwelche Vorschläge? ILeon ᐸ Diskussion
Beiträge - de.Wiki Admin 12:46, 6. Sep. 2014 (UTC)

@ILeonx: Jede Versionsgeschichte mit Vorlage:Lade Inhalt manuell einzublenden bzw. die Vorlagen untereinander (eingeklappt) anzuzeigen geht immer. Aber vielleicht schaffen wir es, ein schickes Menü zu erstellen, das je nach Auswahl automatisch eine Versionsgeschichte anzeigt und die anderen ausblendet? Man könnte auch die Länge der bisherigen Boxen halbieren, dass jeweils zwei nebeneinander passen. --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 13:07, 6. Sep. 2014 (UTC)

Ich glaube, es gibt nur 3 Versionsgeschichten: PC, PE (Android + iOS) und Konsolen (Xbox 360 und One, PS 3 und 4). -- Sumpfhütte 13:34, 6. Sep. 2014 (UTC)

Stimmt nicht ganz. PC, PE (Android + iOS), Konsolen und Pi.

ILeon ᐸ Diskussion
Beiträge - de.Wiki Admin 13:37, 6. Sep. 2014 (UTC)

Ach ja, die Pi Edition. Hm - die wird aber im Gegensatz zu den anderen zur Zeit nicht weiter entwickelt. Auf jeden Fall haben wir nicht vier Konsolengeschichten, sondern nur eine, d.h. wir bräuchten erstmal nur eine weitere Box, die wir in den Artikeln nach der PE-Box einfügen. Wir könnten dann PE und Konsole initial einklappen. Wie wäre das? -- Sumpfhütte 13:57, 6. Sep. 2014 (UTC)

Soweit ich weiß, basiert die Pi Edition auf einer Version der Pocket Edition, wenn sie nicht sogar dieser Version gleicht. Außerdem gibt es nur eine Pi-Version (0.1.1 kann man ignorieren, da sie nur Bugfixes enthielt). Von daher braucht man eigentlich keine Geschichtsbox für die Pi Edition. | violine1101^(Diskussion) 14:07, 6. Sep. 2014 (UTC)

Das sehe ich genauso. Also bräuchten wir erstmal nur eine weitere Geschichtsbox für die Konsoleneditionen. -- Sumpfhütte 15:05, 6. Sep. 2014 (UTC)

Wäre es eurer Meinung nach möglich und vor allem sinnvoll, die Versionsgeschichten der Konsoleneditionen auf eine Seite zu bringen? Zur Zeit sind sie getrennt. | violine1101^(Diskussion) 18:30, 7. Sep. 2014 (UTC)

@ILeonx, Sumpfhütte, Violine1101: Wenn ich das richtig sehe, sind die Versionsgeschichten nicht vollkommen identisch. Das letzte Update der PS3-Edition und der Xbox 360 Edition ist da ein gutes Beispiel: Die Fehlerkorrekturen betreffen nicht immer beide Editionen und bei der PS3-Edition wurden Texturenpakete hinzugefügt. Das alles auf einer Seite zu sammeln könnte etwas unübersichtlich werden, da z. B. auch die Daten der Updates und die Versionsnummern nicht übereinstimmen. Des Weiteren fängt die Versionsgeschichte der PS3-Edition mit dem TU12 an, während es bei der Xbox 360-Edition das TU 1 ist. Ob die neuen Editionen simultan geupdatet werden, wird sich auch erst noch herausstellen. Deswegen kann es schon möglich sein, dass wir mehrere Geschichtsboxen benötigen werden. --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 21:19, 7. Sep. 2014 (UTC)

Dann sollte man aber die beiden Pocket Editionen (Android und iOS) auch trennen, die sind schließlich auch nicht vollkommen identisch und werden sogar in unterschiedlichen Sprachen geschrieben (siehe Pocket Edition). Da gibt es Versionen, die es nur für Android gibt, aber die Unterschiede sind wirklich nicht so stark wie bei den Konsoleneditionen. Allerdings sind es wirklich nur feine Unterschiede (bei Pocket und Konsole), also kann man sie auf anderen Seiten in der Geschichtsbox zusammenhalten. | violine1101^(Diskussion) 21:27, 7. Sep. 2014 (UTC)

Eine gemeinsame Konsolen-Versionsgeschichte dürfte doch machbar sein. Die englischen Kollegen machen es ja vor: en:Console_Edition_version_history --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 21:38, 7. Sep. 2014 (UTC)

Übersetzungswunschliste an Curse

Hallo zusammen,
immer wieder fallen mir Abschnitte im Wiki auf, die nicht übersetzt sind. Deswegen habe ich vor, einen kleinen Wunschzettel an Curse zu schreiben, damit das behoben wird. Ich bitte euch deshalb, untenstehende Liste zu ergänzen, falls euch entsprechende Textpassagen im Wiki auffallen. --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 21:23, 9. Sep. 2014 (UTC)

Leiste am oberen Bildschirmrand
Kompletter Curse-Abschnitt unter allen Artikeln
"Minecraft content and materials are trademarks and copyrights of Mojang and its licensors. All rights reserved. This site is a part of Curse, Inc. and is not affiliated with Mojang." Unter allen Artikeln
"Already have a Curse account? Log in with your Curse information" Auf der Registrierungsseite
"Join the Curse Community, it's free. Signing up for a Curse account is fast and easy. Your Curse ID will work on most curse Network sites, and confers many benefits." Auf der Registrierungsseite
Evtl. dauerhafte Werbung auf der Registrierungsseite
Hunde-/Katzenauswahlbildschirm auf der Registrierungsseite (Tooltip)
"Your passwords must match." Bei der Eingabe einer abweichenden Passwortbestätigung
"Fehler bei der Anmeldung Sorry, der Benutzernamen ist bereits vergeben. Bitte einen anderen wählen. Das E-Mail-Adresse wird bereits von einem anderen Konto verwendet." Bei der Eingabe einer bereits verwendeten E-Mail-Adresse
(email) auf Spezial:ConnectStats
Minecraft Wiki:Impressum
Minecraft Wiki:Datenschutz
Friend Request samt Tooltip (Einstellungen)
Profile Comment samt Tooltip (Einstellungen)
Useer, Sysop (Curse-Profil)
Datum und Tooltip (Statistik Curse-Profil)
about a minute ago (Benutzerbeiträge Curse-Profil)

Navboxen für mobile Geräte anpassen

Hallo zusammen,
wie schon mal angedeutet, werden (zumindest bei mir) die Navboxen auf mobilen Geräten sehr unübersichtlich dargestellt. Ich vermute, das wird euch und anderen ähnlich gehen. Um das ganze übersichtlicher zu machen habe ich mir etwas überlegt: Extra Navboxen für mobile Geräte.

height: 0px;
width: 0px;
visibility:hidden;

Mit diesen drei Einträgen in der mobile.css für die Klasse "navbox" werden die normalen Navboxen quasi ausgeblendet. Das Spielchen geht auch umgekehrt, indem man die mobilen Navboxen dann in der normalen CSS ausblendet. Die mobilen Navboxen würde ich dann als Unterseiten der normalen Navboxen anlegen. Ich habe auf meiner Testseite schon mal testweise die Vorlage:Navbox-Mojang für mobile Geräte angepasst, indem ich Vorlage:Navbox durch eine einfache Tabelle ersetzt habe. Gestalterisch kann man da natürlich noch einiges machen, aber das/mein Hauptziel ist erreicht. Die Daten werden nun übersichtlicher angezeigt, ohne dass man scrollen muss. Doppelte Navbox-Vorlagen bedeuten zwar doppelte Pflegearbeit, dafür könnten aber Smartphone-Nutzer die Navboxen verwenden. Da in der mobilen Ansicht alle Abschnitte standardmäßig eingeklappt werden, bräuchten die mobilen Navboxen auf jeden Fall auch einen eigenen Abschnitt, da sie sonst immer in den darüberliegenden Abschnitt rutschen. Was meint ihr zu dem Vorschlag? --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 23:37, 9. Sep. 2014 (UTC)

Statt doppelter Navboxen wäre ich eher dafür, die bestehenden Navboxen so umzubauen, dass sie (abhängig vom Device) unterschiedlich angezeigt werden. Dann würde im Artikel weiterhin nur eine Navbox angezeigt, deren Optik (und ggf. Inhalt) wird dann aber über die CSS-Dateien gesteuert. Auf die Art und Weise bleibt der Wartungsaufwand in den Artikeln derselbe. Zugegebenermaßen wird das bei den Vorlagen mehr als nur etwas komplexer, aber nun ja.... ;) --Caleb Blackhand 06:39, 10. Sep. 2014 (UTC)

@CalebBlackhand: Das ist natürlich geschickter. Willst du dich darum kümmern? --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 09:49, 11. Sep. 2014 (UTC)

Kann ich machen - allerdings (in Ermangelung eines mobilen Geräts) nur über Mobil-Simulatoren. Das Finetuning darf dann jemand anderes.... --Caleb Blackhand 10:09, 11. Sep. 2014 (UTC)

Ausklappen der Gruppierungen in den Letzten Änderungen

Ich habe in den Einstellungen das Gruppieren der Letzten Änderungen aktiviert, seit der Umstellung gestern wird der Ausklapp-Pfeil allerdings nicht mehr angezeigt. Könnte ein Admin bitte die folgenden dafür verantwortlichen Zeilen aus den common.css entfernen? (Der obere Teil mit dem expanded-Pfeil funktioniert zwar noch, ein fast gleich aussehender Pfeil ist allerdings jetzt schon vorhanden, weshalb wir nicht mehr einen eigenen verwenden brauchen)

/* Use vector style arrows for enhanced rc instead of those ones from like 2003 */
.mw-enhancedchanges-arrow.mw-collapsible-toggle-expanded {
    background-image: url(/extensions/Vector/modules/images/open.svg);
}
.mw-enhancedchanges-arrow.mw-collapsible-toggle-collapsed {
    background-image: url(/extensions/Vector/modules/images/closed-ltr.svg);
}

-- Elike98 ^Diskussion 10:34, 11. Sep. 2014 (UTC)

@Elike98: Erledigt --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 10:39, 11. Sep. 2014 (UTC)

Ich hatte grade parallel an dieser Sache gebastelt und in der Hydra.css was eingetragen - kann das wieder weg? (Die Änderungen in der Common waren mir entgangen....) --Caleb Blackhand 10:47, 11. Sep. 2014 (UTC)

@Xzipx: Vielen dank :)

@Caleb: Ja, ich denke schon. Jedenfalls funktioniert es bei mir jetzt wieder, auch wenn ich das Häckchen neben deinem Style entferne -- Elike98 ^Diskussion 10:51, 11. Sep. 2014 (UTC)

Na denn.... ;) Is weg. --Caleb Blackhand 10:54, 11. Sep. 2014 (UTC)

Schriftgröße ändern

Hier sind CSS-Spezialisten gefragt: Seit dem MediaWiki-Update ist in meinem IE10-Browser die Schrift grundsätzlich größer als vorher. Wenn ich im Browser die "Ansicht - Zoom" auf 90% stelle, ist es perfekt. Leider muss ich das für jedes neue Tab machen, das ich öffne. Kann ich das in meiner CSS dauerhaft einstellen? -- Sumpfhütte 09:01, 13. Sep. 2014 (UTC)

@Sumpfhütte: Damit müsste es gehen:

body {
	font-size: "Zahlpx";
}

Mehr Infos gibt es auch hier: http://www.w3schools.com/cssref/pr_font_font-size.asp --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 09:11, 13. Sep. 2014 (UTC)

Klappt prima, danke :-) -- Sumpfhütte 09:55, 13. Sep. 2014 (UTC)

Seiten mit Download-Welten: Handhabung ?

Da ja unsere Seite Redstone-Schaltkreise eine extra Download-Welt anbietet, ist es schwerer diese aktuell zu halten, wenn viele Bearbeitungen bezüglich neuer Schaltkreise vorliegen. Da schon eine neue Unterseite erstellt wurde, welche einen völlig neuen Schaltkreis präsentiert, wollte ich das hier mal besprechen. Da ich momentan die Download-Welt bearbeite und auch für diese zuständig bin, ist das momentan kein großes Problem, wenn neue Schaltkreise von anderen Leuten in Seiten eingearbeitet werden, da ich mir diese dann anschauen, anpasse und dann auch auf die Download-Welt einarbeite. Nur hätte ich gerne irgendein Konzept, wodurch solche Fälle (Unterseite wird von jemanden ohne Ankündigung erstellt) nicht mehr ohne Diskussion eintreten. Es müsste irgendwie so gehandhabt werden, sobald jemand was neues hat, soll dieser es am besten erst mal präsentieren, damit nicht alle zwei Wochen eine neue Schaltung in die Download-Welt eingearbeitet werden muss und sich so die Welt-Version unnötiger aufbläht.

Mir geht es darum, dass nicht wieder so ein Chaos ensteht wie vor der Überarbeitung der Seite Redstone-Schaltkreise. Wie seht ihr das und/oder habt ihr weitere Vorschläge ? Askon (Diskussion) 12:25, 13. Sep. 2014 (UTC)

Hm - Prinzipiell ist ein gerade Wiki eine Informationssammlung, in die jeder schreiben kann und soll. In Einzelfällen kann man das allerdings verhindern, indem die Seite nur für Admins beschreibbar ist, wie z.B. die Hauptseite. Das könnte man auch mit der Redstone-Hauptseite so machen und eine /editcopy anlegen, in die jeder seine neuen Schaltkreisideen eintragen kann. Die zugehörigen Artikel würde weiterhin jeder selber schreiben, nur der Eintrag in die Redstone-Hauptseite würde geregelt werden. Den Übertrag aus der /editcopy würde dann ein Admin vornehmen, wenn du einen entsprechenden Hinweis gibst. -- Sumpfhütte 13:25, 13. Sep. 2014 (UTC)

Ok, dann könnte jeder seine Seiten erstellen und trotzdem versinkt das ganze nicht im Chaos. Ich hab jetzt mal die die Unterseite entsprechend umsortiert. Hier war es noch einfach, ich denke sobald die Welt-Version 1.5 raus ist, wäre eine editcopy wirklich angebracht. Achso, sollte man dann die Originalseite mit der Seiten-Versionsgeschichte als editcopy anlegen, das heißt die Seite Redstone-Schaltkreise nach Redstone-Schaltkreise/editcopy verschieben ? Wäre besser oder ? Askon (Diskussion) 13:36, 13. Sep. 2014 (UTC)

Nicht verschieben, sondern kopieren. Die Seite Redstone-Schaltkreise bleibt, wo sie ist und ist auch als einzige in den Navboxen verlinkt. Auch alle Unterseiten bleiben wie sie sind. Man könnte aber zukünftig keinen neuen Einträge in der Hauptseite machen, wenn sie gesperrt wird. Dafür gibt es dann die Kopie namens Redstone-Schaltkreise/editcopy. -- Sumpfhütte 13:51, 13. Sep. 2014 (UTC)

Sorry, ich hab mich wohl unklar ausgedrückt. Das sollte auch so geschehen wie du geschrieben hast, falls halt die Redstone-Hauptseite verschoben werden würde, wäre dann die neu angelegte Seite das neue Original. Die Unterseiten sollten natürlich so bleiben wie sie sind. Askon (Diskussion) 14:04, 13. Sep. 2014 (UTC)

Mobile Anpassung

Hallo zusammen,
in den letzten Tagen habe ich etwas am CSS-Code rumgespielt, um die Darstellung auf mobilen Geräten etwas zu fixen. Konkret habe ich MediaWiki:Sitenotice mithilfe der Vorlage:Hilfe umstrukturiert. Außerdem habe ich für die mobile Ansicht alles außer den beiden Links ausgeblendet. Einen Teil des mobilen Hintergrundes habe ich hinter die Suchleiste gelegt. Das heißt: Die Sitenotice wird mobil wie am PC in Boxen angezeigt, die sich an Bildschirmbreite und Inhalt anpassen. Es kommt jetzt auch zu keinen Überschneidungen mehr auf der mobilen Seite. Allerdings wird nun der Text, der vormals in einer Zeile angezeigt wurde, auf drei Zeilen aufgeteilt. Die mobile Ansicht weicht nun auch etwas vom englischen Vorbild ab: Der Hintergrund besteht aus zwei untereinander angezeigten Bildern. Einmal der Himmel mit etwas Gras und einmal das dunkle Steinmuster. Ich habe die Datei mit dem Himmel nun hinter die Suchleiste platziert. Das führt nun dazu, dass die Datei nicht mehr komplett angezeigt wird. (Nur der Himmel, Gras fällt weg) Der Effekt, dass das erste Bild und die Graszacken des Inhaltsteils ein Gesamtbild geben, geht dadurch verloren. Mit meinen beschränkten Fähigkeiten bekomme ich leider keinen Kompromiss zwischen Sitenotice und dem Design wie im englischen Wiki, da die Sitenotice alles herunterschiebt und die Suchleiste nicht mehr auf der "Grasdatei" angezeigt werden würde. Jetzt ist die Frage. Nimmt man die Einbußen hin, um auch mobil die Sitenotice anzuzeigen? Oder blendet man sie für mobile Geräte komplett aus, um die Seite korrekt anzuzeigen? --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 14:53, 15. Sep. 2014 (UTC)

Also mich stört die Anpassung der Sitenotice kollossal: Ich kann das Aas seit einiger Zeit nicht mehr ausblenden (das hat nix mit den Änderungen zu tun, ist aber der grund für meinen Unmut), bei jedem Reload kommt die wieder - und nu isse nicht mehr wie früher 1 Zeile hoch, sondern derer 4 (bzw. mit den Abständen eher wie 6). Wenn die so bleibt, blende ich die mit persönlichem CSS aus - so riesig ist gruselig. Bildschirme auf nicht-Mobil-Geräten sind in der Regel eher breit denn hoch, da kann ich wenige lange Zeilen eher verkraften als viele kurze.

Ich persönlich würde sogar das Twitter-Widget gleich ganz entfernen (ich glaub, seit das drin ist klapprt das bei mir mit dem Ausblenden nicht mehr - bin mir da aber nicht so ganz sicher). Der Textlink zu den Tweets reicht IMHO völlig aus, auf Twitter kann man dann immer noch 'Folgen'. --Caleb Blackhand 15:11, 15. Sep. 2014 (UTC)

@CalebBlackhand: Nach meiner letzten Bearbeitung müsste bei der PC-Ansicht eigentlich wieder alles in einer Zeile angezeigt werden. So sieht es auch in der Vorschau aus. Tatsächlich ist die ganze Tabelle aber nicht mehr zu sehen und ich finde den Fehler nicht. Kannst du da vielleicht einen Blick drauf werfen? Der Button zum Ausblenden wird mir angezeigt. Es ist also kein generelles Problem. Momentan wird das Widget ja nicht angezeigt. Kannst du die Sitenotice jetzt ausblenden? Zum generellen Entfernen des Widgets teile ich deine Meinung. Niemand folgt, ohne das Profil anzuschauen (Das würde ich zumindest nicht machen). --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 15:52, 15. Sep. 2014 (UTC)

Das war ziemlich invalides HTML, was da raus kam - Formatierung und Gruppierung bunt gewürfelt. Ich hab mal das Widget entfernt (ohne das geht das Ausblenden tatsächlich wieder) und das Markup aufgeräumt. Bei mir wird's jetzt wieder sauber angezeigt (2 Zeilen, wegen des M$-Hinweises, aber das ist IMHO vorübergehend okay). --Caleb Blackhand 20:54, 15. Sep. 2014 (UTC)

Wie verschiebe ich eine Seite?

Der Menüpunkt zum Seitenverschieben hatte früher einen nichtssagenden Pfeil nach unten, jetzt ist er bei mir ganz leer. Weiß jemand, welche MediaWiki-Systemnachricht das ist, damit ich da eine Beschriftung eintragen kann? (Ich würde "Verschieben" eintragen, auch wenn Admins dort noch andere Unterpunkte haben). -- Sumpfhütte 20:35, 16. Sep. 2014 (UTC)

MediaWiki:Actions. Das ist aber durch "display:none" explizit von irgendwo deaktiviert worden. Vmtl. von Curse. Frag mal bei englischen Kollegen nach. --eagle3000 ^{(D ~ B)} 20:54, 16. Sep. 2014 (UTC)

@Sumpfhütte, Eagle3000: Bitte nicht fragen, einfach machen. Sonst bekommen wir eine Antwort, die negativ für uns ausfallen könnte und uns dann bindet. Ich glaube, dass wir in diesem Fall schon alleine entscheiden können. --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 21:12, 16. Sep. 2014 (UTC)

Aber bitte nicht "verschieben" nennen, nur den Pfeil wieder herzaubern - die Zeile wird sonst verflixt voll (und für Admins wäre 'verschieben' ziemlich falsch). Sonst muss ich da wieder mit JavaScript gegensteuern.... --Caleb Blackhand 21:16, 16. Sep. 2014 (UTC)

“	MediaWiki 1.23 includes 3 ResourceLoader modules that you can import to get some common content styling without having to copy it into your own CSS: 'mediawiki.skinning.elements', 'mediawiki.skinning.content' and 'mediawiki.skinning.interface', which provide progressively more default styling. They can be loaded like any other module (see the example in "Skin code" section below). We will use 'mediawiki.skinning.interface'. Note: you can't use these ResourceLoader modules if you'd like your skin to be compatible with earlier MediaWiki versions.	„
	~ http://www.mediawiki.org/wiki/Manual:Skinning#Skin_styles_and_scripts_.28ResourceLoader_modules.29

So wie ich das verstanden hab, geht das Ganze über die load.php - wo wir halt keinen Zugriff drauf haben. --eagle3000 ^{(D ~ B)} 21:26, 16. Sep. 2014 (UTC)

Siehe: http://minecraft-de.gamepedia.com/load.php --eagle3000 ^{(D ~ B)} 21:27, 16. Sep. 2014 (UTC)

Hier ist das verantwortliche Modul: http://minecraft-de.gamepedia.com/load.php?&modules=skins.vector.styles&*

div.vectorTabs h3,div.vectorMenu h3 span{display:none}

--eagle3000 ^{(D ~ B)} 21:31, 16. Sep. 2014 (UTC)

Lösung für die persönliche common.css:

div.vectorMenu h3 span
{
  display:block;
  width: 70px;
  font-size: 0.6em;
  text-align: center;
  margin-top: 15px;
  margin-left: 7px;
}

Funktioniert zumindest bei mir in der Firefox-Stilbearbeitung einwandfrei. Die Schaltfläche heißt dann "Aktionen", das hängt aber wie gesagt an MediaWiki:Actions. | violine1101^(Diskussion) 22:16, 16. Sep. 2014 (UTC)

Alternative CSS-Einstellungen, um ~~in das leere Feld~~ In das Aktionen-Feld statt des Textes wieder einen Pfeil zu zaubern:

#p-cactions #p-cactions-label a {
  background-image: linear-gradient(transparent, transparent),
url("data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c3ZnIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgd2lkdGg9IjE2IiBoZWlnaHQ9IjE2Ij48cGF0aCBkPSJNMTMuMDAyIDYuMDAxbC01IDUuMDAxLTUtNS4wMDF6IiBmaWxsPSIjMjAyMDIwIi8+PC9zdmc+Cg==");
  background-position: right center;
}

div.vectorMenu h3 span
{
  display:none !important;
}

Die SVG-Datei wird als Base64-Encoding direkt eingebettet, ein fast schwarzer Pfeil nach unten. Hier kann man ntürlich auch eine URL zu einer existierenden Datei angeben, z.B. url("http://hydra-media.cursecdn.com/minecraft-de.gamepedia.com/f/fb/Arrow-down.png") für den hellgrauen Pfeil Datei:Arrow-down.png. --Caleb Blackhand 08:55, 17. Sep. 2014 (UTC)

PS: Das sollte dann auch in der MediaWiki:Common.css funktionieren für alle. Hydra.css sollten wir evtl. nicht nehmen, da scheint ja geplant zu sein, die zentralisiert zu verwalten (en-MCW).... --Caleb Blackhand 11:45, 17. Sep. 2014 (UTC)

Oben ergänzt für alle, die wie ich was gegen zu viel Text in der Zeile haben.... --Caleb Blackhand 05:54, 18. Sep. 2014 (UTC)

Eieiei, da kam ja einiges zusammen. Aber wie ich sehe, kann man durch Änderung der common.css den leeren Menüpunkt beschriften. Das durch die Systemtexte vorgegebene "Aktionen" finde ich gut. Jetzt kann auch ein neuer Benutzer damit etwas anfangen und ist hoffentlich etwas weniger ratlos, wenn er eine Seite umbenennen/verschieben will. Zwar scheint jetzt "Teilen" doppelt da zu stehen, aber das stört mich weniger, als ein leerer Menüpunkt. Den Sinn des Menüpunktes "Lesen" habe ich aber nicht verstanden. Er scheint identisch zu "Seite" bzw. "Diskussion" zu sein. -- Sumpfhütte 22:40, 17. Sep. 2014 (UTC)

Design kaputt

Ich hab vor ein paar Minuten auf Twitter gefragt an wem ich mich wenden muss, wenn es ein Problem mit dem Design gibt. Der Fehler tritt jederzeit auf jeder Seite auf, nutze Firefox 32.0.2 (mit Add-Ons) und nochmal denselben ohne Add-Ons probiert, ohne sichtbare Änderungen.
Warum Teilen 2x da steht, ist mir auch schleierhaft. Den 2. Screenshot nur zur Veranschaulichung, wie es normal aussehen sollte (Englisches Wiki)
Screenshots: -M1n3r2011 (Diskussion / Beiträge) 18:37, 20. Sep. 2014 (UTC)

Merkwürdig. Ich habe auch mit Firefox 32.0.2 getestet, und bei mir gibt es diese Verschiebung im Design nicht. Vielleicht liegt es an den Firefox-Einstellungen? -- Sumpfhütte 19:28, 20. Sep. 2014 (UTC)

Bei mir gibt's den doppelten "Teilen"-Button nur ohne meine persönliche common.css (Weil ich diesen dort ausgeschaltet habe :P). Die Verschiebungen der Buttons "Lesen", "Quelltext anzeigen" und "Aktionen" könnten etwas mit dem doppelten Anzeigen des "Teilen"-Buttons zu tun haben. Wenn du dein Fenster größer ziehst, wirst du sehen, dass das an deinem zu kleinen Fenster liegt. Getestet habe ich das in Google Chrome 37.0.2032.120 m (Was für eine Versionsnummer!) und Firefox 32.0.2. Ich vermute allerdings, dass das ganze Problem durch die Änderung der Aufschrift des "Aktionen"-Buttons von Nichts auf "Aktionen" entstanden ist. | violine1101^(Diskussion) 19:48, 20. Sep. 2014 (UTC)

Ah, es hing tatsächlich daran. Hier ein Fix:

/* Text for empty action-menu */
#p-cactions-label span /* <- DAS HIER ÄNDERN */
{
  display:block;
  width: 70px;
  font-size: 0.6em;
  text-align: center;
  margin-top: 15px;
  margin-left: 7px;
}

Dies kann dann in die nicht so persönliche Common.css‎ übertragen werden, das sollte deinen Fehler beheben. Allerdings fehlt auch der Pfeil hinter "Teilen" und der Tab ist unnötig breit, ich habe allerdings noch keinen Weg gefunden, dies zu beheben (wobei das EN-Wiki immernoch den unbeschrifteten Aktionen- und den übergroßen Teilen-Tab hat).

PS: Der Pfeil, so wie er vorher war, und wie CalebBlackhand ihn auch wieder durch CSS wieder sichtbar gemacht hat, kann meiner Meinung nach auch in die offizielle Common.css eingefügt werden, ich hab da nichts dagegen. Vielleicht eine Einstellung hinzufügen, falls das möglich ist? | violine1101^(Diskussion) 20:16, 20. Sep. 2014 (UTC)

Das Problem ist, ich kann nicht größer als 1014 x 768 gehen, weil der derzeitige Monitor leider keine größeren Auflösungen darstellen kann und daher diese nutzen muss. Wie könnte ich den Fix machen? Eine Erklärung wäre sehr hilfreich. :) -M1n3r2011 (Diskussion / Beiträge) 22:28, 20. Sep. 2014 (UTC)

Den oben erwähnten Fix kann nur ein Admin anwenden. Du persönlich kannst folgendes in dein persönliches Stildokument schreiben:

div.vectorMenu h3 span /* Zur Erklärung: Hier handelt es sich um die Titel der Tabs "Teilen" und "Aktionen", da beide Tabs ein Drop-Down-Menü (vectorMenu) sind */
{
  display: none !important; 
}

#p-cactions-label span /* Zur Erklärung: Hier handelt es sich NUR um den Titel des "Aktonen"-Tabs */
{
  display: block !important;
}

Das behebt den Fehler wie oben, der doppelte Twittertab wird nur einmal angezeigt. Wenn du diesen aber gar nicht benutzt (wie ich), kannst du ihn dort auch ganz ausschalten:

#p-sharing /* Zur Erklärung: Hier handelt es sich NUR um den Tab "Teilen" */
{
  display: none !important;
}

Das ganze war mein Fehler, da ich beim Erstellen des "Leeres-Aktionsmenü-Fixes" meine persönliche CSS drin hatte, weswegen ich nicht gemerkt habe, dass der "Teilen"-Tab doppelt ist. Wie ich auf deinen Screenshots sehe, sollte auch dein Problem mit den verschobenenen Tabs links behoben sein, vor allem, wenn du meine zweite Lösung genommen hast und diesen "Teilen"-Tab ganz ausblendest.

(PS: Der Text, der oben zwischen /* und */ steht, brauchst du nicht zu kopieren, er dient hier nur als Erklärung) | violine1101^(Diskussion) 08:36, 21. Sep. 2014 (UTC)

Ich bedanke mich herzlich, jetzt hab den "Teilen"-Tab ausgeblendet, da ich den eh nicht nutze. Und es sieht wieder schöner aus :) -M1n3r2011 (Diskussion / Beiträge) 10:29, 21. Sep. 2014 (UTC)

Ich kann das Problem nun auch reproduzieren, indem ich in meinem Browser eine Vergrößerung einstelle, z.B. 125%. Dann verschieben sich die Menüpunkte genauso, wie auf M1n3r2011s Screenshot. Grund ist wohl die längere deutsche Sprache: "Talk" vs. "Diskussion", "Edit" vs. "Bearbeitung", "History" vs. "Versionsgeschichte". Die Beschriftung "Aktionen" finde ich sehr wichtig für Neulinge, weil ein unbeschrifteter oder nur mit Pfeil versehener Menüpunkt aus Sicht des Benutzeroberflächendesigns eine Katastrophe ist. Dagegen ist mir immer noch nicht klar, wozu es den "Lesen"-Menüpunkt gibt, daher könnte man z.B. dessen Beschriftung auf einen Pfeil reduzieren. Oder: ist es möglich wegen der längeren Worte die Schriftgröße zu verkleinern? Oder: statt "Versionsgeschichte" schreiben wir: "Versionen". -- Sumpfhütte 08:58, 21. Sep. 2014 (UTC)

Ja, daran habe ich auch schon gedacht. Allerdings würde ich nicht die Wörter verkürzen, sondern Minecraft-Gegenstände verwenden, wie z.B. für Lesen, für Bearbeiten, für Erstellen, für Quelltext anzeigen, für Versionsgeschichte und den vorherigen Pfeil für Aktionen. Das wäre dann die kürzeste Lösung.

Für den bisherigen Aktions-Tab-Fix hätte ich noch ein Update, damit es auch mit anderen Schriftarten als Arial problemlos dargestellt wird und der Tab genauso aussieht wie die anderen:

/* Text for empty action-menu */
#p-cactions-label span
{
  display: inline-block;
  width: auto;
  font-size: 0.6em;
  text-align: center;
  margin-top: 16px;
  padding-left: 8px;
  padding-right: 8px;
  margin-left: 8px;
}

Gehört dieser Abschnitt nicht mittlerweile in das Gemeinschaftsportal? Er geht ja nicht nur Admins an, sondern alle Wiki-Autoren! | violine1101^(Diskussion) 09:20, 21. Sep. 2014 (UTC)

Das mit den Symbolen finde ich nicht so gut. Einfach alle Beschriftungen durch Symbole zu ersetzen weicht einerseits viel zu stark vom Wiki-Standard ab und ist, v.a. für Neulinge, ein noch viel größerer Design-Fauxpas. Weniger wichtig finde ich persönlich allerdings die Beschriftung "Aktionen", da darunter eigentlich nur Funktionen gruppiert sind, die sonst eher selten gebraucht werden (im Normalfall nur "Verschieben"). Wer diese Funktion braucht, muss sowieso danach suchen, egal, ob da ein Pfeil ist oder eine mehr oder weniger nichtssagende Beschriftung wie "Aktionen", da man so ziemlich alles als "Aktion" ansehen kann. Ich finde den Pfeil eigentlich intuitiv genaug, man denke z.B. auch an den kleinen Pfeil in der Windows-Notification-Leiste, der die versteckten Notifications anzeigt, oder an den nur aus drei Punkten bestehenden Overflow-Button in der Android Action Bar. Fazit: Beschriftungen, wenn man viele verschiedene Einträge gruppiert (wie in der Übersicht am linken Seitenrand), Symbole, wenn es darum geht, Einträge, die keinen Platz mehr haben oder nicht so wichtig sind, in ein Untermenü zu packen (wie bei unseren "Aktionen"). -- Elike98 ^Diskussion 09:26, 21. Sep. 2014 (UTC)

Finde ich auch, ich hab das jetzt einfach mal verschoben (und hoffentlich keinen Editkonflikt damit ausgelöst) -- Elike98 ^Diskussion 09:33, 21. Sep. 2014 (UTC)

Dann wäre eine Einstellung dafür genau das richtige: Wenn man Symbole möchte, kann man diese einschalten, standardmäßig wäre das dann ausgeschaltet (Ähnlich wie die Einstellung "Deaktiviert die Pop-up-Aufforderungen zum Teilen auf Facebook, Twitter, etc." unter "Verschiedenes", z.B. "Verwendet Symbole in der Aktionsleiste"). Die Frage ist dann nur noch, ob eine neue Einstellung zu erstellen möglich ist? | violine1101^(Diskussion) 09:35, 21. Sep. 2014 (UTC)

Ich glaube, das ist leider nur sehr schwer umzusetzen, und wenn, wäre Curse vermutlich nicht sonderlich erfreut darüber, dass wir irgendwo in den Eingeweiden des Minecraft Wikis herumwühlen (Das ist die MediaWiki-Doku-Seite dazu). Auf jeden Fall haben wir aber ja die Möglichkeit, indirekte "Einstellungen" durch eigenes css bzw. js zu realisieren. -- Elike98 ^Diskussion 09:53, 21. Sep. 2014 (UTC)

Ich habe die Beschriftung "Versionsgeschichte" in den Systemnachrichten gesucht, aber es scheint mir gar nicht nötig zu sein, dieses Wort zu verkürzen. Denn wenn ich den Browserzoom verändere, wird die "Versionsgeschichte" offenbar automatisch in die "Aktionen" verschoben. Interessantes Verhalten. Und durch das Entfernen des zweiten "Teilen" ist jetzt bei mir bei 125% Zoom auch keine Überschneidung mehr bei den Menüpunkten zu sehen. Danke an euch für die common.css-Lösungen :-) -- Sumpfhütte 10:02, 21. Sep. 2014 (UTC)