Minecraft Wiki Diskussion:Gemeinschaftsportal/Archiv 9

Dies ist das Archiv der Gemeinschaftsportaldiskussion für Januar bis März 2014. Bitte bearbeite diese Seite nicht. Neue Fragen können auf der aktuellen Diskussionsseite gestellt werden.

Weiterleitungs-Spam

Hallo Leute, ich weiß gar nicht, wie ich es anders nennen soll. Ich finde ja Weiterleitungen grundsätzlich völlig okay, in anderen Gamewikis gibt es davon meist nur wenig bis gar keine. Aber in den letzten Tagen und Wochen wurde es hier - meiner Meinung nach - mit der Erstellung von Weiterleitungen leicht bis mittelschwer übertrieben. Man muss nicht für jede Möglichkeit eine Weiterleitung haben. Die Leute können auch mal für 2 Cent selbst nachdenken und einen anderen Suchbegriff eingeben bzw. gibt es ja auch immernoch die Suchseite, auf die man gelangt, wenn die Suche keinen Treffer ergab. Z.B finde ich Askons aktuelle Aktivität, alle möglichen Kalenderdaten mit Versionsreleases zu verbinden, auch übertrieben. Da ich nicht weiß, ob ich vielleicht die einzige bin, die so denkt, wollte ich das mal in den Raum stellen und - vielleicht - zur Diskussion anregen, wie sinnvoll so unglaublich viele Weiterleitungen denn sind. --Drachin  ♥ ^(Disk) 18:03, 18. Sep. 2013 (UTC)

Nur zur Erläuterung: Die Kalenderdaten werden für die Vorlage:Ver gebraucht, da bestimmte Versionen Datums(?) nutzen. Durch das geänderte System mit den ausgelagerten Entwiclkungsversionen von älteren Versionen musste das so umstellt werden, dass für jede Version eine Weiterleitung erstellt wird. --eagle3000 ^{(D ~ B)} 18:12, 18. Sep. 2013 (UTC)

Ich finde auch, dass übertrieben wird. Weiterleitungen sind zwar gut, aber so viele müssen es jetzt auch wieder nicht sein. HbMinecraft - ^{(Disskusion | Beiträge)} 18:26, 18. Sep. 2013 (UTC)

Es ist völlig in Ordnung wenn Weiterleitungen von Daten her gemacht werden. Aber wenn zum Beispiel Weiterleitungen von bestimmten Seiten dazu führen das es von ihnen gleich 10 Stück gibt ist das zu viel. Beispiel Spawneier - Spawnereier - Spawn Ei - Spawner Ei usw. Nethonos 20:11, 18. Sep. 2013 (UTC)

Wie schon angesprochen müssen wir die Weiterleitungen in zwei Gruppen einteilen. Zum einen die Versionsnummern: Durch die Aufteilung der alten Entwicklungsversionen auf ihre eigenen Seiten (Für jede Vollversion eine) funktionierte Vorlage:Ver nicht mehr richtig. Alle Versionsangaben für Entwicklungsversionen verlinkten dann zu der Versionsgeschichte der Classic. Um dieses Problem zu lösen habe ich auch schon eine Diskussion angefangen. Leider kam aber nicht viel Rückmeldung. Da ich selbst nicht viel von HTML usw. verstehe habe ich dann mangels Alternativen die Lösung mit den Weiterleitungen gewählt. Deswegen auch die Erstellungen der Kalenderdaten, die als Versionsangabe für frühere Versionen fungieren.
Der Nachteil ist, dass die Weiterleitungen, die auf Versionsgeschichte/Entwicklungsversionen leiten, geändert werden müssen, wenn ältere Entwicklungsversionen eine eigene Seite bekommen. Der Vorteil ist, dass man jetzt auch nach 13w36a suchen kann und fündig wird.
Zum anderen gibt es die "normalen" Weiterleitungen, von denen tatsächlich einige existieren. Ich denke wir sollten dort auch etwas ausmisten. Das Spawner-Ei ist da ein gutes Beispiel. Wenn man danach sucht und Spawn eingibt, findet man 4 Weiterleitungen. Um die Suchanfrage zu vervollständigen, würde eine reichen. Das Problem ist allerdings, dass Personen, die die Suchvorschläge missachten und mit einem falschen Suchwort suchen nicht fündig werden. (Trotz der "Suchseite", die danach erscheint. Probiert es mal mit "Spawnei" aus. Ihr werden weder auf die richtige Seite geleitet, noch wird sie danach angezeigt)--.zip ^{de.MinecraftWiki-Admin Diskussion} 14:53, 19. Sep. 2013 (UTC)

Sehe ich auch so. Nebenbei: Ist das Wiki nur bei mir so langsam? ILeon ᐸ Diskussion
Beiträge - de.Wiki Admin 14:57, 19. Sep. 2013 (UTC)

Weiterleitungen schaden ja grundsätzlich niemanden, außer vielleicht der Serverlast oder wenn es darum geht, doppelte oder sonst wie beschädigte Weiterleitungen zu reparieren. Meiner Meinung nach sollte sie nicht grundlos drauf los erstellt werden mit Namen, die eventuell irgendwann mal von irgendwem eingegeben werden könnten. Bei den meisten Suchanfragen wird ja letztendlich der richtige Artikel in den Suchergebnissen angezeigt, wenn der Suchbegriff nicht gerade massiv vom Artikelnamen abweicht. Sollte diese allerdings nicht der Fall sein, können WLs durchaus weiterhelfen. Man weiß aber auch nicht genau, welche Suchbegriffe angewendet werden könnten. Die beste Möglichkeit, dies herauszufinden ist, aus einer Seite, die von einem Unwissenden erstellt wurde, der den entsprechenden Artikel auf Suchanfrage nicht gefunden hat (und daraufhin ja auch oben auf das Erstellen der Seite aufgefordert wird), eine WL zum "echten" Artikel zu machen. Suchti ^{Diskussion Mail} 15:57, 30. Nov. 2013 (UTC)

Antrag auf Bot-Auftrag

Wenn man sich Spezial:Gewünschte Seiten ansieht, so sind dort viele Seiten der Form Mod/<Modname>/<Item> enthalten. Schuld daran bin vmtl. größtenteils ich selbst, weil ich die Grid-Bilder entsprechend verschoben habe (Grid <Itemname> (<Modname>).png) und die automatische Verlinkung nun "ins Leere" greift. Wenn niemand etwas dagegen hat, würde dich meinen Bot gerne mit der Erstellung der Weiterleitungen vom Mod/<Modname>/<Item> auf Mod/<Modname> beauftragen. Meinungen? --Caleb Blackhand 12:11, 3. Nov. 2013 (UTC)

Bist du dir sicher, dass es von deinem Bot kommt? Die Redlinks entstehen durch die Einbindung der Grids. Ich denke, da gibt es einen Fehler in Vorlage:Grid2--.zip ^{de.MinecraftWiki-Admin Diskussion} 12:20, 3. Nov. 2013 (UTC)

Nee, nicht der Bot ist Schuld, sondern meine "Umbenennungen" der Bilder. Beispiel: Datei:Grid haystack3.png nach Datei:Grid Heuballen (Mo' Creatures).png. Es gibt die Weiterleitung haystack3 (auch wenn die inzwischen nutzlos ist), aber nicht Mod/Mo' Creatures/Heuballen. --Caleb Blackhand 12:24, 3. Nov. 2013 (UTC)

ALternativ könnte man aber darüber nachdenken, bei Mod-Bildern statt des Links auf das Item (welches eh fast immer nicht als eigene Seite existiert) direkt die Mod-Seite zu verlinken. --Caleb Blackhand 12:25, 3. Nov. 2013 (UTC)

Das meinte ich, sorry. Eine Verlinkung auf die Mod-Items oder -Blöcke macht wirklich keinen Sinn. Ich habe vorhin Vorlage:Grid2 überflogen und einen Teil entfernt, vom dem ich dachte dass er für die Verlinkung zuständig ist..., war aber erfolglos.--.zip ^{de.MinecraftWiki-Admin Diskussion} 12:40, 3. Nov. 2013 (UTC)

Okay, dann schau ich mir das mal an in der Vorlage. Sinnvoll ist wirklich was anderes. Und grade beim Einsatz der Crafting Table / Brewing Stand / ... - Vorlagen kann man ja nicht mal einen alternativen Link mit angeben. Kann also sein, dass das direkt aus den Untervorlagen stammt. --Caleb Blackhand 12:43, 3. Nov. 2013 (UTC)

Hat etwas gedauert, aber die Grid-Vorlage selbst macht nun erfolgreich genau das, was oben vorgeschlagen wurde: Hat ein Bild ein Mod-Prefix (oder wurde der Parameter mod= benutzt und das Bild hat keinen vanilla: oder v:-Prefix), dann wird der benannte Mod verlinkt, nicht mehr Mod/Modname/Bildname. Bei Animationen klappt dies noch nicht, d.h. ab dem zweiten Bild wird noch aufs Bild verlinkt. Den Code in MediaWiki:Common.js dazu muss ich mir noch genauer ansehen..... (und ggf. dabei auch gleich nachsehen, ob das Problem mit einem zweiten und dritten v: in einer Animation lösbar ist). --Caleb Blackhand 11:31, 13. Nov. 2013 (UTC)

Ich korrigiere mich: Wenn ich Minecraft_Wiki_Diskussion:Gemeinschaftsportal#MediaWiki_update lese, dann lasse ich das lieber noch und warte ggf. auf die (dann ja angeblich so einfache und mächtige) LUA-Lösung. Die kann man dann ja immer noch anpassen. --Caleb Blackhand 15:48, 13. Nov. 2013 (UTC)

Die neue Wiki-Version ist da, LUA nicht - es fehlt die Extension Scribunto dafür. Darf ich davon ausgehen, dass diese Extension nicht sehr hoch in der Liste der Prioritäten liegt? In dem Fall wäre nämlich eine (Teil-)Reparatur des JavaScripts für die Animate-Vorlage angesagt. --Caleb Blackhand 15:25, 23. Dez. 2013 (UTC)

Da wir seit kurzem LUA haben und seit heute die Vorlagen auch damit laufen, hat sich das hier wirklich erledigt. Die Linkanpassungen im LUA-Code durchzuführen war herrlich einfach - ich mag das. --Caleb Blackhand 22:45, 21. Jan. 2014 (UTC)

Mojang-Staff bebildern

Auf der Minecon 2013 wurde das komplette Minecraft-Personal vorgestellt mit Name und Funktion. Wenn jemand ein praktisches Bildbearbeitungsprogramm und die Zeit dafür hat, könnte man aus dem Video des von Mojang offiziell verbreiteten Livestreams (http://www.youtube.com/watch?annotation_id=annotation_1094667583&feature=iv&src_vid=Ti3dhGfQJrI&v=8o1pjJSd-aE von 7:29 bis 10:39) auch für jene Mojang-Leute ein Foto extrahieren, die bisher noch ein Fragezeichen sind. -- Sumpfhütte 13:52, 3. Nov. 2013 (UTC)

Die Länge der Versionsgeschichte von Seiten begrenzen bzw. eine Löschbegrenzung ?

Hallo, ich finde es gut das es Versionsgeschichten zu jeder Seite gibt, so kann man auch Vandalen einhalt gebieten oder manche Fehler die man ausgelöst hat wieder rückgängig machen. Aber wiso wird die Versuionsgeschcihte einer Seite ins unermessliche gespeichert ? Wäre es nicht sinnvoll eine Löschbegrenzung einzuführen ? Das zum Beispiel ab 500 Bearbeitungen die 501. automatisch gelöscht wird. Vorallem bei Seiten wie die Versionsgeschichte/Entwicklungsversionen oder Versionsgeschichte denke ich würde es Sinn machen. Was haltet ihr davon ? Nethonos (Diskussion) 15:37, 23. Nov. 2013 (UTC)

Viel Spass, das bei den Entwicklern von MediaWiki durchzubekommen. Oder bei den Kollegen in der Wikipedia, denn die benutzen die selbe Software. ;)

Ohne Quatsch: Das wäre (zumindest in der Wikipedia) für die Lizenz tödlich. Voraussetzung für die Nachnutzbarkeit ist es doch grade, JEDEN Autor, der an einem Artikel mitgewirkt hat, nennen zu können. Das wäre mit deinem Vorschlag eher schlecht.

Persönlich hätte ich auch etwas dagegen. Ich habe in der letzten Zeit viele Löschanträge auf Dateien gestellt - aber bei jeder Datei erst in der Edit-Historie des Uploaders nachgesehen, ob er die Datei irgendwo eingebaut hat, und dann (falls ja) die Edits im Artikel ab diesem Zeitpunkt nachverfolgt, um zu sehen, warum die Datei grade nicht mehr benutzt wird. Auch das wäre mit Umsetzung deiner Idee nicht mehr vollumfassend möglich. Ergo: Ich wäre dagegen, dieser Vorschlag schadet der Nachvollziehbarkeit. --Caleb Blackhand 15:41, 23. Nov. 2013 (UTC)

Mulitartikel -> Weiterleitungen zu anderen Sprachen

Ich möchte diese Diskussion mal wieder ansprechen. Was haltet ihr davon? ILeon ᐸ Diskussion
Beiträge - de.Wiki Admin 20:52, 7. Dez. 2013 (UTC)

Ich bin derselben Meinung wie 178.6.57.144. Auch ich nutze die Interwiki-Links nur sehr selten. Und wenn, habe ich kein Problem damit, auf einen Link zu klicken, um von wheat zu seed zu kommen. Sehr wichtig ist mir dagegen, dass eine Information nur einmal im Wiki steht und von anderen Stellen darauf verwiesen wird (z.B. mit Vorlage:HA). Daher sollte bei einer möglichen Trennung in die Artikel "Melone", "Melonenkerne" und "Melonenscheibe" auch nur genau darüber informiert werden. Ich glaube aber, bei den Kulturpflanzen lässt sich die Information gar nicht trennen, ohne drei Mal nahezu dasselbe zu schreiben.
Beim "Netherziegel" bin ich dagegen unschlüssig: einerseits sind beim "Lehm" auch Block und Item in einem Artikel zusammengefasst. Bei "Lapislazuli" aber nicht. -- Sumpfhütte 23:17, 7. Dez. 2013 (UTC)

Umbenennungen

Hallo zusammen,
bei der Umbenennungsplattform Crowdin hat sich einiges getan. Da wir nun endlich eine Art Moderator für das deutsche Projekt haben, konnten einige Änderungen vorgenommen werden. Unter anderem wurden die falschen Bezeichnungen "Lehm" und "Silberfisch" durch die korrekten "Ton" und "Silberfischchen" ersetzt. Ich bitte euch, euch an der Umbenennung hier im Wiki zu beteiligen, damit das schnell über die Bühne geht. Einige Punkte sind unten aufgezählt. Ich hoffe ich habe alles zusammengefasst. Die Liste darf auch gerne erweitert werden. Gruß ---.zip ^{de.MinecraftWiki-Admin Diskussion} 18:05, 21. Dez. 2013 (UTC)

• Wolle --> Weiße Wolle (Text und Bilder verschieben)Erledigt
• Teppich --> Weißer Teppich (Text und Bilder verschieben) Teppich Erledigt
• Farbbezeichnungen überprüfen (Vor allem Orange/Magenta)Erledigt
• Redstoneblock --> Redstone-Block (Block, Bilder, usw)Erledigt
• Lehm --> Ton (Block, Item, Bilder, usw)Erledigt
• Silberfisch --> SilberfischchenErledigt
• Rosenrot --> Roter FarbstoffErledigt
• Löwenzahngelb --> Gelber FarbstoffErledigt
• Lapilazuli-Block --> LapislazuliblockErledigt
• Lapilazuli-erz --> LapislazulierzErledigt
• Rüstungsbezeichnungen aktualisieren

Ich habe alle Seiten, auf denn das "Grid Wolle" eingebunden war verändert. Die Seite Wolle würde ich jetzt aber so lassen. Wie sieht es mit den ganzen andere Verlinkungen auf diese Seite aus, z.B. in Versionsgeschichten. Die findet man doch nie. (Ich werde sicher nicht nach dem Wort "Wolle suchen :3 ) -- Oliver Scholz - Wiki Admin 19:56, 21. Dez. 2013 (UTC)

Aufgetauchte doppelte Redirects und 'tote Links' nachgepflegt. Selbst Spezial:Gewünschte_Seiten wird immer kürzer. --Caleb Blackhand 16:48, 22. Dez. 2013 (UTC)

Was Wolle betrifft, habe ich gezielt ein paar Änderungen vorgenommen, wo ich Bedarf vermutet habe. Bei den anderen Seiten kann ich mir nicht vorstellen, dass speziell die weiße Wolle gemeint ist. --.zip ^{de.MinecraftWiki-Admin Diskussion} 09:00, 23. Dez. 2013 (UTC)

Kümmere mich um die Farbnamen Erledigt Kumasasa (Diskussion) 09:26, 23. Dez. 2013 (UTC)

Und um Rosenrot/Löwenzahngelb Erledigt Kumasasa (Diskussion) 11:57, 23. Dez. 2013 (UTC)

Danke Kumasasa! -- Sumpfhütte 12:21, 23. Dez. 2013 (UTC)

Bin ja nicht ganz unschuldig an der Umbenennung... Lapislazuli Erledigt Kumasasa (Diskussion) 12:53, 23. Dez. 2013 (UTC)

Was ist eigentlich der Grund beim Lapisblock den Strich wegzunehmen und beim Redstone-Block einzufügen? Willkür oder steckt mehr dahinter? Die Entscheidung fiel ja - soweit ich das sehe - gegen den Mehrheitswillen durch Kumasasa als Moderator. Die Begründung "Aus Konsistenz mit den anderen Redstone-Blöcken und Items mit Bindestrich" ist für mich wenig aussagekräftig. --eagle3000 ^{(D ~ B)} 13:40, 23. Dez. 2013 (UTC)

Grund für Lapislazuliblock und -erz waren die Einheitlichkeit mit Eisenblock, Goldblock, usw. Bei Redstone-Block war die deutsche Rechtschreibung ausschlaggebend. (Zusammengesetzten Wörter aus einem englischen und einem deutschen Teil müssten mit Bindestrich getrennt werden) --.zip ^{de.MinecraftWiki-Admin Diskussion} 13:49, 23. Dez. 2013 (UTC)

Eagle 3000, bevor du vorschnelle Urteile über mich fällst, lies dir die Diskussion zu dem Thema durch: http://crowdin.net/project/minecraft/discussions/2780 . Hast du denn auch Votes zu den entsprechenden Vorschlägen abgegeben oder eigene eingereicht ? Kumasasa (Diskussion) 14:07, 23. Dez. 2013 (UTC)

Hey, ich urteile doch nicht über dich. Mir hat jedoch der Kontext, der zu der Entscheidung geführt hat, komplett gefehlt, da bei den Übersetzungen an der Seite nichts dazu steht. Ehrlich gesagt habe ich auch gar nicht gewusst, dass es ein Diskussionsforum gibt (mein Lesezeichen ist auf dieser Seite). --eagle3000 ^{(D ~ B)} 14:25, 23. Dez. 2013 (UTC)

Neues Lesezeichen für Eagle3000 Kumasasa (Diskussion) 14:54, 23. Dez. 2013 (UTC)

:-) --eagle3000 ^{(D ~ B)} 16:37, 23. Dez. 2013 (UTC)

Ach Kumasasa haben wir die Arbeit zu verdanken. :D Bin ja garnicht UpToDate. Ich finde es sehr gut, das die Personen von crowdin auch im Wiki arbeiten und andersherrum. Sonst würde das ja monatlich hin und her gehen wie am Anfang. -- Oliver Scholz - Wiki Admin 16:58, 23. Dez. 2013 (UTC)

Ja, ich wars :-P Die Übersetzungen sind aber nun alle validiert und damit stabil. Es ist jedoch immer damit zu rechnen, dass sich durch veränderten Spielkontext veränderte Namen ergeben können (Rosenrot...) oder durch Impulse von Außen, s. http://crowdin.net/project/minecraft/discussions/2813 . Kumasasa (Diskussion) 19:00, 23. Dez. 2013 (UTC)

Vorlage:BiomeLink

Hallo zusammen,
Ich würde gerne oben genannte Vorlage nach dem Vorbild von Vorlage:BlockLink und Vorlage:ItemLink abändern. Leider funktioniert diese Vorlage anders als die andern beiden -Link-Vorlagen. Könnte sich vielleicht jemand, der mehr davon versteht das ganze mal anschauen? Gruß --.zip ^{de.MinecraftWiki-Admin Diskussion} 10:05, 30. Dez. 2013 (UTC)

Verrat mal genauer, was da geändert werden soll bzw. was rauskommen soll. Vorlagen basteln kann ich, aber ich mag jetzt nicht raten, was du willst ;) Übrigens: Vorlage:BiomeLink/doc passt irgendwie grad gar nicht zur Vorlage... --Caleb Blackhand 10:16, 30. Dez. 2013 (UTC)

Im Moment muss die ID und ein Anzeigename angegeben werden, um einen einfachen Link darzustellen. Nach der Umstellung soll das ohne extra Erwähnung der ID funktionieren. (So wie jetzt auch Vorlage:BlockLink funktioniert) Die Dokumentation wurde wohl aus dem englischen Wiki übernommen und nicht großartig angepasst. Aber wir sind ja gerade dabei, die Dokumentationen zu überarbeiten.--.zip ^{de.MinecraftWiki-Admin Diskussion} 10:27, 30. Dez. 2013 (UTC)

Ich habe mal die Zwischenvorlage "SpriteLink" rausgenommen - die tat nichts weiter, als Parameter durchreichen, das aber hinreichend kompliziert. Wenn ich das richtig sehe, müsstest du nun zuerst eine Kopie von {{BiomeSprite}} anlegen, dort die ganzen deutschen Parameter mit den IDs versorgen, und dann die BiomeLink - Aufrufe entsprechend anpassen. Der Parameter id ist übrigens jetzt schon optional, wie {{BiomeLink|hills}} zeigt - nur dass dann halt ein Rotlink kommt, weil wir keinen Artikel 'hills' haben. --Caleb Blackhand 10:53, 30. Dez. 2013 (UTC)

Nachtrag: Bisher gab es ja immer eine Abkürzung, die man nutzen konnte. Hier würde sich meiner Meinung nach Vorlage:Biom anbieten, die nach Abschluss der Arbeiten in einen Redirect auf Vorlage:BiomeLink umgewandelt werden kann. Oder man legt Vorlage:BiomLink an (ohne das 'e') und löscht nach getaner Arbeit die Vorlage BiomeLink. --Caleb Blackhand 11:15, 30. Dez. 2013 (UTC)

Ach wie nett - die Vorlage war anscheinend nur in der NavBox im Einsatz? Dann wärst du damit ja durch, Zip. --Caleb Blackhand 11:45, 30. Dez. 2013 (UTC)

Ja, einfacher als ich dachte. --.zip ^{de.MinecraftWiki-Admin Diskussion} 11:48, 30. Dez. 2013 (UTC)

Guten Rutsch!

Das Jahr neigt sich dem Ende zu. An dieser Stelle bedanken wir uns bei allen Benutzern und Benutzerinnen, die uns so tatkräftig unterstützen, tolle Beiträge leisten, hilfreiche Tipps haben, oder einfach nur einen Rechtschreibfehler beheben. :)

Wir wünschen euch und euren Familien einen guten Rutsch, einen erfolgreichen Start ins neue Jahr und alles erdenklich Gute!

ILeon ᐸ Diskussion
Beiträge - de.Wiki Admin 16:08, 31. Dez. 2013 (UTC)

Ebenfalls. ;) --eagle3000 ^{(D ~ B)} 16:17, 31. Dez. 2013 (UTC)

... und vielen Dank an die sehr engagierten Admins Benutzer:ILeon und Benutzer:.zip, die immer schnell reagieren wenn sie gebraucht werden und auch vor mühseligen Aufgaben nicht zurückschrecken, um die Qualität des deutschen Minecraft Wikis (des zweitgrößten nach dem englischen) weiter zu verbessern. -- Sumpfhütte 12:00, 1. Jan. 2014 (UTC)

Vielen Dank an alle Autoren und unsere Admins, und ein frohes neues Jahr 2014. Lasst und mit dem Frühjahrsputz beginnen ;) --Caleb Blackhand 13:16, 1. Jan. 2014 (UTC)

Ich möchte mich auch ganz herzlich bei allen Autoren und Autorinnen bedanken. Ich denke wir können auf ein für das Wiki erfolgreiches Jahr zurückblicken. Viele neue Artikel sind entstanden, andere grundlegend überarbeitet worden und auch einige Verbesserungen im administrativen Bereich gab es (Kategorien, Vorlagen, Dateilöschungen usw.) Ebenso sind aber auch die kleinen Änderungen zu würdigen. Oftmals fallen kleine Fehler nicht auf. Umso besser ist es, dass es angemeldete aber auch anonyme Nutzer gibt, die sich diesen Fehlern annehmen. Ich wünsche euch ein frohes neues Jahr, und dass 2014 sowohl für das Wiki als auch für euch privat mindestens genauso erforlgreich wird. Grüße --.zip ^{de.MinecraftWiki-Admin Diskussion} 13:38, 1. Jan. 2014 (UTC)

Einheitliche Sprite/Eintrags-Vorlage für alle Sprite-ID-Listen.

Hallo zusammen,
durch die Erstellung der ID-Listen für Sprite-Vorlagen wie etwas Vorlage|ItemSprite, {{BlockSprite}}, {{EffektSprite}} sowie die dazugehörigen Link-Vorlagen brauchen wir momentan für jede dieser Vorlage eine Unterseite /Eintrag bzw. /entry. Ich habe mir gedacht, dass das doch auch durch eine einzige Vorlage gelöst werden kann. Auf einer meiner Unterseiten habe ich schon einen Versuch gestartet, komme aber mal wieder nicht weiter. Kennt jemand eine Lösung? Bearbeitungen können an meinre Unterseite gerne vorgenommen werden. Mein Ansatz war, dass die Vorlage je nach "Präfix" der ID-Liste den richtigen Teil der Vorlage verwendet. (Durch if-Abfrage) Gruß --.zip ^{de.MinecraftWiki-Admin Diskussion} 17:09, 4. Jan. 2014 (UTC)

Ich konnte das Problem mit der Vorlage {{!}} lösen. Habe nebenbei aber auch noch andere Änderungen gemacht, die du nicht übernehmen musst. -- Oliver Scholz - Wiki Admin 19:22, 4. Jan. 2014 (UTC)

Durch #titleparts ist sogar die if-Abfrage überflüssig und daher entfernt. -- Oliver Scholz - Wiki Admin 00:39, 5. Jan. 2014 (UTC)

Warum nur habe ich das ungute Gefühl, dass die neue Sammelvorlage an der Explosiven Ausdehnung von Spezial:Gewünschte_Seiten Schuld ist? Das mag mir grad nicht gefallen.... ;) --Caleb Blackhand 00:51, 5. Jan. 2014 (UTC)

Tip: titleparts ist da falsch, denn es erzeugt auch ObjektLink / EffektLink / ItemLink / ... - Einbindungen, wo nur die -Sprite-Version erwünscht ist. --Caleb Blackhand 00:53, 5. Jan. 2014 (UTC)

Ich habe jetzt Olivers Änderungen erst einmal rückgängig gemacht. --.zip ^{de.MinecraftWiki-Admin Diskussion} 01:08, 5. Jan. 2014 (UTC)

Jetzt, wo ich wieder wach bin, war die Lösung einfach ;) Der Titleparts-Ansatz war genial, aber er muss in ein Switch, damit die -Link-Versionen auch wie die -Sprite-Versionen behandelt werden. Nicht wirklich kompliziert, muss man halt nur drauf kommen. --Caleb Blackhand 08:44, 5. Jan. 2014 (UTC)

Das mit den Link Seiten war mir nicht bewusst. Schön, dass du es noch retten konntest. :) -- Oliver Scholz - Wiki Admin 09:27, 5. Jan. 2014 (UTC)

Aus 2 mach 1?

Hallo zusammen,
entgegen meiner ersten Vermutung kann "Vorlage:Sprite" doch (noch) nicht entfallen. Sie hat noch eine Einbindung unter Hilfe:Bearbeiten. Mit Vorlage:Sprite/Block gibt es jedoch eine ähnliche Vorlage, die wohl früher einmal auf Vorlage:BlockSprite zugeschnitten war bzw. es immernoch ist. Mittlerweile verwenden sie aber auch die anderen Sprite-Vorlagen. Jetzt meine Frage: Gibt es eine Möglichkeit, aus diesen beiden Vorlagen eine einzige zu machen? Gruß --.zip ^{de.MinecraftWiki-Admin Diskussion} 13:40, 7. Jan. 2014 (UTC)

Ich glaube, man kann das in Hilfe:Bearbeiten umsetzen. Ich schau mir das heut Abend mal an (wenn keiner schneller ist) --Caleb Blackhand 13:49, 7. Jan. 2014 (UTC)

Ich korrigiere: Ersetze Vorlage:Sprite durch Vorlage:Sprite/Block in der Hilfeseite, füge noch jeweils ein Leerzeichen pro Zeile ein - für mich sieht das immer noch gut aus. Ergo kann Sprite nu weg. Oder? Alternativ-Vorschlag: Code von Sprite/Block nach Sprite kopieren, und alle Vorkommen von Sprite/Block durch Sprite ersetzen. --Caleb Blackhand 14:20, 7. Jan. 2014 (UTC)

Ich habe vorhin auch die Vorlagen testweise ausgetauscht, wegen dem Abstand aber aufgegeben. Auf die einfache Lösung mit den Leerzeichen bin ich gar nicht gekommen. Ich würde deinen zweiten Vorschlag umsetzen. Eine Unterseite /Block ohne Hauptseite würde keinen Sinn machen. --.zip ^{de.MinecraftWiki-Admin Diskussion} 14:25, 7. Jan. 2014 (UTC)

Der /Block kann weg, ist nicht mehr verlinkt oder im Einsatz ;) --Caleb Blackhand 14:58, 7. Jan. 2014 (UTC)

Merkwürdige Geräusche

Hallo zusammen, ich will jetzt auch gar nicht mit Herobrine oder sonstigem anfangen, aber ich habe gerade im neuen Snapshot Sounds von Mobs (Creeper Zünde Geräusch aber ohne Explosion und Endermen Geräusch) gehört obwohl ich auf Friedlich gespielt habe und eine Redstone Ready Map gehabt habe auf der es keine Höhlen gab. Und ich habe auch weit und breit keine Mobs gesehen. Könnte das mit den Secret Features im neuen Snapshot etwas zu tun haben? Ich behaupte nicht das es Herobrine oder ähnliches gibt. --Mario_52 ^(Diskussion) 18:40, 9. Jan. 2014 (UTC)

Es war doch eine Redstone-Ready Welt. Hast du mit Sounds experimentiert? Vielleicht ist es aber wirklich ein Feature. HbMinecraft ^{(Diskussion) | (Testseite)} 18:43, 9. Jan. 2014 (UTC)

Ich habe nur Secret Settings gedrückt aber das war schon ein bisschen her und die Sounds ertönen ja gleich beim wechseln. --Mario_52 ^(Diskussion) 18:45, 9. Jan. 2014 (UTC)

Wir sind kein Forum, wir dokumentieren lediglich Minecraft. Am besten du stellst deine Frage in Minecraft.de Suchti ^{Diskussion Mail} 19:17, 9. Jan. 2014 (UTC)

Abgesehen davon kann es in Entwicklungsversionen vor Fehlern nur so wimmeln. Deswegen wird man auch extra gewarnt, bevor man sie im Launcher freischaltet. Ich tippe auf einen Bug, vor allem, weil diese Geräusche in "friedlich" völlig sinnlos sind. (Abschweifung: dass du Herobrine erwähnst, passt perfekt, weil man auch im realen Leben, Dinge, die man auf den ersten Blick nicht erklären kann, mythologischen Wesen zuschreibt, z.B. den deutschen Kobolden oder den englischen Gremlins. In diesem Sinne hat Herobrine immer seine Hände im Spiel, wenn in Minecraft ein Bug auftritt - augenzwinkernderweise natürlich) -- Sumpfhütte 19:25, 9. Jan. 2014 (UTC)

Meinungsbild: Bemooster Stein

Hallo zusammen
der bemooste Pflasterstein wurde in "Bemooster Stein" umbenannt. Infolgedessen sollte der bemooste Stein aus der Seite Pflasterstein entfernt werden. Die Frage ist jetzt, ob man den entsprechenden Inhalt wegen der Namensgleichheit auf die Seite Stein verschiebt, oder der Block eine eigene Seite erhält. Bleiben kann er trotz ähnlicher Verwendung nicht auf der aktuellen Seite. Mit dem Stein an sich hat er eigentlich keine Ähnlichkeit. Was meint ihr? --.zip ^{de.MinecraftWiki-Admin Diskussion} 17:46, 10. Jan. 2014 (UTC)

Hm, den neuen Namen finde ich nicht so gut. Der "bemooste Stein" hat genau dieselbe Textur wie der Pflasterstein, die Pflastersteinstufe, die Pflastersteintreppe, die Pflastersteinmauer und die bemooste Pflastersteinmauer. Und er sieht auch überhaupt nicht dem "Stein" ähnlich und ist auch keine bemooste Version von diesem. Von daher passte "bemooster Pflasterstein" perfekt. Bevor wir das alles ändern, könnten wir auch nochmal abwarten, vielleicht überdenken die Crowdiner die Namensgebung ja nochmal... Ansonsten: eigene Seite - die er mal hatte, bevor ich ihn vor einigen Monaten zum Pflasterstein dazutat :( -- Sumpfhütte 18:19, 10. Jan. 2014 (UTC)

Und: "Pflasterstein" + "Ranke" müsste eigentlich einen "bemoosten Pflasterstein" ergeben... -- Sumpfhütte 18:22, 10. Jan. 2014 (UTC)

Siehe

“	Wouldn't be Bemooster Stein better than Bemooster Pflasterstein? Especially since the Mega Taiga was added, I guess it's weird to find "mossy paving stone" boulders in it. Bemooster Stein would be more natural in my opinion, and more accurate translation-wise.	„
	~ Duke bezüglich http://crowdin.net/translate/minecraft/9380/enus-de#2842024

und http://crowdin.net/project/minecraft/discussions/2813

Bitte übersetzungsrelevante Themen dort diskutieren. Kumasasa (Diskussion) 20:28, 10. Jan. 2014 (UTC)

Komischerweise heist das Resultat aus dem Bemoosten Stein wieder Bemooste Pflastersteinmauer, auch im englischen. Nethonos (Diskussion) 16:54, 25. Jan. 2014 (UTC)

Zusätzliche MediaWiki-Texte

Weiß jemand, warum die Beschriftung MediaWiki:Editnotice-0 und ca. 20 weitere MediaWiki-Texte nicht in den MediaWiki-Systemnachrichten enthalten sind? Und wo findet man sie stattdessen? -- Sumpfhütte 16:09, 15. Jan. 2014 (UTC)

Die Texte stehen nicht in den Systemnachrichten, weil es keine "echten" Systemnachrichten sind - die Editnotices sind eine Art Sonderlösung, siehe auch mw:Help:Edit_notice. Bei anderen könnte es sich um "Leichen" handeln, wo die eigentliche Systemnachricht nicht mehr existiert - das müsste man im Einzelfall nachsehen. In der Liste aller MediaWiki-Seiten stehen die allerdings drin, oder auch unter Spezial:Präfixindex/MediaWiki: --Caleb Blackhand 16:29, 15. Jan. 2014 (UTC)

Prima, habe ich gleich im Inhaltsverzeichnis vermerkt. Folgende sind noch übrig, wobei die meisten offenbar Reste des letzten MediaWiki-Versionswechsels sind, denn ILeon wies danach darauf hin, dass man den Anzeigenamen mit der jetzigen Version nicht mehr ändern kann. Hier die Liste der Textnamen und ihr Inhalt:

• MediaWiki:Custom tag => "Benutzerdefinierte Tags"
• MediaWiki:Disable ads => "Deaktiviert Anzeigen"
• MediaWiki:Displayname => "Anzeigename"
• MediaWiki:Display name => "Anzeigename:"
• MediaWiki:Display name changed => "Anzeigenamen und Einstellungen wurden erfolgreich geändert."
• MediaWiki:Display name error => "Fehler - Anzeigename"
• MediaWiki:Displayname-desc => "Dient zum Bestimmen von Namen und Tags für Benutzer."
• MediaWiki:Displayname description => "Verwandelt Links im NS_USER und NS_USER_TALK Namensraum in Links mit dem Anzeigenamen des Benutzers."
• MediaWiki:Edit display name => "Anzeigenamen bearbeiten"
• MediaWiki:Look up user => "Benutzer suchen"
• MediaWiki:Rss Whitelist => "http://www.minecraftforum.net/rss/writ/1-news/"
• MediaWiki:Sitenotice close => "Schließen"
• MediaWiki:Statistics-jobqueue => "Länge der Auftragswarteschlange"
• MediaWiki:User name => "Benutzername"

Könnten alle veraltet sein? Wie findet man das heraus? -- Sumpfhütte 17:39, 15. Jan. 2014 (UTC)

Die Seiten bezüglich des Anzeigenamen können wohl sicher weg. Bei den anderen bin ich mir nicht sicher, weiß aber auch keinen Weg, wie man das herausfindet.--.zip ^{de.MinecraftWiki-Admin Diskussion} 16:20, 16. Jan. 2014 (UTC)

Ich habe jetzt überall gesucht, finde aber auch nicht heraus, wie man das herausfindet. Aber ich bin bei "translatewiki.net" auf folgende Frage+Antwort im FAQ gestoßen:

“

Why is this obsolete message kept? Q: Should this message and its translations be removed? It is not used any more. A: We do not remove pages that became unused, or are no longer part of any groups. They are not in the way, and may serve a purpose one day. If they are in the way some day, we can always remove them...

„

Jetzt weiß ich zwar immer noch nicht, ob die obigen Meldungen für irgend etwas benötigt werden oder nicht, aber das kann ich dann ja auch so in den Inhalt schreiben, ohne sie alle aufzulisten. -- Sumpfhütte 10:24, 17. Jan. 2014 (UTC)

Werbevideos

Hallo zusammen! Mir ist aufgefallen, dass in letzter Zeit vermehrt Videos als Werbung in der rechten obenren Ecke der Wikiseiten geschaltet werden. Leider gibt es dort weder einen Pause- noch einen Stummschalt-Button. Vielleicht geht es nur mir so, aber ich finde es recht nervig jede 3. Seite neu laden zu müssen, weil in voller Lautstärke ne Werbung losdröhnt, die sich nicht abschalten lässt. Klar, dass ihr auch Geld braucht, aber vll nicht ganz so offensiv? ;) Hoffe ich bin an der richtigen Stelle. Gruß, Benjamin 93.134.146.91 00:55, 16. Jan. 2014 (UTC)

Hi Benjamin! Leider hat die Gemeinschaft der Wiki-Leser und -Autoren, die du hier ansprichst (und zu der du auch gehörst ;-) damit nichts zu tun. Der Server, auf dem das Wiki läuft, die Wiki-Verwaltungssoftware MediaWiki und die dahinter stehende Datenbank - all das wird vom amerikanischen Spielehersteller Curse kostenlos bereitgestellt, gewartet und abgesichert. Und zwar nicht nur für das deutsche, sondern für alle Gamepedia-Minecraft Wikis in 12 Ländern und für alle Minecraft Foren. Diese Firma finanziert sich und ihre Leistung mit der Werbung und gibt das einheitliche Erscheinungsbild aller Minecraft Wikis und Foren vor, z.B. steht der Firmenname immer ganz oben links in der Ecke. Aber: es gibt Abhilfe gegen nervige Werbung. Ich schreibe viel im Wiki und mich würde das auch nerven. Im Firefox habe ich daher das Add-On Flashblock heruntergeladen (über Extras > Add-Ons > Add Ons suchen), das jedes Flash-Video mit einem Startknopf versieht, den man explizit drücken muss. Es gibt aber auch andere, ähnliche Add-Ons. Das hilft. -- Sumpfhütte 08:35, 16. Jan. 2014 (UTC)

Hi Sumpfhütte, dankeschön für den Tip, das hilft tatsächlich ;) Wusste nicht, dass das Wiki-Team da selbst keinen Einfluss hat. Dann ist das natürlich was anderes. Aber gut, dass es solche Add-Ons gibt. Gruß, Benjamin 93.134.236.242 22:37, 16. Jan. 2014 (UTC)

Bestätigung bei externen Links

Ich hab schon wieder ein Problem: Wenn ich neue externe Links hinzufüge (ich wollte Pig Tales erweitern) und die Seite speichere, muss erscheint oben ja dieses Bestätigungsfeld, bei dem man die Katzen auswählen muss. Wenn ich dann nochmal auf speichern gehe, komme ich wieder auf genau der selben Seite wieder mit dem Bestätigungsfeld heraus. Diesmal liegt es auch nicht am Cache oder am Browser, das habe ich schon probiert, avast habe ich auch deaktiviert. Wenn ich andere Änderungen vornehme, kann ich die ganz normal speichern. Hat vielleicht sonst noch jemand das gleiche Problem (gehabt) oder weiß eine Lösung? --Elike98 ^Diskussion 16:06, 16. Jan. 2014 (UTC)

Ich glaube, Suchti hat dasselbe Problem. Wenn ich den Firefox benutzt habe, hat es bei mir funktioniert. Zur Not kommentiere den externen Link mit <!-- Text --> aus und schreibe einen Hinweis in den Speicherkommentar, dann holt das jemand für dich nach. Das ist zwar keine Dauerlösung, aber so kommst du erstmal weiter. -- Sumpfhütte 16:16, 16. Jan. 2014 (UTC)

Ich hab das Problem auch, und zwar im Firefox. Der Fuchs mag also auch keine Katzen. Manchmal kann man das Problem umgehen - aber nicht immer. --Caleb Blackhand 16:21, 16. Jan. 2014 (UTC)

Dann wäre es wohl das Beste, wenn jemand der Betroffenen das Problem im englischen Wiki anspricht. Bei mir selber kommt es nicht vor. Admins bekommen keine Katzen zu sehen :( --.zip ^{de.MinecraftWiki-Admin Diskussion} 16:25, 16. Jan. 2014 (UTC)

Interessant! Dann muss es an den Einstellungen liegen. Denn bei mir hat es mit dem Firefox immer funktioniert. Außer... ich habe ein undefinierbares Fellknäul auf einem verschwommenen, dunklen Bild für eine Katze gehalten, aber es war ein Hund. Oder zumindest keine Katze :-) Hast du das Problem auch, wenn die Bilder ohne jeden Zweifel eindeutig sind? Du kannst die Bilderauswahl mit dem kleinen Knopf am Rand ändern, bis sie eindeutig sind. (Ich habe das oft machen müssen). -- Sumpfhütte 16:33, 16. Jan. 2014 (UTC)

Das war ziemlich eindeutig, was ich da hatte. 3 Mal hintereinander Fellbündel "Maunz" und "Kläff", deutlich erkennbar. Hat nichts geändert. --Caleb Blackhand 16:35, 16. Jan. 2014 (UTC)

Es gibt dazu zwei Beschwerden vom 16. Januar im engl. Wiki. Frage: wenn die Admins diese Auswahl nicht treffen müssen, könnte man das nicht auch für User, die länger als z.B. 100 Tage registriert sind, abschalten? Nicht für neue registrierte User, denn es gibt Spammer, die sich extra dafür registrieren. -- Sumpfhütte 16:44, 16. Jan. 2014 (UTC)

Bei den Kollegen der de-Wikipedia hieße das "ab automatisch bestätigter Benutzer" - Anzahl Tage eingeloggt, Anzahl Edits und bestätigte EMail-Adresse. Hier geht das Recht allerdings schon ab "bestätigte EMail-Adresse" raus, das ist suboptimal. --Caleb Blackhand 16:47, 16. Jan. 2014 (UTC)

Kann das Problem in Chrome 31 bestätigen. --eagle3000 ^{(D ~ B)} 17:04, 16. Jan. 2014 (UTC)

Ich hab das Problem ca. seit Chrome 32, aber nachdem bei mir auch IE nicht funktioniert geh ich davon aus das es andere Gründe hat. Hab Pig Tales jetzt einfach wie Sumpfhütte empfohlen hat mal ohne Links gespeichert, vielleicht kann ja bei Gelegenheit jemand die Links einfügen (und meine Fehler korrigieren) --Elike98 ^Diskussion 17:14, 16. Jan. 2014 (UTC)

Schon geschehen :-) -- Sumpfhütte 17:23, 16. Jan. 2014 (UTC)

Danke --Elike98 ^Diskussion 17:27, 16. Jan. 2014 (UTC)

Komisch, bei den Downloadlinks für die neuen Entwicklungsversionen hat´s auf einmal wieder geklappt ... --Elike98 ^Diskussion 19:57, 16. Jan. 2014 (UTC)

Hattest du deinen Rechner zwischendurch neu gestartet? Oder den Browser? -- Sumpfhütte 20:01, 16. Jan. 2014 (UTC)

Nein, nur in Standby. Aber ich hab mich zwischendurch mal mit meinem Smartphone eingeloggt, weil ich ausprobieren wollte, obs da funktioniert, bin dann aber nicht dazu gekommen. --Elike98 ^Diskussion 20:22, 16. Jan. 2014 (UTC)

Steckbriefe kaputt

Seit Umstellung auf das Modul:Infobox wird der Parameter "firstver" der Vorlage:Block nicht mehr angezeigt. Wer kann das reparieren? -- Sumpfhütte 12:54, 25. Jan. 2014 (UTC)

Weiß ich nicht, weil ich nichtmal weiß, was das mit dem Modul bewirkt. Kann mir das mal jemand erklären? ILeon ᐸ Diskussion
Beiträge - de.Wiki Admin 13:02, 25. Jan. 2014 (UTC)

@ILeon: Seit der neuesten MediaWiki-Erweiterung gibt es den Namensraum "Modul", in dem Skripte lagern, die in Lua geschrieben sind (Infos dazu siehe entspr. Abschnitt in Hilfe:Vorlagen). Damit können einige Probleme gelöst werden, die mit Wiki-Syntax in den Vorlagen nicht lösbar waren. Im engl. Wiki hat User:Majr einige Module geschrieben und die Vorlagen entspr. umgestellt: alter Wiki-Syntax-Code raus, Aufruf eines Moduls rein. Jetzt macht das Modul die Arbeit, die Vorlage ruft es nur auf. Nötig ist das nur bei einigen wenigen Vorlagen. eagle3000 hat die entspr. Module rübergeholt und mit Caleb angepasst. -- Sumpfhütte 13:17, 25. Jan. 2014 (UTC)

Ich schau gleich mal, kann nix wildes sein. --Caleb Blackhand 13:08, 25. Jan. 2014 (UTC)

Hmm, Hast du mal ein Beispiel? In Pflasterstein sieht das nämlich sauber aus (firstver angegeben und angezeigt). Bitte beachten: firstver funktioniert nur, wenn es kein multivers gibt, die beiden sind entweder-oder, mit multivers vorrrangig. Das war aber immer schon so. --Caleb Blackhand 13:11, 25. Jan. 2014 (UTC)

Es ist mir beim Schleimblock aufgefallen. -- Sumpfhütte 13:19, 25. Jan. 2014 (UTC)

Der hat (jedenfalls bei mir) auch "Einführung Vollversion 1.8 (14w02a)" als Zeile. Mal Cache leeren / purge? --Caleb Blackhand 13:25, 25. Jan. 2014 (UTC)

Bei mir sieht alles normal aus. Bild --eagle3000 ^{(D ~ B)} 13:44, 25. Jan. 2014 (UTC)

Eben, bei mir auch. Sumpfhütte, du denkst dran, dass die Parameter-Position nichts mit der Position der Zeile zu tun hat, ja? Nur weil firstver als letztes angegeben wird, ist das nicht die letzte Zeile... ;) --Caleb Blackhand 13:47, 25. Jan. 2014 (UTC)

Cache leeren! Seltsam, aber das war's, danke :-) -- Sumpfhütte 14:15, 25. Jan. 2014 (UTC)

Name-IDs und Datenwerte für TB

Wie sollen wir mit den Datenwerten und Name-IDs bei den Technischen Blöcken verfahren? Sie sind ja nicht mehr via Befehl "givebar" - haben aber bestimmt noch bei externen Programmen wie MCEdit einen Nutzen. Der bezieht sich wohl aber eher auf die IDs als auf die Name-IDs. Habe jetzt schon bei den Artikeln Datenwert und Redstone-Komparator Name-IDs entfernt, bin mir jetzt aber nicht mehr so sicher, ob das wirklich sinnvoll war.. (Änderung betrifft eine offizielle Version und nicht nur Snapshots) --eagle3000 ^{(D ~ B)} 23:07, 1. Feb. 2014 (UTC)

Ich finde, wir sollten die Name-IDs in den Artikeln stehen lassen, und dann in der Vorlage BlockTileEntity die entsprechende Zeile einfach auskommentieren. Braucht man die Name-IDs dann doch wieder, kann man die Zeile einfach wieder einfügen und muss die IDs nicht überall einzeln wieder einfügen. -- Elike98 ^Diskussion 07:45, 2. Feb. 2014 (UTC)

Hm - wenn in der Vorlage die Anzeige der "nameid" auskommentiert wird, dann wird sie für keinen Block mit diesem Steckbrief gezeigt. Vielleicht können aber einige dieser Blöcke auch weiterhin mit /give bekommen werden. Daher würde ich nicht auskommentieren.
Soll man den Namen ganz löschen? Ich würde ihn nur dann behalten, wenn man ihn irgendwie aus den Weltdaten (Chunkdaten) ablesen kann. Dort kann man aber nur die ID ablesen, nicht den Namen. Im Spieler-Inventar (Spielerdaten) könnte man den Namen ablesen, aber diese Blöcke können je gerade nicht ins Inventar geholt werden. Was ist, wenn Mojang den Namen ändert? Oder neue Blöcke einführt? Wir würden deren Namen nicht kennen. Vielleicht wird sogar tatsächlich intern nur die ID benutzt und der Name ignoriert bzw. ausschließlich für die Eingabe von Befehlen benötigt.
Daher würde ich die "nameid" bei allen Blöcken, die weder mit /give, /fill, /setblock oder /testforblock ansprechbar sind, als "nameid" einfach "keine" eintragen. Dann wird "keine" angezeigt. Das heißt für den Leser: dieser Block ist nicht erreichbar (bzw. nur mit Mods, dann aber über die Zahlen-ID). -- Sumpfhütte 13:22, 2. Feb. 2014 (UTC)

Stimmt, ich bin davon ausgegangen, dass alle Blöcke betroffen sind. "keine" einzutragen finde ich eine gute Idee. -- Elike98 ^Diskussion 14:48, 2. Feb. 2014 (UTC)

Okay, dann leg los :-) -- Sumpfhütte 19:50, 2. Feb. 2014 (UTC)

Ich denke es macht Sinn erst mal abzuwarten, bis geklärt ist, wie wir die Name-IDs eintragen wollen, oder? -- Elike98 ^Diskussion 20:15, 2. Feb. 2014 (UTC)

Hm - wenn die Umstellung automatisiert werden kann, könnte man zu den bisherigen nameids auch weitere hinzufügen. Aber wenn nicht... hast du Recht. Warten wir also lieber erstmal ab... -- Sumpfhütte 20:25, 2. Feb. 2014 (UTC)

Ich habe nochmal die Technischen Blöcke überprüft. Zwar kann man nicht alle ins Inventar holen, aber mit /setblock lassen sich alle mit einem ID_Namen setzen. Also gelten noch alle ID-Namen, die in "Datenwert" stehen. Ich habe sie bei Weizen und Melone wieder in die Artikel eingefügt. -- Sumpfhütte 20:51, 18. Feb. 2014 (UTC)

Metadaten in den Steckbriefen

In den Steckbriefen "Vorlage:Block", "Vorlage:Item" etc. wird die ID dezimal, hexadezimal und binär angezeigt. Falls zur eindeutigen Erlangung des Blockes oder Items Metadaten notwendig sind (z.B. beim Gras), kommt eine kleine hochgestellte Ziffer dazu. Das ist aber üblicherweise die Kennzeichnung für eine Fußnote. Ich habe lange nach Fußnoten gesucht, bis ich begriffen habe, dass es keine solche gibt, sondern es die Metadaten-Ziffer ist. Aus dem Steckbrief wird das nicht ersichtlich.
Da das Thema ID und Metadaten durch die vielen neuen Befehle und das neue Update 1.8 mit dem Schwerpunkt "Adventure Mapping" immer wichtiger wird, schlage ich vor, die Metadaten-Ziffer deutlicher anzuzeigen: Zusätzlich zu "dec:" und "hex:" das Wort "meta:", das genauso unterstrichen ist und einen Tooltiptext hat mit dem Inhalt "Metadaten-Ziffer", gefolgt von der Metadaten-Ziffer, die nicht mehr winzig und hochgestellt, sondern normal groß ist. Damit der Steckbrief nicht zu breit wird, würde ich stattdessen die binäre Darstellung entfallen lassen. Wozu wird die eigentlich benötigt? Die dezimale Darstellung wird für NBT-Parameter benötigt, die hexadezimale, wenn man den NBT-Explorer benutzt. Aber die binäre? Da diese meist achtstellige Info recht lang ist, wird schöner Platz frei für eine verständliche Anzeige der Metadaten-Ziffer.
Nun gibt es ja auch neuerdings die Namens-ID. Diese ersetzt in einigen Befehlen die Zahlen-ID, muss aber genauso in einigen Fällen durch eine Metadaten-Ziffer eindeutig gemacht werden. Auch da würde ich die Anzeige von "meta:" plus Ziffer dahinterstellen wollen. Da die Metadaten-Ziffer bisher schon in die Steckbriefe eingegeben wird, müsste nur die Anzeige bzw. Darstellung geändert werden, die Aufrufe können unverändert bleiben. Beispiel "Gras":

ALT		NEU
Busch: dez: 31:0 hex: 0 Gras: dez: 31:1 hex: 0 Farn: dez: 31:2 hex: 0 Grüner Busch: dez: 31:3 hex: 0		Busch: dec: 31 meta: 0 hex: 1F Gras: dec: 31 meta: 1 hex: 1F Farn: dec: 31 meta: 2 hex: 1F Grüner Busch: dec: 31 meta: 3 hex: 1F
tallgrass		Busch: tallgrass meta: 0 Gras: tallgrass meta: 1 Farn: tallgrass meta: 2 Grüner Busch: tallgrass meta: 3

Was meint ihr dazu? -- Sumpfhütte 12:35, 2. Feb. 2014 (UTC)

Hört sich gut an. Was die binären Zahlen sollen, kann ich aber auch nicht sagen.--.zip ^{de.MinecraftWiki-Admin Diskussion} 12:49, 2. Feb. 2014 (UTC)

Ich bin auch dafür. Ich würde allerdings die Binäre Zahl durch die Name-ID ersetzen und die Metadaten-Ziffer einzeln schreiben, weil die Name-ID ja eigentlich nichts andereres ist als die alte ID, sondern diese ersetzt. Außerdem werden sonst dec, hex und die nameid dauernd wiederholt. Etwas abgeändert sähe es dann so aus:

ALT		NEU
Busch: dez: 31:0 hex: 0 Gras: dez: 31:1 hex: 0 Farn: dez: 31:2 hex: 0 Grüner Busch: dez: 31:3 hex: 0		Benutzer:Elike98/Testseite
tallgrass		Busch: Benutzer:Elike98/Testseite Gras: Benutzer:Elike98/Testseite Farn: Benutzer:Elike98/Testseite Grüner Busch: Benutzer:Elike98/Testseite

-- Elike98 ^Diskussion 15:12, 2. Feb. 2014 (UTC)

Gefällt mir viel besser als mein Vorschlag. Aber es würde nur funktionieren, wenn alle Aufrufer angepasst würden (ca. 500 Seiten mit Blöcken und Items), denn der Aufrufer übergibt die Liste "Busch, Gras, Farn, Grüner Busch" an den Steckbrief. Da wäre eine Menge zu tun. Ich weiß nicht, ob man das automatisieren kann. Wenn man es automatisieren kann, dann könnte man natürlich gleich eine elegante Lösung bauen, was ich am besten fände: In "Vorlage:Datenwert" entfällt der Paramter "p=" bzw ":" (warum gibt es eigentlich zwei Varianten?) und der neue Parameter "idname=" kommt dazu; in den Steckbriefen entfällt der Parameter "idname" bzw. wird gleich umbenannt in "metadata" und erhält statt dem idnamen die Metadaten als Freitext. Dabei ist das unterstrichene Wort "meta" nicht mehr nötig, vielmehr würde dann nur die Ziffer dort stehen oder mehreren Zeilen mit Bezeichnung und Ziffer. Das macht den Freitext auch einfacher.
Ein Bot müsste nach "data", "multipledata" und "idname" suchen, aus "data" und "multipledata" die Metadaten entfernen (":" und "p=") und stattdessen die nameid einfügen, sowie "idname" in "metadata" ändern. Die Schwierigkeit liegt bei "multipledata": hier müsste aus mehreren Zeilen eine werden, die dann dafür mit denselben Zeilenumbrüchen bei "metadata" eingefügt werden müssten. Beispiel: Gras und Notenblock. Ächz. Caleb, was sagst du dazu? -- Sumpfhütte 17:19, 2. Feb. 2014 (UTC)

Puh, das klingt ja gar nicht einfach. Falls der Bot das mit multipledata nicht hinkriegt wäre es aber ja immer noch möglich, dass er die betroffenen Seiten einer Kategorie zuweist und man diese Fälle dann manuell bearbeitet, das sollten ja maximal 100 sein. Und falls das Ganze überhaupt nicht möglich wäre, könnten wir trotzdem noch die Steckbriefe so einstellen, dass sie die alten Zeilen anzeigen, bis die neuen eingegeben sind, aber beides möglich ist. Dann könnten wir die 500 Seiten auch mit der Zeit manuell umstellen, bei den Steckbriefen, bei denen nameid noch fehlt müssen die Name-IDs sowieso noch manuell eingegeben werden. Aber wenns mit dem Bot hinhaut wärs natürlich optimal :-) -- Elike98 ^Diskussion 17:59, 2. Feb. 2014 (UTC)

schluck Also das muss ich mir noch mal ganz langsam aufschreiben. Auhaueha. Da wird der Bot einiges zu parsen haben. Prinzipiell machbar ist das aber - ich hoffe nur, es eilt nicht ;) --Caleb Blackhand 15:38, 4. Feb. 2014 (UTC)

Wir hatten jetzt schon mehrfach so komplizierte Fälle (Crafting-Grids untersuchen). Daher würde ich gerne erstmal wissen über welche Mengen wir reden. Könnte der Bot bitte mal alle Artikel auswerfen, in denen das Wort "multipledata" vorkommt? Bei 30 bis 40 würde ich sagen: das ist noch manuell schaffbar. Immerhin haben wir erst kürzlich überall die nameid nachgetragen... -- Sumpfhütte 17:39, 4. Feb. 2014 (UTC)

Okay, das geht schneller. Ich lass den Bot mal zählen - oder besser, gleich mal 'ne Liste anlegen, dann kann man die (wenn's wenig ist) auch direkt abfrühstücken. --Caleb Blackhand 17:51, 4. Feb. 2014 (UTC)

Ich verweise auf Benutzer:CalebBot/Arbeitsauftrag. Man muss allerdings dabeischreiben: Es gibt da (zum Beispiel in Erde Vorkommen von multipledata, die eigentlich falsch sind, weil nur ein einziger Datensatz 'Drin' ist. --Caleb Blackhand 19:37, 4. Feb. 2014 (UTC)

Seehr schön :-) Das ist ja übersichtlich: nur ca. 60 Artikel, da haben wir schon ganz andere Mengen manuell bewältigt. Und vor allem: es gibt einige Sonderfälle, die kann man sowieso nur manuell lösen. Ich ändere jetzt mal den Block-Steckbrief als ersten. Er erhält einen neuen Parameter "metadata", der einen Freitext erwartet, wie "multipledata". Das baue ich ein bei "Erde" (einfachster Fall, multipledata ist dort übrigens drin, weil es mal zusammen mit "graslose Erde" stand) und bei "Sand" (echte multiple Daten). Die binäre Darstellung nehme ich bei der Gelegenheit auch weg, kommentiere sie aber erstmal nur aus, wer weiß... -- Sumpfhütte 20:09, 4. Feb. 2014 (UTC)

Bei den meisten Blöcken und vor bei den allem Items sind die Metadaten ja 0. Das soll auch absichtlich dort stehen, weil dieser Wert in den Befehlen angegeben werden muss, wenn man einen weiteren optionalen Parameter (meist NBT-Daten) angeben will. Nun stimmt diese Info aber nicht wirklich, denn es gibt zwar z.B. keine alternativen Falltüren, die sich in den Metadaten unterscheiden, wie Sand oder Blumen, aber Falltüren haben durchaus auch Metadaten. Ich habe daher demnächst vor, den Block-Steckbrief (später auch die anderen) nochmal zu erweitern, so dass man bei "Metadata" auch einen Link übergeben kann. Das soll die Abschnittsüberschrift im Artikel "Datenwert" sein, z.B. "#Falltür". Da "Metadata" ein Freitext ist, schreibt man dann im Falltür-Steckbrief keine Zahl rein, sondern "für die Ausrichtung". Dann steht da: "Metadata: für die Ausrichtung" und verlinkt bei Klick auf "Metadata" auf "Datenwert#Falltür". Wenn mir jemand mit der Umsetzung dieses Plans helfen könnte, wäre ich dankbar :-) -- Sumpfhütte 16:34, 5. Feb. 2014 (UTC)

Meinst du in etwa so? -- Elike98 ^Diskussion 17:51, 5. Feb. 2014 (UTC)

Man könnte dem neuen Parameter für den Link dann auch einfach standardmäßig den Seitentitel zuweisen. Falls der Abschnitt existiert, wird dann automatisch dorthin verlinkt, ansonsten gelangt man ganz normal zum Seitenanfang. -- Elike98 ^Diskussion 19:30, 5. Feb. 2014 (UTC)

Ja, prima! Aber ohne Autolink, denn es gibt zu viele Metadaten-Abschnitte, die nicht mit dem Blocknamen identisch sind. Einfach und robust. Der Aufrufer soll den Link selber angeben. Bau das doch mal beim Block-Steckbrief ein und passe die Blöcke/Items mit Metadaten an, indem du von oben durch die Datenwert-Metadaten-Abschnitte gehst und ich komme dir von unten entgegen. -- Sumpfhütte 19:59, 5. Feb. 2014 (UTC)

Eingebaut und Doku aktualisiert. Ich fang jetzt bei Stein an. -- Elike98 ^Diskussion 20:14, 5. Feb. 2014 (UTC)

Ups, ich meinte die Abschnittsüberschriften, du die IDs. IDs ist besser, also fange ich bei 175 (Große Blumen, hohes Gras) an... -- Sumpfhütte 20:21, 5. Feb. 2014 (UTC)

IDs hab ich auch nicht gemeint, sondern Spezial:Linkliste/Vorlage:Block :D Dann mach ich jetzt aber auch IDs. -- Elike98 ^Diskussion 20:24, 5. Feb. 2014 (UTC)

Nehmen wir eigentlich in einem zweiten Schritt die Name-ID mit in die normale ID hinein? Das würde die langen Listen wie bei Treppe ersparen. Bei den Blöcken ohne multipledata würde ja sogar schon eine Vorlagenabänderung reichen. -- Elike98 ^Diskussion 21:29, 5. Feb. 2014 (UTC)

Seehr gut. Die Treppen sind extrem, aber auch bei allem anderen wäre es gut, denn die nameid ist ja der Ersatz für den bisherigen Datenwert, passt also hervorragend dazu. Vorschlag: Änderung der Vorlage:Datenwert, so dass dort die nameid übergeben wird und in einer zweiten Zeile unter "dec" und "hex" angezeigt, ohne weiteres Wort. Dann (erstmal) im Block-Steckbrief Anpassung von "data": dort Übergabe der nameid an "Datenwert". Die "multipledata"-Aufrufe passen wir ja gerade manuell an, da wäre es super, wenn wir das in einem Aufwasch mit machten. -- Sumpfhütte 21:39, 5. Feb. 2014 (UTC)

Hab ich mir eben auch gedacht. Heute habe ich dafür leider keine Zeit mehr, entweder wir machen morgen weiter oder du alleine. -- Elike98 ^Diskussion 21:56, 5. Feb. 2014 (UTC)

hmm - lass mich nachdenken - morgen gemeinsam oder heute alles alleine? *denk* ... Ich wähle Option a) :-) -- Sumpfhütte 22:04, 5. Feb. 2014 (UTC)

So, alle Blöcke mit Metadaten sind von Elike98 und mir angepasst. Jetzt fehlen noch die Items mit Metadaten, das sind aber deutlich weniger, als bei den Blöcken... -- Sumpfhütte 15:38, 7. Feb. 2014 (UTC)

Erledigt. Danke Elike98 und CalebBlackhand für die Liste -- Sumpfhütte 17:50, 9. Feb. 2014 (UTC)

Grafikvorlagen: aus 14 mach 1?

Wir haben 6 Vorlagen, die Sprites von Blöcken, Items etc. anzeigen und 6 Vorlagen, die diese Sprites zusätzlich mit dem Artikel verlinken. Gestern hat eagle3000 alles auf ein einziges Lua-Modul umgestellt - Uff! Schauen wir mal, wie unsere 12 Vorlagen jetzt aussehen (plus einige weitere):

Vorlage	Inhalt
BlockLink	{{#invoke: Sprite | link| name = Block| sheetsize = 384| defaultpos = 384}}
BlockSprite	{{#invoke: Sprite | sprite| name = Block| sheetsize = 384| defaultpos = 384}}
BiomLink	{{#invoke: Sprite | link| name = Biom| image = BiomeCSS.png| sheetsize = 64| defaultpos = 28}}
BiomSprite	{{#invoke: Sprite | sprite| name = Biom| image = BiomeCSS.png| sheetsize = 64| defaultpos = 28}}
ItemLink	{{#invoke: Sprite | link| name = Item| defaultpos = 256}}
ItemSprite	{{#invoke: Sprite | sprite| name = Item| defaultpos = 256}}
ObjektLink	{{#invoke: Sprite | link| name = Objekt| sheetsize = 192| defaultpos = 144}}
ObjektSprite	{{#invoke: Sprite | sprite| name = Objekt| sheetsize = 192| defaultpos = 144}}
EffektLink	{{#invoke: Sprite | link| name = Effekt| image = EffectsCSS.png| sheetsize = 288| size = 18| defaultpos = 256}}
EffektSprite	{{#invoke: Sprite | sprite| name = Effekt| image = EffectsCSS.png| sheetsize = 288| size = 18| defaultpos = 256}}
UmweltLink	{{#invoke: Sprite | link| name = Umwelt| image = EnvCSS.png| sheetsize = 128| defaultpos = 64}}
UmweltSprite	{{#invoke: Sprite | sprite| name = Umwelt| image = EnvCSS.png| sheetsize = 128| defaultpos = 64}}
KommentarSprite	{{Sprite|name=Kommentar|pos={{{1|}}}|image=CommentCSS.png|sheetsize=48}}
Sprite	{{#invoke:sprite|base}}

Da taucht sofort die Idee zu einer Zusammenfassung auf: Wir könnten auf einen Schlag 14 Vorlagen gegen 1 tauschen. Der jetzige Zustand ist wegen der mehrfachen Verschachtelung kaum durchschau- und daher schwer wartbar. Das würde sich zu unserem großen Vorteil ändern. Beispiel: "Stub" benutzt "Hinweis" benutzt "KommentarSprite" benutzt "Sprite" benutzt "Modul:Sprite" - um ein kleines "i" im blauen Kreis anzuzeigen.

Ich habe noch nicht herausfinden können, wo "Vorlage:Sprite" sonst noch eingesetzt wird. Erstmal die Frage: was haltet von einer Zusammenfassung aller Sprite-Vorlagen auf eine, z.B. so: {{Sprite|BL|...}}, {{Sprite|BS|...}}, {{Sprite|IL|...}}, {{Sprite|IS|...}}, {{Sprite|KS|...}} etc.? -- Sumpfhütte 17:35, 3. Feb. 2014 (UTC)

Klare Frage: Was bringts? Meiner Meinung nach nichts. Ob ich jetzt {{BS|...}} schreibe oder {{Sprite|BS|...}} ... eigentlich ist ersteres deutlicher, und letzteres schreibaufwändiger. Und Wartungsaufwand ist das jetzt mit den 14 Vorlagen nun nicht SO sehr, dass die Vereinheitlichung wirklich lohnt. --Caleb Blackhand 17:59, 3. Feb. 2014 (UTC)

PS: Das gilt jetzt nicht für die Vorlagen, die ihrerseits dann wieder Vorlage:Sprite verwenden - DIE könnte man mal der Einheitlichkeit wegen auf das Modul umbiegen. --Caleb Blackhand 18:00, 3. Feb. 2014 (UTC)

Ja, ich war mir auch unsicher - daher die Frage hier im GP. Die Vereinheitlichung von z.B. KommentarSprite werde ich aber mal angehen. Ergebnis:

• "KommentarSprite" ruft jetzt "Modul:Sprite" direkt auf, wie alle anderen Sprite-Vorlagen auch.
• "NBT/sprite" heißt jetzt "NBTSprite", wie alle anderen Sprite-Vorlagen auch.
• Die Seite "Hilfe:Bearbeiten" ruft die neue Vorlage "HilfeSprite" auf und nicht mehr die Vorlage "Sprite".
• Vorlage "Sprite" ist gelöscht.

Es folgen dann noch ein paar Aufräumarbeiten... -- Sumpfhütte 00:35, 4. Feb. 2014 (UTC)

Barriere-Sprite fehlt

Die Barriere ist nicht zu sehen (sic) - In Datei:ItemCSS.png ist sie drin. Weil sie schon beim 1. Hochladen plötzlich fehlte, war ich unsicher und lud ein 2. Mal hoch. Sie fehlte wieder, war nun aber in der Vorversion drin. "action=purge" bricht mit Timeout ab. In der Vorlage:Navbox-Baumaterial ist sie nicht zu sehen, in der Liste der Vorlage:ItemSprite (Nr. 163) auch nicht. Cache leeren oder Browser neustarten nützt nichts. Also vermutlich ein MediaWiki-Problem, d.h. einfach warten, oder? -- Sumpfhütte 15:46, 5. Feb. 2014 (UTC)

In der aktuellen Version der Datei ist die Barriere nicht zu sehen. Eventuell nochmal hochladen?--.zip ^{de.MinecraftWiki-Admin Diskussion} 10:21, 6. Feb. 2014 (UTC)

??? Ich habe die Datei nun zum 3. Mal hochgeladen. Die Barriere ist nicht zu sehen, aber jedesmal ist sie beim erneuten Hochladen in der vorigen Version zu sehen, obwohl sie dort vor dem Hochladen nicht zu sehen war - ??? -- Sumpfhütte 11:03, 6. Feb. 2014 (UTC)

Es scheint so, als ob zwar die Größe des hochgeladenen Bildes übernommen wird, aber nicht der Inhalt. Ich habe mal ein andersformatiges Testbild hochgeladen. Der Inhalt ist immer nur beim vorigen Bild richtig, nicht beim aktuellen. Man kann auch nicht das letzte Hochladen rückgängig machen, nur das vorige. Nun wollte ich das Bild einfach nach "ItemCSS-alt.png" verschieben und ein frisches hochladen, aber das Verschieben geht auch nicht wegen Timeout. Werden wir nie wieder ItemCSS.png ändern können? -- Sumpfhütte 12:26, 6. Feb. 2014 (UTC)

Ich habe den Seitenschutz entfernt - hat auch nichts genützt. Ich habe nochmal versucht, sie zu verschieben - das hat MediaWiki nur zur Hälfte gemacht, bevor es mit Timeout abbrach. Dann hieß es: "Datei nicht vorhanden". Ich habe sie neu hochgeladen und... SIE IST IMMER NOCH ALT! Das gibt's doch nicht! MediaWiki will einfach keine neue Version akzeptieren. Durch die Verschiebung ist allerdings die Datei "ItemCSS-alt.png" entstanden mit nur einer Version (obwohl ich alle Versionen verschoben habe). Und diese Datei wird endlich richtig angezeigt. Leider unter falschem Namen... -- Sumpfhütte 12:51, 6. Feb. 2014 (UTC)

Jetzt habe ich "ItemCSS-alt.png" gelöscht und dafür "ItemCSS-neu.png" hochgeladen. Jetzt muss man nur noch Modul:Sprite umprogrammieren auf den neuen Namen. Lustig, dass das ausgerechnet bei dem Item "Barriere" passiert. Hm - nee, doch nicht lustig das ganze :( -- Sumpfhütte 13:07, 6. Feb. 2014 (UTC)

So, alles ist auf "ItemCSS-neu.png" umgebogen. Merkwürdig und unschön. -- Sumpfhütte 14:29, 6. Feb. 2014 (UTC)

Geht. --eagle3000 ^{(D ~ B)} 16:56, 6. Feb. 2014 (UTC)

Aha, du hast die Datei auch nochmal hochgeladen. Hm - schau an, dieselbe Datei, die davor auch schon drin war (mit Barriere). Seltsam... -- Sumpfhütte 17:20, 6. Feb. 2014 (UTC)

Entwicklungsversion-Änderungen manchmal genauer kennzeichnen können

Minecraft wird ständig weiter entwickelt und das Wiki wird ständig daraufhin angepasst. Problem dabei ist die Vermischung von "aktuell" und "neu". Für beide Versionen gibt es Leser, also sollten beide Infos in den jeweiligen Artikeln stehen. Die Lösung eines eigenen Abschnitts für neue Funktionen und Eigenschaften liegt auf der Hand, hat aber einen entscheidenden Nachteil: es wird nicht gekennzeichnet, was zukünftig entfallen wird.

Man könnte daher erstmal nur sammeln und nicht einarbeiten. Wochenlang. Dann müssten aber mit dem Tag der Veröffentlichung Dutzende von Artikeln gleichzeitig und möglichst schnell überarbeitet und aktualisiert werden. Das wäre zuviel auf einmal für die geringe Anzahl an Autoren, die wir haben (es gibt viele Helfer, die Rechtschreibfehler beseitigen, aber nur sehr wenige Autoren). Das zeitnahe Einarbeiten von Änderungen streckt nicht nur den Gesamtaufwand über viele Wochen, wodurch er bewältigbar bleibt, sondern hält das Wiki auch ständig aktuell für die vielen Entwicklungsversionsspieler, die es gibt. Daher bin ich für zeitnahe Einarbeitung in die Artikel.

Aber wie trennen wie die Info? Dass eine Trennung notwendig ist, steht außer Frage, das "wie" ist die Schwierigkeit. Vorschlag:

• Bei neuen Artikeln ("Granit") kein Problem: alles ist neu. Vorlagenhinweis drüber und fertig.
• Bei kompakten Neuerungen (neues Crafting-Rezpet) auch kein Problem: Vorlagenhinweis über den Abschnitt.
• Schwierig sind jedoch die Änderungen, die alte Zustände ersetzen, wie z.B. - und daher komme ich natürlich drauf - die Anzahl Rotationen im Rahmen: vorher 4, jetzt 8. Das ist aber noch gar nichts im Vergleich zu den Änderungen an der Anzeigetafel. Ich habe über den Einsatz der "Vorlage:Hinweis" nachgedacht, aber die ist immer noch zu klobig, wenn es nur um einzelne Sätze geht, die zukünftig gelöscht werden müssen oder hinzukommen. Man könnte daher in solchen - zum Glück eher seltenen - Fällen eine neue Vorlage verwenden, die feiner nutzbar ist, als nur für ganze Abschnitte, nämlich für einzelne Sätze.

Ich habe ein Beispiel gemacht, schaut euch mal die Anzeigetafel an. Grün unterlegt ist NEU, rot unterlegt ist ALT (d.h. dieser Text wird demnächst gelöscht). Die "Vorlage:Entwicklungsversion", die weiterhin über dem Artikel steht, würde dann natürlich entsprechend angepasst werden und auf die Farbmarkierungen hinweisen. Die Markierungen würden den Artikel wie die "Vorlage:Entwicklungsversion" der Kategorie "Zukunft" zuordnen, damit man sie schnell finden und umbauen kann, wenn es soweit ist.

Was haltet ihr davon? -- Sumpfhütte 16:49, 17. Feb. 2014 (UTC)

Nachtrag: so etwas gibt es übrigens schon im Artikel "Datenwert": neue werden orange markiert. -- Sumpfhütte 16:56, 17. Feb. 2014 (UTC)

Farblichen Markierungen innerhalb eines Fließtextes gegenüber bin ich etwas skeptisch. Mich würde das beim "normalen" Lesen stören. Und wirklich esthetisch ist das auch nicht. Als Lösung gefällt mir persönlich, wie schon ein paar mal praktiziert, die Variante mit eigenen Abschnitten besser. So wäre alles sauber getrennt und sofort ersichtlich, was ist, was kommt und eventuell was entfällt.--.zip ^{de.MinecraftWiki-Admin Diskussion} 17:38, 17. Feb. 2014 (UTC)

Wie würdest du das bei "Anzeigetafel" lösen? Da entfallen einzelne Sätze. -- Sumpfhütte 17:40, 17. Feb. 2014 (UTC)

Oder bei den "Spielerdaten"? Da kommen einzelne NBT-Parameter irgendwo in der Baumstruktur hinzu. Wie könnte man das in einem eigenen Abschnitt beschreiben, so dass es jemand Wochen später richtig einarbeitet? -- Sumpfhütte 17:46, 17. Feb. 2014 (UTC)

Auf entfallende Features o.ä. würde ich wie gesagt in diesem Abschnitt hinweisen. Mit dem neuen Update wird dieser Abschnitt dann in den Haupttext integriert und die (erst dann) veralteten Sätze entfernt. Bei den "Spielerdaten" oder ähnlichen Seiten könnte man meiner Meinung nach auch Ausnahmen machen. Meine vorherigen Aussagen bezogen sich auf Fließtexte. Hier in der Baumstruktur könnte der Eintrag im Hauptteil mit Vermerk integriert sein. Aber auch ein Hinweis in einem eigenen Abschnitt fände ich nicht so schlimm. --.zip ^{de.MinecraftWiki-Admin Diskussion} 18:00, 17. Feb. 2014 (UTC)

Es geht nicht um entfallende Features, sondern um entfallende Sätze. Wie erkennt man diese in ein paar Wochen? Ich weiß nicht, wie ich in "Anzeigetafel" in einem eigenen Abschnitt sagen soll, dass in dem Abschnitt "Punktestand ändern" der Rest der Absatzes, der mit dem Satz "Oder man kann..." beginnt bis zum Ende des Absatzes zukünftig entfallen wird. Daher die Idee mit den Farben. Aber du hast Recht: Farben wären ungewöhnlich, die gibt es in den anderen Wikis auch nicht. Bei der Suche nach einer Alternative stieß ich auf die vielen "Seit Version 123"-Sätze. Wahrscheinlich hat man damit solche einzelnen Sätze markiert. Man müsste diese Einleitungen jetzt nur noch am Tag des Versionwechsels schnell finden und die Artikeltexte anpassen können. Das hat man bisher nicht gemacht, daher ist das Wiki noch voll solcher Hinweise. Daher...
Neuer Vorschlag: zusätzlich zu dem eigenen Absatz für neue Funktionen, den ich gut finde und der auch in den meisten Fällen ausreicht, gibt es eine neue Vorlage, die nicht mit Farben, sondern mit Worten markiert. Konkret: "Ab Version 1.8..." und "Bis Version 1.8..." als zwei Markierungen für schwierige oder integrierte Formulierungen. Besonderheit: weil es Vorlagen wären, würden sie eine Kategorie setzen, die das Auffinden ermöglicht. Wie wäre diese Lösung? Wie gesagt nur für Einzelfälle. Und so könnte man auch NBT-Tags in der Baumstruktur lassen und markieren. -- Sumpfhütte 18:21, 17. Feb. 2014 (UTC)

Wenn ich auch dazu was sagen darf, ich finde die Idee von "Seit der Version 1.8" oder "Bis zur Version 1.8" richtig gut. Mir fällt dazu aber noch was ein, wenns machbar wäre, könnte man sich eine Vorlage sparen und zwar so: Man belegt die Vorlage (falls das geht) mit einer Funktion bei der man (wie bei der Versionsgeschichte die PE Funktion) entscheidet ob die Vorlage "Bis" oder "Seit" heißen soll. Nur ein Tipp. Nethonos (Diskussion) 18:31, 17. Feb. 2014 (UTC)

Der Nachteil dabei ist, dass optisch nicht ersichtlich ist, ob es ein neues oder altes Feature ist. Es müsste der ganze Text gelesen werden. Ein Spieler, der die aktuelle Vollversion spielt, möchte nicht von zukünftigen Inhalten verwirrt werden. Ander herum möchte ein Entwicklungsversionsspieler auf einem Blick sehen, was sich wie ändert und dabei vermutlich nicht noch einmal den gesamten Text lesen. In einem eigenen Abschnitt wäre das wie gesagt ersichtlich. Bei übersichtlichen Seiten würde man alle Informationen, welche durch das neue Update widersprüchlich geworden sind, finden und entfernen können. Bei etwas längeren Seiten(Anzeigetafel) sieht das anders aus. Dazu könnte man aber eine unsichtbare Vorlage erstellen, welche auf Abschnitte mit Änderungsbedarf hinweisen. (Mit Kategorisierung und Verweis auf die genaue Textstelle). --.zip ^{de.MinecraftWiki-Admin Diskussion} 18:42, 17. Feb. 2014 (UTC)

Den Nachteil habe ich nicht verstanden. Es ist doch optisch ersichtlich. Schau bitte mal auf Anzeigetafel, ich habe das gerade nochmal geändert. Was könnte ich dort noch besser machen? (Ich habe übrigens Askons Vorschlag berücksichtigt und nur eine Vorlage verwendet.) -- Sumpfhütte 18:49, 17. Feb. 2014 (UTC)

Jemand der sich mit der Anzeigetafel auskennt und sich nur über die Neuerungen der Entwicklungsversionen informieren möchte, müsste sich hier zum Beispel die Informationen selber aus dem Text herausarbeiten. Zumindest den Teil, der nicht im Abschnitt "Neuerungen" steht. Würde ich micht über etwas informieren wollen, hätte ich vermutlich keine Lust, einen Artikel, den ich schon kenne, nochmals durchzulesen. --.zip ^{de.MinecraftWiki-Admin Diskussion} 20:26, 17. Feb. 2014 (UTC)

Ich verstehe was du meinst, aber jemand der sich mit der Anzeigetafel auskennt und sich nur über die Neuerungen der Entwicklungsversionen informieren möchte, schaut ganz einfach in den Artikel "Vollversion 1.8". Dort stehen gebündelt alle Neuerungen. Hier geht es um eine andere Zielgruppe. Es geht um Leser, die Detailinfos benötigen. Das Wiki als Lexikon informiert ja gerade über Details. Stell dir zwei Personen vor, der eine hat 1.7, der andere hat 14w07a. Beide bauen gerade an ihrer Welt und möchten ganz konkret wissen, wie man den Punktestand einer Anzeigetafel anzeigt. Beide finden ihre jeweilige Information sauber gekennzeichnet im Abschnitt "Punktestand anzeigen". Insbesondere ist es für den Leser mit 1.7 sehr interessant, dass dort steht "Wird mit Version 1.8 entfallen", denn dann wird er nicht mehr so viel Aufwand in sein Problem investieren.
Ich bin gerade am Prüfen der bisherigen 1.8-Neuerungen. Eieiei, da wurde bisher kaum auf eine Trennung geachtet. Jetzt gibt es in vielen Artikeln einen Abschnitt "Neuerungen". Das ist wichtig, aber darum geht es hier gar nicht. Hier geht es um Artikel wie "Befehl", "Chunkdaten", "Spielerdaten", "Level Format", "Ressourcenpaket", "Server.properties", "Speicherung" etc. die alle nur Änderungen in einzelnen Sätzen haben, die ich mit einer kleinen Markierung versehen möchte, statt wie bisher einfach pauschal "In diesem Artikel ist etwas neu" drüberzusetzen. -- Sumpfhütte 20:45, 17. Feb. 2014 (UTC)

Was hältst du von einem Symbol, ähnlich denen von Vorlage:KommentarSprite (Fragezeichen), die im entsprechenden Abschnitt/Am Ende des Satzes angebracht werden und beim Überfahren weitere Informationen bieten? Das würde nicht viel Platz wegnehmen und trotzdem einige Informationen bieten können. Das wäre ein Vorteil gegenüber den farblichen Markierungen.--.zip ^{de.MinecraftWiki-Admin Diskussion} 16:42, 19. Feb. 2014 (UTC)

Mein Ziel war, einzelne Sätze kennzeichnen zu können. Ich finde die dezente gelbe Farbe (die man auch noch weiter abschwächen könnte) prima, weil sie aussieht, wie ein Markerstift. Und die drei Worte nehmen nun wirklich keinen nennenswerten Platz weg. Aber solange dasselbe Ziel erreicht wird, ist mir der Weg egal, d.h. zwei Symbole (eins für "entfällt" und eins für "neu") mit Tooltips wären auch okay. Sie sollten allerdings am Anfang des Satzes stehen, wie jetzt die Worte auch, denn dann kann man alle Artikel so lassen wie sie sind, und muss nur die Vorlage ändern.
Ich habe es gerade mal ausprobiert, aber ich habe nur eine komplizierte Lösung gefunden, wie es funktionieren könnte: Da wir offensichtlich die WikiMedia-Extension "Tooltip" nicht haben, funktionieren Tooltips nur zusammen mit einem Link. Wir müssten also zwei Weiterleitungen anlegen namens "Entfällt mit 1.8" und "Neu mit 1.8" auf die "Vollversion 1.8". Dann bräuchten wir zwei Symbolbilddateien (die Kommentarsprites können wir nicht nutzen, weil die nicht im Dateinamensraum liegen), die wir einbinden und auf die Weiterleitungen verlinken würden. Beispiel: . Das einzige Problem was ich damit habe, ist, dass ich nicht sicher bin, ob man Tooltips individuell abschalten kann. Wenn dem so wäre, wären die Symbole für solche Leser völlig unverständlich und die drei Worte dann doch besser geeignet. Was meinst du? -- Sumpfhütte 17:31, 19. Feb. 2014 (UTC)

Ich hatte mir das eigentlich ganz einfach mit HTML vorgestellt. Nur leider ist der <img>-Tag im Wiki nicht zulässig: <img src="http://hydra-media.cursecdn.com/minecraft-de.gamepedia.com/e/ee/Grid_Grasblock.png" title="Erklärender Text"> Das ist aber mit der Wiki-Einbindung, auch ohne Verlinkung, machbar: Das Bild würde dann auf die eigene Seite verlinken. Um das zu verhindern könnte man auf die 1.8 verlinken. Solange es dort jedoch keine zwei verschiedenen Abschnitte gibt, braucht man auch keine zwei Weiterleitungen. Google hat bestätigt: Unter Firefox kann man die Tooltips auf jeden Fall abschalten. --.zip ^{de.MinecraftWiki-Admin Diskussion} 18:40, 19. Feb. 2014 (UTC)

Ach so, einfach so: ? Schick. Aber was sagst du zu der Firefox-Abschaltbarkeit? Was würdest du machen, wenn du die Symbole ohne Tooltip siehst? Würde dir ein Hinweis auf den Hilfeseiten reichen? -- Sumpfhütte 18:56, 19. Feb. 2014 (UTC)

Geschichte-Stubs

Hallo Miner, ich bin relativ neu und setze alles daran unbekannte oder überholte Daten neu zu verfassen. Dabei ist mir aufgefallen das bei fast allen Stubs die als solche angezeigt werden, nur die Geschichte fehlt! Deswegen bitte ich euch um eure Unterstützung bei der Aufgabe diese Inforamationen zu ergänzen. Londigger00 (Diskussion) 15:43, 24. Feb. 2014 (UTC)Londigger00 :)

Abschnitt nach unten verschoben. ILeon ᐸ Diskussion
Beiträge - de.Wiki Admin 15:51, 24. Feb. 2014 (UTC)

neues Steinstufenrezept

Ein Benutzer hat heute darauf aufmerksam gemacht, dass Steinstufen auch aus Diorit hergestellt werden können. Ich habe das getestet und gemerkt, dass alle Kombinationen aller Steine möglich sind: Stein, Granit, Diorit, Andesit, poliert und unpoliert. Das könnte man für einen Bug halten. Es wurde auch im Bugtracker gemeldet. Aber es ist Absicht, denn z.B. Knöpfe können nicht mit allen Steinen hergestellt werden. Also habe ich bei Diorir, Andesit, Granit, Stein und Crafting/Zukünftiges das neue Rezept hinzugefügt. Das Rezept erlaubt eine beliebige Kombination, nicht nur Granit. Daher hat meine Version das reale Rezept gezeigt. Die Veränderung von Askon + ILeon haben es verändert. Frage: wie wollen wir es machen? Und wenn, dann bitte auf allen genannten Seiten einheitlich. -- Sumpfhütte 19:08, 28. Feb. 2014 (UTC)

Ich mache die beiden Änderungen erstmal wieder rückgängig, damit alle 5 Artikel wieder einheitlich sind. -- Sumpfhütte 20:01, 28. Feb. 2014 (UTC)

Ich wäre dafür, dass die Gesteinsarten nur jeweils auf ihrer Seite vorhanden sind, wärend es bei der Seite "Stufe" dann eine Zusammenfassung aller Steinarten im Craftingrezept gemacht wird. Nethonos (Diskussion) 00:41, 1. Mär. 2014 (UTC)

Ich auch. Wer sich z.B. Diorit durchliest, möchte vor allem wissen, was er mit diesem Stein anfangen kann, da würden die anderen Gesteinsarten eher verwirren. Wer aber wissen will, wie er eine Stufe bauen kann, schaut nicht bei Diorit, sondern bei Stufe. -- Elike98 ^Diskussion 09:06, 1. Mär. 2014 (UTC)

Okay. Erledigt. -- Sumpfhütte 09:49, 1. Mär. 2014 (UTC)

Modseiten aus ftbwiki.org hier im Wiki

Wie auch auf meine Benutzerseite zu sehen, bin ich ein Admin der FTB-Wiki unter ftbwiki.org. Diese Wiki besitzt derzeit fast 5000 Seiten ausführliche Informationen zu FTB-Modpacks und enthaltene Mods. Für Vanilla-Items verweisen wir grundsätzlich auf eure Wiki und ergänzen auf unsere Seite nur durch FTB hinzugekommene Informationen.

Meine Frage ist nun, ob wir im Gegenzug bei FTB-Items und -Seiten auf ftbwiki.org verweisen können, sodass wir die Seiten nicht doppelt pflegen müssen. Das Ganze in der Form, dass eure Wiki eine kurze Beschreibung beinhalten würde, für Rezepte/Verhalten/Verwendung aber auf ftbwiki verweisen würde, die kurze Beschreibung auch in dem Hinblick, dass die FTB-Wiki derzeit nur auf Englisch existiert.

Ein (vielleicht nicht gerade perfektes) Beispiel hab ich mal unter https://minecraft-de.gamepedia.com/Benutzer:Thaxllssillyia/Kupfererz abgelegt. Vertägt eventuell noch etwas Style.

Danke für eine Rückmeldung! Thaxllssillyia (Diskussion) 09:54, 3. Mär. 2014 (UTC)

Doppelte Informationshaltung bedeutet immer doppelte Pflege und doppelte Fehleranfälligkeit. Da gibt es im deutschen MC-Wiki genügend schlechte Beispiele. Von daher bin ich ein Fan der Verlinkung, d.h. mir gefällt der Vorschlag. Schwierig wird vielleicht nur die Entscheidung zu treffen, was auf Deutsch stehen bleiben soll und wo ein Verweis ins englische FTB-Wiki ausreicht. FTB ist ja ein Mod-Pack. Hier im MC-Wiki sind davon folgende Mods betroffen:

• Mod/Feed_the_Beast_lite <<< Baustelle von Benutzer:Johnny JayJay, letzte Änderung im August 2013
• Mod/ComputerCraft <<< Baustelle von Benutzer:Violine1101, letzt Änderung im September 2013
• Mod/BuildCraft <<< {{Unvollständig}}
• Mod/Inventory Tweaks
• Mod/Minecraft Forge
• Mod/Railcraft <<< {{Unvollständig}}
• Mod/Rei's Minimap
• Mod/Twilight Forest
• Mod/Thaumcraft 3 <<< {{Unvollständig}}

Heißt das, alle diese Seiten würden angepasst? Thaxllssillyia, du kennst dich doch sehr gut in dem Thema aus. Würdest du diese Seiten auf den neuesten Stand bringen, die Auswahl (was bleibt, wo reicht ein Verweis) treffen und die Verweise einbauen?
Innerhalb des MC-Wikis haben wir für solche Verweise die Vorlage:Hauptartikel. Ich könnte mir gut vorstellen, dass man eine ähnliche Vorlage für Verweise ins englische FTB-Wiki erstellt. Thaxllssillyia, könntest du einen Vorschlag machen, wie so eine FTB-Verweis-Vorlage aussehen könnte? Was meinen die anderen dazu? -- Sumpfhütte 12:04, 3. Mär. 2014 (UTC)

Ich sehe da einige Probleme: Das von dir genannte inoffizielle Feed The Beast Wiki ist nur auf englisch vorhanden. Nicht jeder spricht fließend englisch. Die deutsche Community kann bei dem Vorhaben nur verlieren. Außerdem ist Feed The Beast ein Modpack, welches aus mehreren Modifikationen besteht, die auch unabhängig voneinander verwendet werden können. Deswegen sollten auch ihre eigenen Seiten bestehen bleiben. --.zip ^{de.MinecraftWiki-Admin Diskussion} 12:17, 3. Mär. 2014 (UTC)

Danke für die schnellen Rückmeldungen. Zur Status inoffiziell: Ja, wir sind die sogenannte inoffizielle FTB-Wiki. Sie ist aus dem Grund entstanden, dass es Differenzen mit der offiziellen bezüglich Design, Struktur und Leitung gab. Des weiteren ist die offizielle FTB-wiki vom Inhalt deutlich hinter unserer zurück, weshalb auch schon die Admins der offiziellen uns angefragt haben, ob wir unseren Inhalt auf ihre Seite migrieren (abgelehnt).

Das mit der Sprache ist natürlich nachvollziehbar. Problem ist halt immer, dass durch jede weitere Sprache der Pflegeaufwand exponentiell steigt. Dazu möchte ich auch sagen, dass nicht immer unbedingt Top-Englischkenntnisse vorrausgesetzt werden, um so eine Seite zu lesen, auch aufgrund der Crafting/Usage-Bilder und Verlinkung.

Wenn ihr für die deutsche Minecraftwiki den Vorschlag ablehnt, kann ich dass schon nachvollziehen, für die englische wärs vielleicht eine Idee.-- Thaxllssillyia (Diskussion) 07:08, 4. Mär. 2014 (UTC)

.zip hat Recht mit dem Hinweis auf das Sprachproblem. Auch ich habe darauf hingewiesen. Allerdings glaube ich nicht, dass deutsche Community bei dem Vorhaben grundsätzlich nur verlieren kann. Es kommt darauf an, wie wir "das Vorhaben" definieren, um einen Gewinn daraus zu machen. Wie ich oben aufgelistet habe, haben wir in den betroffenen Mod-Seiten zwei verwaiste Baustellen und drei Stubs. Es gibt also große Lücken im MC-Wiki. Wenn die Artikel Links in das FTB-Wiki für weitergehende Infos hätten, wäre das durchaus ein Gewinn für den Leser. Wir haben ja auch Links ins englische (und die anderen) MC-Wikis. Daher könnte ich mir gut eine Hinzufügung von Links vorstellen, dann aber ohne Verkürzung der Artikel. Dabei zu beachten wäre, dass es auch für andere Mods eigene Wikis gibt und auch zu diesen sollte man verweisen dürfen. Das heißt, alle Mod-Wikis sollten gleich behandelt werden. Es könnten dann z.B. bei ComputerCraft drei Verweise stehen: in das ComputerCraft Wiki, in das inoffizielle FTB-Wiki, das ComputerCraft enthält und in die ComputerCraft-Seite des offiziellen FTB-Wikis. -- Sumpfhütte 09:54, 4. Mär. 2014 (UTC)

Ich stimme dir zu, Sumpfhütte. Ich habe mich an der Verkürzung der Artikel gestört. Links können wir gerne nennen. --.zip ^{de.MinecraftWiki-Admin Diskussion} 10:19, 4. Mär. 2014 (UTC)

Twitteraccount der deutschen Minecraft Wiki

Ich möchte euch mal den Twitteraccount der deutschen Minecraft Wiki vorstellen. Dort findet ihr immer aktuelle Informationen rund um Minecraft und um das Wiki. Momentan besitzt der Account noch nicht viele Follower, deshalb würde ich mich freuen, wenn wir durch eure Hilfe einpaar dazu gewinnen könnten. Empfehlt diesen Twitteraccount vielleicht euren Minecraft-Freunden weiter, oder werdet selber Follower. :) Verbesserungsvorschläge werden auch gerne gesehen. Der Twittername lautet MinecraftWikiDE und ist unter diesem Link zu erreichen: https://twitter.com/MinecraftWikiDE ILeon ᐸ Diskussion
Beiträge - de.Wiki Admin 12:47, 15. Mär. 2014 (UTC)

Den verwaltest du, oder? Suchti ^{Diskussion Mail} 13:04, 15. Mär. 2014 (UTC)

Ja :) ILeon ᐸ Diskussion
Beiträge - de.Wiki Admin 13:07, 15. Mär. 2014 (UTC)

Ich finde die Idee prima, auf das Wiki aufmerksam zu machen und vielleicht neue Autoren zu gewinnen. Ich stelle den Link mal in die Sidebar. Ist unser Bürokrat informiert? -- Sumpfhütte 13:13, 15. Mär. 2014 (UTC)

Habt ihr Verbesserungsvorschläge? Wie findet ihr das Profildesign? ILeon ᐸ Diskussion
Beiträge - de.Wiki Admin 14:28, 15. Mär. 2014 (UTC)

Das Profilbild ist an den Seiten etwas abgeschnitten. Das würde ich auf jeden Fall ändern und bei der Gelegenheit vielleicht das "richtige" Wiki-Logo verwenden. (Tulpen entfernen)--.zip ^{de.MinecraftWiki-Admin Diskussion} 14:51, 15. Mär. 2014 (UTC)

Was haltet ihr davon, auf der Hauptseite folgendes einzubetten? Benutzer:Xzipx/Testseite Wahrscheinlich hast du, Leon das gleiche oder etwas ähnliches mit Widget:Twitter vorgehabt? --.zip ^{de.MinecraftWiki-Admin Diskussion} 15:27, 15. Mär. 2014 (UTC)

Schick! Aber wo auf der Hauptseite? Und - äh - was sagt Curse dazu ("das engl. Wiki"™) ? -- Sumpfhütte 16:20, 15. Mär. 2014 (UTC)

Ich hätte es irgendwo auf der rechten Seite platziert. Eine genaue Aufteilung müsste man sich noch überlegen. Curse muss natürlich auch noch gefragt werden, wollte aber erst mal hier Meinungen einholen. --.zip ^{de.MinecraftWiki-Admin Diskussion} 16:24, 15. Mär. 2014 (UTC)

Find ich gut. Bei mir hat das Widget nicht funktioniert. Kann jemand von euch Curse mal Fragen? Ich glaube meine Englischkenntnisse sind nicht die besten. :) ILeon ᐸ Diskussion
Beiträge - de.Wiki Admin 17:27, 15. Mär. 2014 (UTC)

Bevor wir uns an Curse wenden: Ist der Account eigentlich mit Wissen von Curse erstellt worden, oder eigentlich unoffiziell? --.zip ^{de.MinecraftWiki-Admin Diskussion} 17:39, 15. Mär. 2014 (UTC)

Ohne aber ich denke, dass ist kein Problem. ILeon ᐸ Diskussion
Beiträge - de.Wiki Admin 17:47, 15. Mär. 2014 (UTC)

Mail wurde verschickt und an euch beide weitergeleitet --.zip ^{de.MinecraftWiki-Admin Diskussion} 18:10, 15. Mär. 2014 (UTC)

Ich hatte oben schon gefragt: "Ist unser Bürokrat informiert?" - ILeon hat nicht geantwortet. Es wäre nett, wenn ILeon ihm einen kurzen Hinweis z.B. in die Diskussion stellt, damit er nicht aus allen Wolken fällt, falls er von Curse angesprochen wird. Außerdem hatte er ja auch Ideen zum Ändern der Hauptseite, Stichwort "Film einbinden". -- Sumpfhütte 18:16, 15. Mär. 2014 (UTC)

Super danke! ILeon ᐸ Diskussion
Beiträge - de.Wiki Admin 18:17, 15. Mär. 2014 (UTC)

Sorry, hab das wohl überlesen. Hab ihn jetzt mal informiert. ILeon ᐸ Diskussion
Beiträge - de.Wiki Admin 18:22, 15. Mär. 2014 (UTC)

Ja das Video auf der Startseite... Da sagst du was. ^^ Aber hierzu: Der Account ist aus meiner Sicht ok, nur auf der Startseite ist es eher fehlplatziert. (Designmäßig wie auch Platzmäßig) Der Link links sollte ausreichen. Aber vielleicht will ja jemand wie beim Video mal einen Vorschlag machen, so lässt sich das besser vorstellen. -- Oliver Scholz - Wiki Admin 18:38, 15. Mär. 2014 (UTC)

Im Gemeinschaftsportal kann man diesen Twitterfeed bestimmt auch gut unterbringen. ILeon ᐸ Diskussion
Beiträge - de.Wiki Admin 18:47, 15. Mär. 2014 (UTC)

So wie hier beispielsweise. ILeon ᐸ Diskussion
Beiträge - de.Wiki Admin 18:58, 15. Mär. 2014 (UTC)

Was sagt ihr dazu? ILeon ᐸ Diskussion
Beiträge - de.Wiki Admin 08:47, 16. Mär. 2014 (UTC)

Falls das mit der Hauptseite nichts werden sollte, ist das Gemeinschafts-Portal die richtige Stelle. Die Position rechts oben auf der Seite passt prima - und passt zum Mojang-Blog, wo es genauso ist. -- Sumpfhütte 09:16, 16. Mär. 2014 (UTC)

Wie es aussieht hat Wyn nix dagegen. Ich bin trotzdem der Meinung, es ist zu groß für die Startseite. Hier beim Gemeinschafts-Portal sieht es viel, viel besser aus. Wem willst du denn noch alles Zugang zum Account geben? -- Oliver Scholz - Wiki Admin 10:51, 16. Mär. 2014 (UTC)

Das Widget kann auch noch verkleinert werden, das wäre nicht das Problem. Ich wäre dafür, allen Admins Zugang zum Account zu gewähren. Und wie verlangt auch Wynthist.--.zip ^{de.MinecraftWiki-Admin Diskussion} 11:51, 16. Mär. 2014 (UTC)

Ja, finde ich gut. Werde ich demnächst machen. ILeon ᐸ Diskussion
Beiträge - de.Wiki Admin 12:23, 16. Mär. 2014 (UTC)

Leon, mal ne blöde Frage. Ich kann durch mein Tweetdeck beobachten, wem du so folgst mit dem Account... kannst du mir/uns sagen, nach welchen Kriterien das passiert? :D --Drachin  ♥ ^(Disk) 19:12, 16. Mär. 2014 (UTC)

Naja, ich suche mir vor allem die raus, die an Minecraft interessiert sind, und folge denen dann. Damit eben viele Follower gewonnen werden können. ILeon ᐸ Diskussion
Beiträge - de.Wiki Admin 19:16, 16. Mär. 2014 (UTC)

Ich frage nur, weil du nicht ZU vielen Leuten folgen solltest. Wenn man mehr Leuten folgt als Follower hat, wirkt das ab einer besteimmten Menge immer, als sei man ein Bot oder eben jemand, der geil auf Follower ist... und das wollen wir ja nicht. :) --Drachin  ♥ ^(Disk) 19:44, 16. Mär. 2014 (UTC)

Für meinen Geschmack sind das auch etwas zu viel gefolgte Leute. Ich persönlich würde denen Personen folgen, die Informationen bereit stellen. (Mojang, Mitarbeiter), denen, die uns folgen und sonstigen Wiki-Mitgliedern. Denen, die nicht in dieses Raster passen würde ich entfolgen. Auch denen, die Informationen doppelt aufwärmen. Follower sollten wir in erster Linie dadurch bekommen, dass die Personen sich für uns interessieren. Nicht dadurch, dass sie uns zurückfolgen, weil wir ihnen folgen. --.zip ^{de.MinecraftWiki-Admin Diskussion} 20:02, 16. Mär. 2014 (UTC)

Ja stimmt auch wieder. Jetzt sind es 86. Und für die Mojang Entwickler existiert eine extra Liste, die hier zu finden ist. ILeon ᐸ Diskussion
Beiträge - de.Wiki Admin 20:16, 16. Mär. 2014 (UTC)

Sieht schon viel besser aus :) --.zip ^{de.MinecraftWiki-Admin Diskussion} 20:20, 16. Mär. 2014 (UTC)

Bin ja so ein Twitter-Mensch, deswegen wars mir aufgefallen, dass du da die letzten Tage sehr aktiv warst ^^ --Drachin  ♥ ^(Disk) 20:27, 16. Mär. 2014 (UTC)