Minecraft Wiki 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 - September 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

Diese seit einiger Zeit laufende Diskussion ist immer noch ohne Ergebnis. Kannst du antworten oder eine Entscheidung treffen? Wenn ja, dann bitte diese Markierung löschen. - Weitere ungelöste Fragen siehe hier.

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)

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)

Und was ist mit den Geschichtsboxen in Artikeln? ILeon ᐸ Diskussion
Beiträge - de.Wiki Admin 12:22, 27. Sep. 2014 (UTC)

Da funktioniert eine gemeinsame Box ja dann auch. Es muss nur noch jemand in die Hand nehmen. --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 12:28, 27. Sep. 2014 (UTC)

Diese seit einiger Zeit laufende Diskussion ist immer noch ohne Ergebnis. Kannst du antworten oder eine Entscheidung treffen? Wenn ja, dann bitte diese Markierung löschen. - Weitere ungelöste Fragen siehe hier.

Ü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)

Zur Information: Die Mail mit den Vorschlägen ging eben raus. --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 16:01, 29. Sep. 2014 (UTC)

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)

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 "Teilen"-Tab 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 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)

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 melde mich erneut, da ich in Benutzerseiten das Problem habe, dass diese auch zu Breit sind und sich dann nach unten verschieben, kann man da irgendwie den Text verkürzen (wenn möglich per .css) so, dass es auch in einer Reihe ist? -M1n3r2011 (Diskussion / Beiträge) 16:51, 21. Sep. 2014 (UTC)

Bitte sehr:

/* Hinweis: Dies ist nur für die persönliche CSS-Datei gedacht, nicht für die allgemeine! */

.vectorTabs span, .vectorMenu span
{
  font-size: 0.75em !important;
}

#ca-watch span, #ca-unwatch span
{
  font-size: 1em !important;
}

#p-cactions-label span
{
  font-size: 0.475em !important;
}

#p-sharing
{
  display: none;
}

Die Schrift wird kleiner, du musst dich also einigermaßen auskennen. Auf meinem großen Bildschirm kann ich so bis 170% ohne Probleme zoomen, auf meinem kleineren 4:3-Bildschirm geht's aber nur bis 130%. Ich kann nicht genau sagen, wie's dann bei dir aussieht, aber probier's mal aus. Die oben erwähnte Lösung mit Symbolen würde da große Abhilfe schaffen. | violine1101^(Diskussion) 17:37, 21. Sep. 2014 (UTC)

Vielen Dank! :) -M1n3r2011 (Diskussion / Beiträge) 17:56, 21. Sep. 2014 (UTC)

@Violine1101: Du kannst ja mal das Stylesheet anfertigen, und wessen Bildschirm zu klein ist bzw. wer die Texte nicht will/braucht, kann es dann importieren. -- Elike98 ^Diskussion 18:41, 21. Sep. 2014 (UTC)

Yay, "Versionsgeschichte" ist jetzt kürzer ("Versionen"), vielen Dank CalebBlackhand! (Wobei "Hydra-view-history" in den MediaWiki-Systemnachrichten gar nicht vorkommt, na so was...) -- Sumpfhütte 12:21, 24. Sep. 2014 (UTC)

Na ja, ich empfehle in solchen Fällen den Parameter uselang=qqx, dann sieht man die "richtigen" Tags. Hydra-* dürfte nicht auftreten, weil das kein MediaWiki-eigener Skin, sondern die Curse-Version von Vector (oder so) ist. --Caleb Blackhand 12:58, 24. Sep. 2014 (UTC)

Tabellen

Mir ist aufgefallen das die Tabellen im Englischen-Wiki etwas anders aussehen. Ich wollte fragen ob es möglich währe das Englische-Layout auch für das Deutsche-Wiki zu verwenden.--93.130.41.22 19:31, 25. Sep. 2014 (UTC)

Welche Tabellen meinst du? --eagle3000 ^{(D ~ B)} 19:48, 25. Sep. 2014 (UTC)

Hier (Englisch) etwas weiter unten ist die History-Tabelle,hier sieht die Tabelle etwas übersichtlicher aus ,mit kleinen änderungen,so eine Tabelle meine ich ,zum vergleich :Klicken (Deutsch) bei dieser Tabelle muss man Scrollen.--93.130.41.22 20:10, 25. Sep. 2014 (UTC)

Das ist doch im Prinzip die gleiche Tabelle. Der Unterschied ist nur, dass man hier scrollen muss (dadurch wird aber die Gesamtgröße der Seite kleiner und diese dadurch übersichtlicher). Ein weiterer Unterschied ist, dass hier nicht zwischen "Beta" und "Vollversion" unterschieden wird (Im EN-Wiki gibt's dafür eigene Überschriften). Allerdings finde ich, dass das Design, das wir hier im DE-Wiki haben, übersichtlicher ist. So kann man auch die Beta- und die Vollversionen nicht so gut verwechseln, was andernfalls zu Missverständnissen führen könnte. | violine1101^(Diskussion) 20:18, 25. Sep. 2014 (UTC)

Mobile Version dauerhaft deaktivieren

Da ich die Mobile Version ziemlich unpraktisch finde (z.B. kein "rückgängig machen"?) und eh meistens im WLAN bin, würde ich sie gerne dauerhaft deaktivieren. Früher hat das auch prima durch klicken auf "Klassische Ansicht" geklappt, jetzt wird bei jedem Neuladen aber leider wieder zur Mobilen gewechselt (Cookies aktiv, Android + Chrome). Kann mir jemand helfen? :) -- Elike98 ^Diskussion 16:01, 29. Sep. 2014 (UTC)

Neue Vorlage "Übersetzung"?

Ich habe eben hier ein wenig an einer Übersetzungs-Vorlage herumexperimentiert. Diese wäre sehr nützlich, zum Beispiel im Artikel Herobrine, um dort nicht zwei Zitate (Eins original, eins übersetzt) zu haben. Was denkt ihr von der Idee? | violine1101^(Diskussion) 20:28, 29. Sep. 2014 (UTC)

Gute Idee, hab mir mal die Beispiele von der Doku angeschaut, sehr gut ! Mir gefällt die Vorlage. Voralem so was finde ich hat bis jetzt völlig gefehlt. Dadurch wird nicht nur die Seite an sich verkürzt sondern man hat direkten Bezug vom Original und der Übersetzung. Askon103974 (Diskussion) 20:50, 29. Sep. 2014 (UTC)

@Violine1101, Askon: Prinzipiell finde ich die Idee auch super. Ich finde aber, dass trotzdem beide Texte angezeigt werden sollten. Auf die Idee, den Tooltip zu lesen, wird man nicht so schnell kommen. Ich würde vorschlagen, dass man die Zitat-Vorlage mit deiner Test-Vorlage entsprechend erweitert. --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 15:51, 30. Sep. 2014 (UTC)

Die Überlegung hatte ich auch schon - grade weil ich bei übersetzten Zitaten aus dem Englischen gerne den Original-Text vergleichen möchte, um zu sehen, wo sich der Übersetzer ein paar "kreative Freiheiten" erlaubt hat. Im TV sind das die Untertitel zum gesprochenen Wort.... Hier könnte man neben dem Logo die 2 Zitate untereinander ausgeben, die Sprach"flagge" davor (wobei ich da auch unsicher bin - der Union Jack? Ist das wirklich britisches Englisch? Oder müsste das nicht eher das Star-sprangled banner sein? Oder etwas anderes? Gleiches gilt für die Flagge, die die deutsche Sprache repräsentiert (wobei das eher eindeutig ist, denn wir schreiben weder Österreichisch noch Switzerdütsch). Eindeutiger wäre die Sprachkürzel, also 'de' und 'en'. --Caleb Blackhand 16:05, 30. Sep. 2014 (UTC)

@Violine1101, Askon, Xzipx, Caleb: Die Tooltips finde ich zwar schön gemacht, aber ebenfalls nicht so praktisch. Ich wäre eher für eine Art Tabelle, so ähnlich wie wir sie jetzt beim Impressum haben. Damit sieht man übersichtlich und klar, was der engl. Text und was der dt. ist, und was zu was gehört. Ich habe einfach mal Violines Vorlage geklaut und etwas angepasst, das sähe dann in etwa so aus. Ob Flaggen oder Text ließe sich ja in jedem Fall leicht anpassen. -- Elike98 ^Diskussion 16:22, 30. Sep. 2014 (UTC)

@Violine1101, Askon, Elike98, Caleb: Zuallererst: Sprachcodes lösen das Problem auch nicht wirklich. Für amerikanisches Englisch gibt es beispielsweise den Code "en-US". Sowohl mit Länderflaggen aber auch mit den einfachen Codes "de" und "en" dürfte aber jedem klar sein, was gemeint ist. Die Spaltenlösung finde ich persönlich nicht so schön. Da gefällt mir der Fließtext besser. --Xzipx ^{de.MinecraftWiki-Admin Diskussion} 16:30, 30. Sep. 2014 (UTC)

Ich habe tatsächlich zuerst die amerikanische Flagge eingebaut gehabt, allerdings feststellen müssen, dass diese sich nicht so gut skalieren lässt: . Außerdem denke ich, dass die Union Jack sehr häufig allgemein für die englische Sprache verwendet wird, von daher finde ich die Union Jack als allgemeine Lösung vertretbar. Das gleiche gilt auch für die deutsche Flagge, denke ich. Außerdem wird, wenn man sich mit der Maus über dem übersetzbaren Text befindet, der Hilfe-Cursor angezeigt, der eben zusammen mit der vorangestellten Flagge und dem grauen Hintergrund auf eine Übersetzung hinweisen soll. Die Tabellenvariante würde natürlich auch gut funktionieren, erfüllt aber den Sinn (für die Zitate) nicht ganz so gut. | violine1101^(Diskussion) 16:35, 30. Sep. 2014 (UTC)

Das mit den Flaggen sehe ich auch so. Ich habe die Tabellen-Variation jetzt nochmal ein bisschen erweitert, sodass man sie quasi wie ein Zitat verwenden kann, aber du hast natürlich recht, praktischer geht es mit deiner Variante. -- Elike98 ^Diskussion 16:42, 30. Sep. 2014 (UTC)