PokéWiki:Allgemeine Diskussionsseite/Archiv 2016

Aus PokéWiki
< PokéWiki:Allgemeine Diskussionsseite
Version vom 10. Mai 2016, 15:29 Uhr von Skelabra2509 (Diskussion | Beiträge) (Archiv angelegt)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

Vorlage:Kasten


Neustrukturierung der (Haupt)spieleartikel

Guten Abend allesamt,

das Spieleprojekt hat sich Überlegungen zu einer neuen Musterstruktur gemacht und bittet um Feedback. Die neue Struktur findet ihr auf der Seite Pokéwiki:Spiele-Projekt/Kriterien, wo auch gerne Feedback gegeben werden kann. 384.gif Jones 19:42, 20. Jan. 2016 (CET)

Ausgediente Auszeichnungen?

In unserem heutige Chattreffen ging es unter anderem um die Auszeichnung zum äußerst wertvollen und/oder wertvollen Benutzer (im folgenden Text als ÄWB und WB bezeichnet). Diese beiden Auszeichnungen wurden in der Vergangenheit zusammen mit erweiterten Rechten verliehen – ein als wertvoller Benutzer ausgezeichneter Benutzer wurde zugleich zum Rollback ernannt. Diese Verbindung ist seit geraumer Zeit nicht mehr gegeben. Vielmehr wurden diese Auszeichnungen nur noch für die erweiterte Stimmberechtigung benötigt. Da die erw. Stimmberechtigung von nun an die Benutzerrechte der verlässlichen Benutzer geknüpft wird, sind die beiden Auszeichnungen ohne jeglichen Nutzen, für den sie eigentlich ins Leben gerufen worden sind.

Im weiteren Verlauf waren sich die anwesenden Benutzer uneinig, inwiefern nun mit den Auszeichnungen verfahren werden sollte, weshalb ich nun diese Abstimmung an dieser Stelle starte. Ich bitte hierbei um jeweils eine kleine Begründung, warum man so gewählt hat.

Vorlage:Celer1

Ergebnis: Die Auszeichnungen werden ohne Gegenstimmen behalten und weiterhin vergeben.

Abstimmung zeigen

Kleinere Änderungen an bestehenden Gruppen

Um das nächste Chattreffen effizienter zu machen, seien hier schon mal die Effekte der vorgeschlagenen Rechte erklärt. Frage und Anmerkungen zu dieser Erläuterung bitte stellen.

  • tboverride
    • Vorgeschlagen für: Verlässliche Benutzer
    • Effekt: Benutzer, die dieses Recht besitzen, können Seiten und Benutzerkonten anlegen, die mit der Titleblacklist kollidieren.
    • Hintergrund: Verlässlichen Benutzern wird zugetraut, dass sie nicht mutwillig Artikel mit beleidigenden Titeln anlegen. Dieses Recht kann allerdings von Nutzen sein, falls ein bereits ercheatetes, offiziell geleaktes Pokémon wie Volcanion vor einigen Wochen bekannt wird: In diesem Fall kann der Artikel auch ohne Hilfe eines Administrators von einem vertrauenswürdigen Benutzer angelegt werden.
  • titleblacklistlog
    • Vorgeschlagen für: Verlässliche Benutzer oder Redakteure
    • Effekt: Der Benutzer hat Zugriff auf das Log, in dem jeder durch die Titleblacklist verhinderter Versuch der Artikelanlage aufgezeichnet wird.
    • Hintergrund: Das Log erlaubt den Benutzern, sowohl fehlerhafte Treffer der Blacklist als auch sperrwürdige Treffer zu identifizieren. Solche können somit schneller an die Administratoren weitergereicht werden.
  • writeapi (de facto)
    • Vorgeschlagen für: Verlässliche Benutzer
    • Effekt: Der Benutzer darf über die API editieren. Der Zugriff ist de jure schon fregeschaltet, aber wird intern anderweitig verhindert.
    • Hintergrund: Die API wird nicht nur für botartige Massenänderungen verwendet, ob konstruktiv oder destruktiv; sondern auch von vielen halbautomatischen Skripte. Verlässlichen Benutzern dürfte das Vertrauen entgegengebracht werden, diesen Zugang nicht zu missbrauchen.
  • mergehistory
    • Vorgeschlagen für: Redakteure
    • Effekt: Erlaubt unter bestimmten Voraussetzungen die reversible Vereinigung der Versionen zweier Artikel und damit auch der Artikel selbst zu einem.
    • Hintergrund: Über geschickten Einsatz der Rechte delete und undelete, über die die Redakteure verfügen, ist das ohne jegliche Erfüllung von Voraussetzungen auch so möglich, dass es nur unter Einsatz langwieriger, komplizierter Arbeit wieder von einem Admin oder Redakteur wieder rückgängig gemacht werden kann.
  • markbotedits
    • Vorgeschlagen für: Redakteure
    • Effekt: Setzt der Benutzer eine Änderung zurück, kann er optional auswählen, ob die zurückgesetzende + die zurücksetzende Änderung in den Letzten Änderungen als Bot-Änderungen markiert, also standardmäßig ausgeblendet werden sollen.
    • Hintergrund: Klarere Abgrenzung der Redakteure von den VBs in Bezug auf Vertrauen und Rechte, entspricht ein Stück weit der ursprünglichen Rolle als „Rollbacks“.
  • protect
  • patrol
    • Vorgeschlagen für: Projektleiter
    • Effekt: Erlaubt, Änderungen zu kontrollieren, die nicht von einem selbst getätigt wurden.
    • Hintergrund: Projektleiter kennen sich bei ihrem Projektthema am besten aus.

Diskussion zu tboverride, titleblacklistlog, wirteapi, mergehistory, markbotedits

Gibt es gegen die Umsetzung dieser Änderungen irgendwelche Einwände? Welche Gruppe soll titleblacklistlog erhalten? -- 609.png Skelabra2509 (Diskussion | Beiträge) 22:21, 20. Feb. 2016 (CET)

Ich verstehe nicht ganz, wozu man allgemein markbotedits gebrauchen soll. --Kein Dschungel zu dicht... Killuu http://i.imgur.com/acgb9YG.png 22:40, 20. Feb. 2016 (CET)
Keine Einwände von mir. @Killuu: Zwei Situationen, in denen ich das verwenden würde: 1. Wenn man Vandalismus auf Benutzerdiskussionsseiten mit markbotedits rückgängig macht, wird beim betroffenen Benutzer keine Benachrichtigung ausgelöst. 2. Um im Notfall massenhaft Änderungen rückgängig zu machen, ohne dabei die LÄ zu fluten. – shadowtweaker 23:10, 20. Feb. 2016 (CET)
tboverride und titleblacklistlog nur auf Red runter pls (das befürworte ich dann allerdings), mergehistory würde ich auf Admin lassen [auch arg selten, das man das braucht], markbotedits is mir egal, writeapi weiss ich auch nicht, was dort schiefgelaufen ist. --Datei:Sugimori 672.pngMecanno-manMäh 23:18, 20. Feb. 2016 (CET)
mergehistory in radikaler haben die Redakteure ja eh schon, daher sehe ich keinen Grund, ihnen das vorzuenthalten. Bei tboverride kann ich die Problematik, es VBs zu geben, nicht ganz nachvollziehen. Von ihnen kann man erwarten, dass sie weder beleidigende Seitentitel verwenden noch dass sie unerlaubte Artikel zu unbestätigten Pokis anlegen. Sollte es Vorbehalte gegen einzelne Benutzer geben, sollte diese nicht die ganze Gruppe tragen müssen. -- 609.png Skelabra2509 (Diskussion | Beiträge) 12:46, 21. Feb. 2016 (CET)
Ich habe fast keine Einwände. Lediglich titleblacklistlog würde ich nur auf Redakteur heruntersetzen. Bezüglich writeapi liegt die Entscheidung aber wohl bei den Bürokraten. ~ Taisuke 136.gif 03:30, 24. Feb. 2016 (CET)
Nachdem ich gesehen hab, was shadow da versucht hat [Ergebnis: Eine Datei gelöscht, ohne die Datei zu löschen] können die Redakteure das mergehistory von mir aus haben... --Datei:Sugimori 672.pngMecanno-manMäh 10:47, 27. Feb. 2016 (CET)
Nach kurzen Tests: Was genau bewirkt titleblacklistlog? Bzw. wann wird etwas geloggt; weil das Log ist derzeit leer... --Datei:Sugimori 672.pngMecanno-manMäh 19:44, 21. Mär. 2016 (CET)
tboverride wurde auf den VB, titleblacklistlog an die Redakteure und mergehistory an dei Redakteure vergeben; die titleblacklislog erlaubt btw scheinbar nur das einsehen von veruchten accountkreierungen. (Der vorstehende nicht signierte Beitrag stammt von: Mecanno-man • Diskussion • Beiträge)

Diskussion zu protect

Sollen Redakteure protect erhalten? -- 609.png Skelabra2509 (Diskussion | Beiträge) 22:21, 20. Feb. 2016 (CET)

Ich muss zugeben, ich sehe keinen Sinn, wieso Redakteure das haben sollten. Hast du Beispiele dafür? --Kein Dschungel zu dicht... Killuu http://i.imgur.com/acgb9YG.png 22:40, 20. Feb. 2016 (CET)
Pro, erst recht in Kombination mit Schutzstufe für stimmberechtigte. – shadowtweaker 23:10, 20. Feb. 2016 (CET)
Siehe Killuu --Datei:Sugimori 672.pngMecanno-manMäh 23:18, 20. Feb. 2016 (CET)
Macht in meinen Augen nur Sinn, wenn sie Schutzniveau bis Redakteursebene vergeben oder ändern können. Sollten sie dadurch auch automatisch festlegen können, was auf Adminlevel geschützt ist bzw. könnten diesen Schutz herabstufen, wäre ich dagegen. ~ Taisuke 136.gif 03:30, 24. Feb. 2016 (CET)
Analog zum Wikipedia:Superschutz könnten die Redakteure
  • nicht auf Admin-Level schützen
  • Auf Admin-Level gegen das Editieren geschützte Seiten nicht bearbeiten.
Theoretisch ließe sich sogar ein zusätzlicher Schutz gegen das Schützen selbst einrichten. -- 609.png Skelabra2509 (Diskussion | Beiträge) 14:29, 25. Feb. 2016 (CET)
Ich stehe der Idee mittlerweile übrigens auch ein wenig kritisch gegenüber, ist aber eher ein Bauchgefühl. -- 609.png Skelabra2509 (Diskussion | Beiträge) 21:47, 26. Feb. 2016 (CET)

Diskussion zu autopatrol

Sollen Verlässliche Benutzer autopatrol erhalten? -- 609.png Skelabra2509 (Diskussion | Beiträge) 22:21, 20. Feb. 2016 (CET)

Hä, ich dachte, die haben das jetzt schon? Meiner Meinung nach nicht, da bei vielen verlässlichen Benutzern immer noch Fehler passieren. --Kein Dschungel zu dicht... Killuu http://i.imgur.com/acgb9YG.png 22:40, 20. Feb. 2016 (CET)
Hat Vor- und Nachteile, Projektleiter ohne autopatrol finde ich aber auf jeden Fall sinnlos. – shadowtweaker 23:10, 20. Feb. 2016 (CET)
^ --Datei:Sugimori 672.pngMecanno-manMäh 23:18, 20. Feb. 2016 (CET)
Meinte natürlich behalten. -- 609.png Skelabra2509 (Diskussion | Beiträge) 23:19, 20. Feb. 2016 (CET)
Ich würde es auf Projektleiter beschränken, niemand kann von sich behaupten, nie Rechtschreibfehler oder kurze Denkaussetzer zu haben und wenn noch einmal jemand drüberschaut, fällt sowas dann doch im Normalfall auf. -- 359.png Korvel1 Diskussion 11:30, 21. Feb. 2016 (CET)
Hm, ich tue mich hier schwierig. In meinen Augen sind unsere verlässlichen Benutzer halt einfach potenzielle Projektleiter, nur halt ohne einen solchen Posten. Daher fällt es mir schwer zwischen den beiden Benutzergruppen einen Strich zu ziehen und dann den einen autopatrol zuzutrauen und den anderen nicht. ~ Taisuke 136.gif 03:30, 24. Feb. 2016 (CET)

Diskussion zu patrol

Sollen Projektleiter oder Verlässliche Benutzer das Recht erhalten, Beiträge, neue Seiten (und neue Dateien) zu kontrollieren? Hierbei sollte die schwindende Differenz zu Redakteuren beachtet werden. -- 609.png Skelabra2509 (Diskussion | Beiträge) 22:21, 20. Feb. 2016 (CET)

Dann könnten wir die Rechtegruppen gleich fusionieren, halte das eher nicht für sinnvoll. --Kein Dschungel zu dicht... Killuu http://i.imgur.com/acgb9YG.png 22:40, 20. Feb. 2016 (CET)
Macht bei Projektleitern Sinn, bei normalen VBs bin ich eher skeptisch... --Datei:Sugimori 672.pngMecanno-manMäh 23:18, 20. Feb. 2016 (CET)
Mit VBs wollte ich nur die Anzahl der Gruppen, die wir am Ende haben, verringern. -- 609.png Skelabra2509 (Diskussion | Beiträge) 23:24, 20. Feb. 2016 (CET)
Würde ich höchstens Projektleitern zutrauen, bin allerdings auch da skeptisch, ob das so eine gute Idee wäre. 359.png Korvel1 Diskussion 11:30, 21. Feb. 2016 (CET)
Wenn überhaupt, dann würde ich mich hier für Projektleiter aussprechen, da sie in ihren jeweiligen Bereichen ja im Zweifel sehr gut bzw. mit am besten bewandert sein sollten. Sollten die Projektleiter autopatrol erhalten, dann auch patrol. Dennoch bin ich der Meinung, dass wir momentan keinen Mangel an Leuten haben, die Bearbeitungen kontrollieren. Zumindest sehe ich selten über einen längeren Zeitraum unkontrollierte Beiträge. ~ Taisuke 136.gif 03:30, 24. Feb. 2016 (CET)
Ich werde spätestens morgen mal eine Idee zu den Changetags (und eine nähere Erläuterung) zu Byte bringen, mit der man gleichzeitig den Projektleitern eine größere Rolle bei der Kontroller zuspricht und patrol bei den Redakteuren belässt. -- 609.png Skelabra2509 (Diskussion | Beiträge) 14:29, 25. Feb. 2016 (CET)

Kongruente Gruppen

Sollen stimmberechtigte verlässliche Benutzer auch der Gruppe der Stimmberechtigten Benutzer hinzugefügt werden? Technisch ist dies nicht nötig, es erlaubt jedoch durch einfaches Überprüfen der Gruppenmitgliedschaft die Stimmberechtigung festzustellen. Ähnlcihe Überlegungen wären auch bei der Vergabe der Rechte eines Verlässlichen Benutzers an Redakteure und Admins sinnvoll. -- 609.png Skelabra2509 (Diskussion | Beiträge) 22:21, 20. Feb. 2016 (CET)

Wenn es dabei bleibt, dass es nicht-stimmberechtigte verlässliche Benutzer geben kann, wäre das sinnvoll. – shadowtweaker 23:10, 20. Feb. 2016 (CET)
Mir egal, wenn niemand was dagegen sagt, würd ich das sonst übernehmen. --Datei:Sugimori 672.pngMecanno-manMäh 23:18, 20. Feb. 2016 (CET)
Dies würde unsere jetzige Handhabung bei den anderen Rechtegruppen entsprechen. Schließlich habe ich als Administrator trotzdem die Rechte eines verlässlichen Benutzers. ~ Taisuke 136.gif 03:30, 24. Feb. 2016 (CET)
Admins befinden sich aber nicht in der Gruppe der Redakteure. Da im Falle der Stimmberechtigten die Information, dass eine Person in beiden Gruppen ist, sogar einen Mehrwert bietet, bin ich auf jeden Fall dafür. -- 609.png Skelabra2509 (Diskussion | Beiträge) 14:29, 25. Feb. 2016 (CET)
Dann schlage ich vor, dass ein Redakteur oder Administrator das soweit umsetzt. Ich denke, dass dieses Thema nicht unbedingt ein Bürokratenthema ist. -- 609.png Skelabra2509 (Diskussion | Beiträge) 23:08, 22. Mär. 2016 (CET)
Hab ich jetzt (auf eigene Faust) einfach mal gemacht. --Datei:Sugimori 672.pngMecanno-manMäh 23:23, 22. Mär. 2016 (CET)

Schutz auf Höhe der Stimmberechtigten Benutzer einführen

Ein Schutz auf Höhe der Stimmberechtigten Benutzer könnte evtl. sinnvoll sein, um als eine Art geringe Schutzstufe zur Verhinderung versehentlicher unkonstruktiver Änderungen durch neue Benutzer zu fungieren. Gerade bei der Veröffentlichung neuer Pokémon kann dieser sinnvoll sein. Es ließe sich auch problemlos bei der Gelegenheit auch ein Kaskadenschutz auf dieser Ebene integrieren, ohne die Schutzfunktion der Hauptseite zu beeinträchtigen. -- 609.png Skelabra2509 (Diskussion | Beiträge) 22:21, 20. Feb. 2016 (CET)

Sehe da derzeit keinen Bedarf. --Kein Dschungel zu dicht... Killuu http://i.imgur.com/acgb9YG.png 22:40, 20. Feb. 2016 (CET)
Klares Pro. [1] – shadowtweaker 23:10, 20. Feb. 2016 (CET)
Siehe Killuu --Datei:Sugimori 672.pngMecanno-manMäh 23:18, 20. Feb. 2016 (CET)
Sehe da auch keinen großen Bedarf, das Beispiel, das du genannt hast ist eher die Ausnahme, so viele neue Pokémon werden jetzt auch wieder nicht veröffentlicht und selbst wenn finde ich einen generellen Schutz vor Falschinformationen sinnvoller. Nur, weil jemand 100 Edits im Wiki gemacht hat, kennt diese Person sich nicht automatisch mit der rechtlichen Situation u.a. aus. -- 359.png Korvel1 Diskussion 11:30, 21. Feb. 2016 (CET)
@Killuu, Mecanno-man, Korvel1: Um das noch genauer zu begründen: Diese Schutzstufe wäre einfach die neue niedrigste Schutzstufe für Seiten mit erhöhter Gefahr unerwünschter Bearbeitungen. Beispiele:
  1. Schutz vor Gerüchten und geleakten Bildern (Magearna)
  2. Seiten mit hohem Verhältnis von Aufrufzahl zu Bearbeitungsbedarf (Pokémon-Liste)
  3. Uploadschutz für häufig benutzte Dateien oder Dateien, die auf der Hauptseite benutzt werden, falls kein noch höherer Schutz erforderlich ist (betrifft zum Beispiel Bilder, die via Wds gelegentlich auf die Hauptseite gelangen und dazwischen ungeschützt sind)
Benutzern, denen wir es zutrauen, an Abstimmungen teilzunehmen, sollte man doch auch zutrauen können, in den eben aufgezählten Situationen nicht mehr ganz so unerfahren zu sein wie ein Neuling. Selbst wenn mal ein Fehler passieren sollte, was auch bei verlässlichen Benutzern nicht 100%ig ausgeschlossen ist, – die Gefahr dessen ist in meinen Augen zu gering, als dass man stimmberechtigten Benutzern das Recht auf produktive Beiträge verwehren sollte. – shadowtweaker 12:26, 21. Feb. 2016 (CET)
...würde damit Schutz auf stimmberechtigt-Niveau Schutz auf VB-Niveau ablösen? Imo sollten wir einfach nicht zu viele Schutzstufen haben... --Datei:Sugimori 672.pngMecanno-manMäh 12:59, 21. Feb. 2016 (CET)
VB-Niveau brauchen wir wohl für die Hauptseite. – shadowtweaker 13:04, 21. Feb. 2016 (CET)
Stimmt auch wieder; mein Hauptcontrapunkt ist allerdings, das ich kein Chaos bezüglich Schutzstufen will; drei sind imo. ausreichend - und, ob wir den stimmberechtigten Benutzern allen Erfahrung zutrauen (kann man nach wie vor quantitativ erreichen) ist ne andere Sache... --Datei:Sugimori 672.pngMecanno-manMäh 13:11, 21. Feb. 2016 (CET)
Man kann die Stimmberechtigung aber auch begründet verwehren. Ich würde das VB-Niveau allein schon für Vorlagen u. ä. behalten, für die Hauptseite wäre es allerdings in der Tat nicht nötig (Hauptseite wäre SB kaskadierend, kaskadierend bearbeiten erst ab VB erlaubt). -- 609.png Skelabra2509 (Diskussion | Beiträge) 15:42, 23. Feb. 2016 (CET)
Stehe da weiterhin auf Mecs Seite. Besonders der Punkt, dass die Berechtigung auch quantitativ (und das ziemlich schnell) erreicht werden kann, ist für mich besonders ausschlaggebend. Ich glaube daher auch nicht, dass alle davon schon wissen, wie mit geleakten Informationen umgegangen wird, selbst wenn man schon ein wenig mitgearbeitet hat und sich soweit auskennt, dass man bei Abstimmungen mitmachen darf. --Vorsicht, heiß! Killuu http://i.imgur.com/wVf4WMM.png 18:54, 23. Feb. 2016 (CET)
Ich würde eine solche zusätzliche Schutzstufe begrüßen. Denn sind wir mal ehrlich, ein solcher Schutz würde nur auf einen kleinen Teil unserer Artikel fallen und würde keine Abwertung unseres Schutz-Systems bedeuten. Vielmehr würde es einen differenzierteren Schutz bedeuten und damit mehr Personen die Möglichkeit bieten, Vertrauen geschenkt zu bekommen und Verantwortung zu übernehmen, indem man ihnen neben der Stimmberechtigung auch Bearbeitungen leicht geschützter Artikel zutraut. Dennoch wäre ich ganz klar dagegen, dass Schutzniveau der Hauptseite auf dieses Level zu senken! ~ Taisuke 136.gif 03:30, 24. Feb. 2016 (CET)
Wisst ihr was? Ich gebe nach; es scheint mir zwar nicht sonderlich sinnvoll, aber Schaden tut's auch nicht; einfach was damit geschützt werden soll [Zeugs, das wegen Leaks geschützt ist, möchte ich z. B. nach wie vor auf VB haben] leuchtet mir nicht ein. Naja, Schaden wird es nicht, von demher... --Datei:Sugimori 672.pngMecanno-manMäh 10:47, 27. Feb. 2016 (CET)
Eingeführt. --Datei:Sugimori 672.pngMecanno-manMäh 13:46, 12. Apr. 2016 (CEST)

Rechtesystem reformieren

IPs zu editieren erlauben

IPs das Editieren zu erlauben könnte die Einstiegshürde ins PokéWiki deutlich senken. Dabei könnten zur Vermediung von Vandalismus weitere Maßnahmen getroffen werden, sodass bspw. nicht kontrollierte Änderungen nicht angezeigt werden.(Hierzu könnte man das Kontrollieren auf zwei Ebenen aufteilen.) Die technische Machbarkeit ist grundsätzlich gegeben, müsste jedoch im Detail kontrolliert werden. Auch Rechte wie das Dateien hochladen und das Bearbeiten des Benutzernamensraums sowie das Verschieben von Seiten können eingeschränkt werden, technisch ließe sich das Wiki auch mit komplizierteren Bearbeitungsfiltern aufrüsten. -- 609.png Skelabra2509 (Diskussion | Beiträge) 22:21, 20. Feb. 2016 (CET)

Bedeutet im Kontrollieren einen wesentlich höheren Mehraufwand. Ich glaube, das stand vor einiger Zeit auch schonmal zur Frage. Sehe aber auch hier derzeit nicht den Bedarf. --Kein Dschungel zu dicht... Killuu http://i.imgur.com/acgb9YG.png 22:40, 20. Feb. 2016 (CET)
Wäre in den Zeiten des Benutzermangel eine große Chance für das Wiki. Müsste man aber erstmal testen, wie hoch das Vandalismusaufkommen ist im Vergleich zu produktiven Bearbeitungen. – shadowtweaker 23:10, 20. Feb. 2016 (CET)
Wurde, afaik, auf Bürokratenebene bereits gevetod. Auf jeden Fall: Auch von mir ein nein; eine Konto anzulegen ist nicht schwer. --Datei:Sugimori 672.pngMecanno-manMäh 23:18, 20. Feb. 2016 (CET)
Bedeutender Mehraufwand und Risiko des Vandalismus, selbst mit den von dir genannten Maßnahmen. Würde ich ablehnen. -- 359.png Korvel1 Diskussion 11:30, 21. Feb. 2016 (CET)
Ich denke, dass es einen Versuch wert ist. Sozusagen als Testphase. Nicht jeder will sich immer direkt registrieren und gerade mit dem Benutzermangel könnte es frischen Wind bringen. Sollten jedoch die ersten 10 Edits alle Vandalismus sein, kann man es dann immer noch wieder abschalten. 384.gif Jones 12:13, 21. Feb. 2016 (CET)
Eine Probephase hätte wirklich etwas. Nach 1 Monat könnte man dann die Ergebnisse dieser bewerten und sich über die Folgen Gedanken machen. Technisch ist es möglich (beim Umschalten einer Einstellung), notfalls alle IPs zu sperren, falls es einen unhandhabbarem Vand-Schwell geben sollte. Auch ein Editierhinweis für IPs ließe sich meines Wissens aktivieren, sowas wie eine abgespeckte Begrüßung, die neben einigen Grundregeln auch das Anmelden bewirbt. -- 609.png Skelabra2509 (Diskussion | Beiträge) 12:55, 21. Feb. 2016 (CET)
Ich stehe der ganzen Idee eher skeptisch gegenüber. ~ Taisuke 136.gif 03:30, 24. Feb. 2016 (CET)
Na ja, was gibt es bei einer Testphase zu verlieren? -- 609.png Skelabra2509 (Diskussion | Beiträge) 14:29, 25. Feb. 2016 (CET)
Nerven, Skelabra, die Nerven gibt es zu verlieren, wenn wir dann mit Vandalismus überschwemmt werden. --Datei:Sugimori 672.pngMecanno-manMäh 10:47, 27. Feb. 2016 (CET)
Wenn man in der Probephase sagt, dass das erste Aufkommen von Vandalismus zum sofortigen Deaktivieren führt, denke ich kaum, dass es da Nerven zu verlieren gibt. 384.gif Jones 11:19, 27. Feb. 2016 (CET)
Ich halte die Vorstellung, dass wir nach einer Aktivierung des Editierens für IPs im Minutentakt von Vandalismus überschwemmt werden, für Schwarzmalerei. Damit das passiert, müsste ja die Hälfte der Leser plötzlich Lust bekommen, zu vandalieren, wenn sie einen Bearbeiten-Button sehen. Angnommen, man macht 1 Woche Testpahse und verlängert die dann bei einem nicht zu großen Anstieg von Vandalismus auf einen Monat (oder erlaubt Admins das sofortige Beenden der Probehphase im fall der Fälle) dürfte das meiner Meinung nach unproblematisch sein. Das ganze hängt allerdings natürlich an der aller ersten Stelle von der Meinung Buos ab. -- 609.png Skelabra2509 (Diskussion | Beiträge) 19:35, 27. Feb. 2016 (CET)
Ich bin da auch absolut dagegen. Das hilft uns nicht gegen den Usermangel und stellt einfach nur ein weiteres Sicherheitsrisiko bzw. einen Mehraufwand bei der Kontrolle dar. Klares nein von mir. -- Liebe Grüße, Moltres 146.gif 15:14, 28. Feb. 2016 (CET)

Natürlich wird das Vandalismusaufkommen ein bisschen steigen. Aber was ist so schlimm daran? Redakteure sind doch dafür da, Vandalismus rückgängig zu machen. Und wenn befürchtet wird, dass der Vandalismus nicht schnell genug rückgängig gemacht wird, dann lässt man unkontrollierte Bearbeitungen eben nicht anzeigen. Im Endeffekt ist das Risiko also gering. Dem gegenüber steht der klare Vorteil, dass die Hürde für produktive Beiträge sinkt. Es wird nicht nur mehr produktive Beiträge geben, sondern auch mehr produktiv beitragende Benutzer. Wollen wir diese Chance wirklich leichtfertig wegschmeißen? Natürlich wissen wir nicht, wie das Verhältnis von Vandalismus zu produktiven Beiträgen ausfallen wird und wie viele Benutzer, die als IP angefangen haben, uns dauerhaft erhalten bleiben. Deshalb ja eine Testphase; und wenn die Nachteile überwiegen, dann brechen wir eben ab, ohne dass es uns irgendwie geschadet hätte.
@moltres: „Das hilft uns nicht gegen den Usermangel“ Begründung? Ich kenne viele Wikipedia-Administratoren, die als IP angefangen haben. – shadowtweaker 17:02, 28. Feb. 2016 (CET)

Ich glaube, die Diskussion hat eine Tragweite, dass sie auch für die Bürokraten ganz interessant ist, deshalb pinge ich einfach frecherweise mal Buoysel und Matze an. Vielleicht haben die beiden ja eine (andere) Meinung dazu.ka.gif -- Liebe Grüße, Moltres 146.gif 20:46, 28. Feb. 2016 (CET)
Testphase im Chattreffen abgelehnt. --Datei:Sugimori 672.pngMecanno-manMäh 13:46, 12. Apr. 2016 (CEST)

Neue Gruppe Techniker einführen

Zurzeit gibt es mit bspw. Xavier und shadowtweaker einige Personen bei uns im Wiki, die über keine Administratorrechte verfügen, aber das technische Know-how und die nötige Verantwortung zum Bearbeiten von JS, CSS und dem Interface besitzen. Eine solche Gruppe, die über editinterface, edituserjs und editusercss sowie evtl. weitere passende Rechte verfügt könnte daher hilfreich sein. -- 609.png Skelabra2509 (Diskussion | Beiträge) 22:21, 20. Feb. 2016 (CET)

Was kann mit diesen Rechten alles bearbeitet werden? --Kein Dschungel zu dicht... Killuu http://i.imgur.com/acgb9YG.png 22:40, 20. Feb. 2016 (CET)
Nix gegen, auch nix für; folglich: Mir egal. edituserjs und editusercss würd ich aber gerne auf Adminebene behalten... --Datei:Sugimori 672.pngMecanno-manMäh 23:18, 20. Feb. 2016 (CET)
Mit editinterface kann man den gesamten nicht geschützten MediaWiki-NR bearbeiten, also was an unterschieldichen Stellen im Wiki für Texte und welches JS/CSS im Wiki angezeigt werden. (Der vorstehende nicht signierte Beitrag stammt von: Skelabra2509 • Diskussion • Beiträge)
Ich sehe den Bedarf dafür irgendwie nicht so recht gegeben. ~ Taisuke 136.gif 03:30, 24. Feb. 2016 (CET)
Ich sehe da wie meine Vorredner auch die Notwendigkeit dafür irgendwie nicht gegeben. Sry. -- Liebe Grüße, Moltres 146.gif 15:17, 28. Feb. 2016 (CET)
Ist gut gemeint, aber ich denke auch eher nicht, dass sich das lohnt, da Änderungen im MediaWiki-Namensraum doch recht selten sind. (Es würde aber nicht schaden, Common.css und Common.js mal aufzuräumen.) – shadowtweaker 17:02, 28. Feb. 2016 (CET)

Konfigurationsänderungen

Displaytitle

Spricht irgendwas dagegen, zu erlauben, dass mit {{DISPLAYTITLE:foo}} der angezeigte Seitentitel geändert wird? Dies würde eine Alternative zur teilweise falsch angezeigten Vorlage:Seitentitel führen. -- 609.png Skelabra2509 (Diskussion | Beiträge) 22:21, 20. Feb. 2016 (CET)

Geht doch, oder täusche ich mich da? --Kein Dschungel zu dicht... Killuu http://i.imgur.com/acgb9YG.png 22:40, 20. Feb. 2016 (CET)
Für Artikel in Einzelfällen brauchbar, kann man aber auch viel Unsinn mit treiben. – shadowtweaker 23:10, 20. Feb. 2016 (CET)
Verstehe das Problem gerade nicht ganz. Bitte besser erläutern. --Datei:Sugimori 672.pngMecanno-manMäh 23:18, 20. Feb. 2016 (CET)
Ein Beispiel, wo die Vorlage nicht funktioniert, sind Weiterleitungen. Beispielsweise (ich hab grad leider kein besseres Beispiel parat) hat der Benutzer:Piplup13 seinen Namen geändert, ruft man jetzt Benutzer:Mijumaru1 auf, rutsch der Container nach unten. Daneben sollte mMn generell immer auf eingebaute Lösungen gesetzt werden, anstatt selber was zu basteln. 384.gif Jones 12:13, 21. Feb. 2016 (CET)
Das Problem läuft in die andere Richtung; # kann nicht in DISPLAYTITLE benutzt werden, auf allen anderen Inhaltsseiten wird Seitentitel nicht mehr verwenden; wenn jenes Problem mit DISPLAYTITLE behoben wird, kann Seitentitel weg. --Datei:Sugimori 672.pngMecanno-manMäh 12:59, 21. Feb. 2016 (CET)
Auf die Gefahr hin, dass ich hier etwas falsch verstanden habe: Hier wird doch alles richtig dargestellt mit {{DISPLAYTITLE:}}. Selbst wenn ich den Pokémon-Artikel über eine Weiterleitung aufrufe. ~ Taisuke 136.gif 03:30, 24. Feb. 2016 (CET)
In diesem Fall funktioniert das Magischer Wort, weil nur Groß- und Kleinschreibung geändert wird. Wird in dem Magischem Wort allerdings ein Code angegeben, der den Seitentitel inhaltlich ändern würde, würde das (abgesehen von Groß- und Kleinschreibung) nicht funktionieren. -- 609.png Skelabra2509 (Diskussion | Beiträge) 14:29, 25. Feb. 2016 (CET)
Geändert. --Datei:Sugimori 672.pngMecanno-manMäh 13:46, 12. Apr. 2016 (CEST)

Einbindung externer Bilder

Wenn externe Bilder i. d. R. nicht eingebunden werden sollten, ließe sich die Einbindung auf diese Weise auf bestimmte Domains reduzieren (Wikimedia, Filb, PokéWiki, Greenchu mindestens). -- 609.png Skelabra2509 (Diskussion | Beiträge) 22:21, 20. Feb. 2016 (CET)

Fragwürdig, ob das im gesamten Wiki sinnvoll ist; ich würde es nur auf Inhaltsseiten anwenden wollen, wenn überhaupt... --Datei:Sugimori 672.pngMecanno-manMäh 23:18, 20. Feb. 2016 (CET)
Ich denke, dass es auch auf beispielsweise Benutzerseiten sinnvoll ist. 384.gif Jones 12:13, 21. Feb. 2016 (CET)
Ich bin mir gerade etwas unsicher, ob ich den Punkt richtig verstehe. Auf der Hilfeseite zu Bildern wird doch extra gesagt, dass nicht für Artikel benötigte Bilder bei externen Hostern hochgeladen werden sollen und somit dann mit der URL auf der jeweiligen Benutzerseite eingebunden werden können. Magst du mir vielleicht nochmals genau sagen, was du mit diesem Punkt meinst, Skelabra2509? ~ Taisuke 136.gif 03:30, 24. Feb. 2016 (CET)
Okay, das hatte ich bei meiner Idee übersehen. Vergesst es. -- 609.png Skelabra2509 (Diskussion | Beiträge) 12:52, 25. Feb. 2016 (CET)

Changetags

Nach dem MediaWiki-Update wird es möglich sein, einzelne Versionen händisch mit bestimmten Markierungen zu versehen. Diese können über die API mit applychangetags gesetzt werden, über API und GUI mit changetags nachträglich geändert werden und mit managechangetags bearbeitet werden. Hierbei ist neben dem Ergänzen einer Beschreibung und der Änderung des angezeigten Namens auch ein irreversibles Löschen von Makrierungen möglich. Soll dieses neue Feature im PokéWiki genutzt werden? -- 609.png Skelabra2509 (Diskussion | Beiträge) 22:21, 20. Feb. 2016 (CET)

Funktionsweise und Nutzungsmöglichkeiten bitte genauer erklären. Wäre es damit möglich, inhaltliche und formale Bearbeitungskontrollierung zu trennen? – shadowtweaker 12:46, 21. Feb. 2016 (CET)
Ich würde es ebenfalls gerne etwas genauer erläutert bekommen, was dieses mögliche neue Feature für Vorteile mit sich bringt. ~ Taisuke 136.gif 03:30, 24. Feb. 2016 (CET)
Okay. Auf Spezial:Tags werden alle Markierungen gelistet, die in einem Wiki Versionen (und Logbucheinträgen) zugeordnet werden können. Dabei wird unterschieden zwischen von der Software automatisch gesetzten Markierungen (bei uns bislang nicht der Fall) und Markierungen, die von Benutzern manuell (auch nachträglich) Versionen zugeordnet werden. Markierungen, die die Software nicht zum gegenwärtigen Zeitpunkt automatsich setzt können von berechtigten Benutzern jederzeit aktiviert und deaktiviert sowie irreversibel gelöscht werden. Das Zuordnen von Markierungen kann hier von angemeldeten Benutzern getestet werden: [2]. (Häkchen setzen, „Markierungen ausgewählter Versionen bearbeiten“ klicken und sich freuen.) Sind die Tags einmal gesetzt lassen sich u. a. Special:Contribs, die Versionsgeschichte, Special:Log und Special:RecentChanges danach filtern (darum sind Versionsmarkierungen, die vor mehr als 90 Tagen gesetzt wurden, nicht mehr so einfach auffindbar, weil RecentChanges nur bis dahin zurückreicht). Alle Erstellungen/Löschungen/Zuordnungen von Markierungen werden zudem geloggt.
Das Prinzip – was so wie patrol mit einer beliebigen Anzahl Kriterien anmutet – dürfte jetzt verständlicher geworden sein, nun folgt ein Vorschlag für Umsetzung: Wenn Redakteure kontrollieren, aber inhaltliche Unsicherheiten behalten, könnten sie bspw. „Bitte Gegenchecken durch Anime-PRojektleitung“ oder ähnliches als Markierung zuordnen. So hätte man die inhaltliche Kontrolle durch Projektleiter auch integriert, ohne patrol abzustufen. Für die Rechtevergabe würde sich managechangetags wegen der Möglichkeit irreversibler Löschungen an Admins anbieten, changetags an (Bots und) Projektleiter oder für mehr Flexibilität bei der Weiterentwicklung der Verwendungsarten hier im PokéWiki auch für alle Verlässlichen Benutzer. applychangetags wird während eines Edits von Skripten und Bots über die API gesetzt. Damit kann man wenig scheiße bauen, vor allem weil kaum einer weiß wie. Das kann IMHO jeder bekommen. -- 609.png Skelabra2509 (Diskussion | Beiträge) 21:41, 26. Feb. 2016 (CET)
Ich hätte da spontan nichts gegen eine Probephase, auch wenn ich das ganze noch nicht ausprobiert habe. (Ich hoffe einfach, ich muss nachher nicht andauernd "Erledigt"-Flags entfernen...) --Datei:Sugimori 672.pngMecanno-manMäh 10:47, 27. Feb. 2016 (CET)
Ich verstehe irgendwie nicht, was du damit meinst msnsorry.gif -- 609.png Skelabra2509 (Diskussion | Beiträge) 19:27, 27. Feb. 2016 (CET)
Wäre dafür, dann für jedes Projekt solch eine "Bitte überprüfen"-Markierung einzuführen, da dadurch das Problem mit patrol für Projektleiter gelöst werden würde. – shadowtweaker 17:02, 28. Feb. 2016 (CET)

Disambiguator

Die Extension:Disambiguator erlaubt einen besseren Umgang mit Begriffsklärungen. So werden diese aus Spezial:Verwaiste Seiten sowie Spezial:Kürzeste Seiten ausgeblendet. Links auf BKLs und Weiterletingen darauf werden mir einer speziellen CSS-Klasse (.mw-disambig) markiert, was eine leichte Erkennung auch nach dem Softwarechange erlaubt, der das derzeitig von einigen Benutzern verwendete Skript untauglich macht. Spricht irgendwas gegen die Installation? -- 609.png Skelabra2509 (Diskussion | Beiträge) 22:21, 20. Feb. 2016 (CET)

Könnte hilfreich sein. – shadowtweaker 23:10, 20. Feb. 2016 (CET)
Ich bin dafür, diese einzufügen. --Datei:Sugimori 672.pngMecanno-manMäh 23:18, 20. Feb. 2016 (CET)
Ebenfalls dafür. -- 359.png Korvel1 Diskussion 11:30, 21. Feb. 2016 (CET)
+ 384.gif Jones 12:15, 21. Feb. 2016 (CET)
Könnte sich für uns als hilfreich herausstellen, deshalb wäre ich ebenfalls dafür. ~ Taisuke 136.gif 03:30, 24. Feb. 2016 (CET)
Installiert. --Datei:Sugimori 672.pngMecanno-manMäh 13:46, 12. Apr. 2016 (CEST)
Wir haben das jetzt ja, und das ist auch schon in der Wartung eingefügt. Blöderweise werden da natürlich auch alle gewollten Links auf Begriffsklärungen (z.B. zu Beginn jedes Pokémon-Artikels) aufgeführt. Wäre es möglich, sowas da rauszunehmen? @Skelabra2509: Lg --Toben des Meeres. Killuu http://i.imgur.com/5kAfY2r.png 23:46, 28. Apr. 2016 (CET)
Nun ja, die einfachste Möglichekit wäre, für die Pokémon-Begriffsklärungen andere Vorlagen zu verwenden, die _DISAMBIG_ nicht enthalten. Auf die Dinger kann man ja gar nicht ausversehen verlinken. Das wäre allerdings auch keine perfekte Lösung, da MediaWiki diese Seiten dann nicht mehr als Begriffsklärungen erkennen würde – was gewisse Vorteile mit sich bringt. Allerdings dürfte das in Zukunt meines Wissens zumindest bei den Pokémon-Begriffsklärungen eh kein Problem mehr darstellen, da die afaik mittelfristig gelöscht werden sollen. -- 609.png Skelabra2509 (Diskussion | Beiträge) 20:08, 29. Apr. 2016 (CEST)

Datei Lizenzen und Wasserzeichen

Wie im Chat schon einige male angesprochen, wäre es sinnvoll, dass das Lizenzsystem etwas überarbeitet/erweitert wird. So haben wir aktuell keine Lizenz für Merchandise als solches (momentan meist als Artwork gekennzeichnet), die Lösungsbücher werden auch meist als Artwork gekennzeichnet, obwohl dort ja eigentlich der jeweilige Verlag Rechte dran hat und wir haben keine einheitlichen Lizenzen für Wiki Dinge (sei es Pokéwiki, Wikipedia oder EP). Ein relativ gute Liste hat shadow hier zusammengestellt, es gibt jedoch noch einige Dateien mehr, die einfach falsch lizensiert sind. Vorallem für die EP und Pokéwiki Dinge sollten sich Admins und Bürokraten eine Lizenz aussuchen, daneben ist es sicherlich nicht verkehrt, wenn allgemeine Meinungen zu den Lizenzen (wie genau wollen wir sein, ähnliche Lizenzen zusammenfassen etc) noch ausgesprochen werden.

Daneben gibt es (vorallem ältere) Dateien, welche noch ein Wasserzeichen haben und damit eigentlich der jeweiligen Lizenz widersprechen, hierzu wäre auch eine Klarstellung, möglich der Administration, vonnöten, wie diese gehandhabt werden sollen (entfernen vs ignorieren). 384.gif Jones 12:13, 21. Feb. 2016 (CET)

Da es bei Lizenzen um Themen mit rechtlicher Relevanz geht, würde ich es begrüßen, wenn sich zu diesem genannten Thema mind. einer der beiden Bürokraten (Buoysel, Matze) äußern könnte. Zumal ich persönlich jetzt beispielsweise nicht sehr bewandert bin, was das Thema Lizenzierungen angeht. Bezüglich der Dateien mit Wasserzeichen wäre es wirklich gut zu wissen, wie damit umzugehen ist. Größtenteils wurden sie ja bereits ersetzt bzw. sind nicht mehr vorhanden und neue, bereitgestellte Screenshots/Bilder sind frei von solchen Zeichen. Aus diesem Grund vermute ich eher, dass man die alten Dateien durch neue (ohne Wasserzeichen) ersetzen könnte. ~ Taisuke 136.gif 03:30, 24. Feb. 2016 (CET)
Von mir aus können Bilder mit Wasserzeichen auch ersetzt werden, wenn vorhanden. Die stammen halt noch aus einer Zeit, als nirgends Bilder ohne Wasserzeichen verteilt wurden und wir daher davon ausgingen, dass es von Rechteinhabern entsprechend unerwünscht ist. Es gibt z. B. auch große Websites wie IGN, die alle Bilder (bis heute noch?) mit großen Wasserzeichen versehen. ~ 418.gif Buoysel 16:02, 24. Feb. 2016 (CET)

Ein weiteres Problem, welches mir heute aufgefallen ist, sind Bilder von Personen. Momentan sind sie als Bild-frei gekennzeichnet, was in den meisten Fällen auch korrekt sein dürfte. Jedoch sind bei einigen Bildern keine oder nicht mehr erreichbare Quellen angegeben, so dass nicht genau nachgeprüft werden kann, in welchem Zuge die Bilder erstellt wurden, weswegen wohl Abschnitte über Persönlichkeitsrechte erwähnt werden mussten Deutsche Rechtssprechung hexe.gif. Ich hoffe nach meinen Klausuren mich noch etwas genauer mit der ganzen Thematik beschäftigen zu können, möchte aber schonmal darauf hinweisen.
Daneben wäre es eventuell nicht schlecht, wenn wir die Lizenzen, die auf Bulba in Gebrauch sind, mal mit unseren abgleichen und entsprechende Pendants sammeln. Oft werden ja Bilder von Bulba bei uns hochgeladen und solange es sich nicht um offizielle Dinge handelt ist es häufig schwer eine passende Lizenz zu finden. 384.gif Jones 23:47, 24. Feb. 2016 (CET)

Pokéteca

Wie die meisten vermutlich wissen, ist das spanische Wiki seit 2 Jahren nicht mehr erreichbar, die Interwiki Links sind jedoch noch vorhanden. Bulba hat die Links vor kurzem entfernt, weswegen bei uns die Frage aufkam, ob wir diese nicht ebenfalls entfernen sollen. So weit ich weiss, gab es bei den Admins bereits Diskussionen in die Richtung. Da anscheinend die Pokéteca Administration jedoch nicht mehr erreichbar ist, sollten wir eine Entscheidung bzgl Pokéteca treffen, wobei ich für das Entfernen der Interwikis wäre. 384.gif Jones 12:13, 21. Feb. 2016 (CET)

Bin auch für eine sofortige Entfernung, Bulba hats auch bereits gemacht ohne Absprache mit anderen Wikis. – shadowtweaker 12:46, 21. Feb. 2016 (CET)
Hab ich auf Discord angesprochen. (Dort sind nun alle EP-Wikis ausser dem polnischen vertreten) --Datei:Sugimori 672.pngMecanno-manMäh 12:59, 21. Feb. 2016 (CET)
Schließe mich hier den anderen an und befürworte eine Entfernung der spanischen Interwiki-Links. ~ Taisuke 136.gif 03:30, 24. Feb. 2016 (CET)
Dafür. ~ 418.gif Buoysel 16:02, 24. Feb. 2016 (CET)
Ist dieses Thema noch aktuell? Ich sehe nämlich bei vielen Artikeln immer noch die Verlinkung. --491.png Azett Reue 09:37, 27. Feb. 2016 (CET)
Ich glaube, die können weg. Auf Discord hat Misdre gesagt, das Poképedia die auch bald entfernen wird, demnach wären wir nachher das einzige Wiki (ausser dem polnischen, aber naja...) welches noch spanische Interwikis hat. --Datei:Sugimori 672.pngMecanno-manMäh 10:47, 27. Feb. 2016 (CET)
Bisher hat sich noch kein Bot darum gekümmert, Azett. Zumindest in den Pokémon-Artikeln wurden sie in den letzten Tagen bis einschließlich der dritten Spielgeneration entfernt und die weiteren drei Spielgenerationen werden folgen. Projektübergreifend müsste sich auch einer der Botbetreiber dazu bereit erklären, um das dann zu übernehmen. ~ Taisuke 136.gif 10:52, 27. Feb. 2016 (CET)
Korrekt, bei den Pokémon-Artikeln ist shadowtweaker bereits dran. Ich werde mich die Tage mal mit ihm zusammensetzen und gucken, wie wir bzw wer von uns das löst. 384.gif Jones 11:19, 27. Feb. 2016 (CET)
Kann man das nicht gleich mitmachen? So wie ich es verstanden habe, werden die PKM-Artikel doch eh mit einem Bot umstrukturiert und da könnte man das doch gleich mitmachen, oder? -- Liebe Grüße, Moltres 146.gif 15:23, 28. Feb. 2016 (CET)
Wird schon gemacht. – shadowtweaker 17:02, 28. Feb. 2016 (CET)

Es sollten jetzt alle Interwiki-Links entfernt worden sein. – shadowtweaker 15:08, 14. Mär. 2016 (CET)

Pokemon Weiterleitungen

Ebenfalls würde ich gern wikiweit Einheitlichkeit bzgl der Pokemon → Pokémon Weiterleitungen haben. Im Anime Projekt sind sie, zumindest bei den Filmen, immer vorhanden, beim Spieleprojekt immer mal wieder, in anderen Bereichen jedoch gar nicht. Da dasselbe im Grunde auch für andere „Sonder“zeichen gelten würde, würde ich persönlich von diesen Weiterleitungen absehen. 384.gif Jones 12:13, 21. Feb. 2016 (CET)

Würde da versuchen, einen Mittelweg zu finden. Es gibt zum Beispiel viele Artikel mit dem Suffix „(Pokémon Mystery Dungeon 2)“, wo eine Weiterleitung mit e statt é wirklich unnötig wäre. Bei Artikeln, die aber gerne mal direkt in die Suche eingetippt werden (insbesondere Filme und Spiele), werden Weiterleitungen mit e statt é aber schon ab und zu aufgerufen, denke ich. – shadowtweaker 12:46, 21. Feb. 2016 (CET)
Das sollte, imho, für alle Sonderzeichen eingerichtet werden (Bot?); weil alle Artikel über die Suche aufrufbar sein sollten [da ist é nicht wirklich das wichtigste, eher solche wie ★, δ und ’]. --Datei:Sugimori 672.pngMecanno-manMäh 12:59, 21. Feb. 2016 (CET)
Würde eigentlich bei allen Titeln mit Pokémon die Weiterleitung anlegen. Wer tippt denn schon das é mit ein? Ich nicht, und das auch bei spezifischeren Artikeln. --Vorsicht, heiß! Killuu http://i.imgur.com/wVf4WMM.png 18:57, 23. Feb. 2016 (CET)
Ich tippe eher ein é ein, als irgendwelche anderen Sonderzeichen, die nicht auf meiner Tastatur sind ;)
Bzgl Bot: Im Grunde dürfte es möglich sein, allerdings würden solche Fälle, wie der von shadow beschriebene, dabei vermutlich etwas schwieriger werden. Auch wäre die Frage, inwieweit Weiterleitungen mit Sonderzeichen nochmals Weiterleitungen bekommen (doppelte WL natürlich aufgelöst). Beispiel wäre Pokémon Gelb → Pokémon Special Pikachu Edition, gäbe es dann die Weiterleitung Pokemon Gelb? 384.gif Jones 02:34, 24. Feb. 2016 (CET)
Eine klare Linie würde dem Ganzen sicherlich gut tun. Momentan läuft das Ganze doch recht unstrukturiert, weshalb ich dem Vorschlag von shadowtweaker eher skeptisch gegenüber stehe, da man dann an der momentanen Situation nichts ändern würde. Mal wird eine solche Weiterleitung angelegt und mal nicht. In meinen Augen macht es sich besser, wenn wir uns entweder klar für die Weiterleitungen aussprechen oder halt eben gar nicht. Auch wenn ich wohl einer der wenigen Benutzer bin, die selbst in der Suche mit „é“ arbeiten, befürworte ich dennoch allgemein die Anlegung von Weiterleitungen, um die Suche nach Artikeln mit Sonderzeichen zu erleichtern. Hierbei würde ich aber auch gerne festhalten, dass Artikelnamen mit mehreren Sonderzeichen (z. B. Liste der Pokémon in Pokémon Shuffle) trotz allem nur eine Weiterleitung bekommen (→ Liste der Pokemon in Pokemon Shuffle). Die gemischten Weiterleitungen (Liste der Pokémon in Pokemon Shuffle und Liste der Pokémon in Pokemon Shuffle) empfinde ich als unnötig, weil man bei der Eingabe in der Suche (oder URL) entweder komplett auf Sonderzeichen verzichtet oder sie halt durchweg benutzt. ~ Taisuke 136.gif 03:30, 24. Feb. 2016 (CET)
Ich schließe mich Tai in allen Punkten an. (Der vorstehende nicht signierte Beitrag stammt von: Skelabra2509 • Diskussion • Beiträge)
Ich ebenfalls. --Datei:Sugimori 672.pngMecanno-manMäh 10:47, 27. Feb. 2016 (CET)
Wie sieht es denn mit dem oben beschriebenen Fall der doppelten WLs aus? Ansonsten scheint hier ja Einigkeit zu herrschen. Daneben gibt es übrigens auch noch einige Fälle, gerade bei Vorlagen, wo die Vorlage nur ohne Sonderzeichen vorhanden ist, bspw Vorlage:Pokedex eintrag. Wie soll mit diesen verfahren werden? 384.gif Jones 11:19, 27. Feb. 2016 (CET)
Meiner Meinung nach bitte keine doppelten Weiterleitungen, sondern alle auf den Hauptartikel. Vorlagen brauchen das wohl nicht. --Kein Dschungel zu dicht... Killuu http://i.imgur.com/acgb9YG.png 11:33, 27. Feb. 2016 (CET)
Doppelte WLs natürlich aufgelöst, die Frage war eher, inwieweit Sonderzeichen in WLs selber behandelt werden (weiter oben ist auch ein Beispiel dazu) 384.gif Jones 11:49, 27. Feb. 2016 (CET)
Achso, zu deinem Beispiel: Ja, ich finde solche Weiterleitungen sollte es natürlich auch geben. --Kein Dschungel zu dicht... Killuu http://i.imgur.com/acgb9YG.png 11:57, 27. Feb. 2016 (CET)

Greenchu

Ping Buoysel und Matze
Leider ist es momentan leider so, dass nur die Bürokraten Zugriff auf den Greenchu Server haben, was aktuell dazu führt, das eine ganze Reihe von Sprites fehlen, bzw auf diese gewartet wird (um jetzt nur zwei Beispiele zu nennen: Picross Sprites und Briefe der zweiten Generation). Teilweise enden diese Sprites dann als Datei hier im Wiki, teilweise fehlen sie aber einfach. Ich würd mich darum für eine Änderung der aktuellen Regelung aussprechen:

  1. Genereller FTP Zugriff für Admins - Admins sind meistens leichter zu erreichen und wissen oft selber, was gerade gebraucht wird
    1. Eventuell könnte man das mit einem kleinen Uploadscript lösen, welches sowohl via API ein Login anbietet, welches die Berechtigung überprüft, als auch das direkte Hochladen von ZIP Archiven erlaubt
  2. Die Einrichtung eines zweiten Wikis als Image Repository. In diesem Wiki könnte die Registrierung abgeschaltet werden und die Bürokraten würden nach Bedarf Accounts erstellen/sperren. Würde vermutlich auch die Einbindung der Dateien vereinfachen. Wäre jedoch die Frage, inwieweit der Overhead sinnvoll ist.
  3. Verschieben der Dateien ins Wiki. Es sind wie gesagt bereits eine ganze Menge an Sprites hier, vorallem die PMD Items.

Daneben gibt es sicherlich noch eine ganze Reihe weiterer Möglichkeiten, wie sich diese Problematik lösen lässt. Auch wäre es eine Überlegung wert, ob nicht auch Redakteure Zugriff bekommen sollen. Auch wäre eine öffentlich einsehbare Richtlinie wünschenswert, von wo diese Sprites kommen dürfen, Bulba hat eine ganze Reihe der fehlenden, im Chat konnte mir jedoch keiner sagen, ob und inwieweit diese auf Greenchu landen dürfen. 384.gif Jones 22:04, 28. Feb. 2016 (CET)

Danke fürs Ansprechen dieses Themas, mich stört die Einbindung von greenchu-Bildern auch regelmäßig. Mit der ersten Alternative wäre ich nicht zufrieden, da weder sichtbar ist, was wann wo geändert wird, noch die übliche MediaWiki-Funktionalität bereitsteht, um beispielsweise Links auf nicht existente Dateien zu bemerken. – shadowtweaker 22:15, 28. Feb. 2016 (CET)
Die zweite Möglichkeit scheint mir sinnvoll, aber das ganze hängt wohl arg von der Meinung der Bürokraten ab. Ich bin gegen eine Direktverschiebung ins Wiki, da die Dateien auch auf filb benutzt werden. --Datei:Sugimori 672.pngMecanno-manMäh 22:22, 28. Feb. 2016 (CET)
Brächte einer Verschiebung ins PokéWiki nicht die gleichen Nachteile mit sich wie die Verschiebung in ein Repository? -- 609.png Skelabra2509 (Diskussion | Beiträge) 22:30, 28. Feb. 2016 (CET)
Ich sehe den Vorteil darin, dass wir dadurch nicht tausende Dateien schützen müssen; und von kaskadierendem Schutz halte ich persönlich nicht all zu viel. Eine Möglichkeit für die Direktintegration wäre noch ein separater NS. --Datei:Sugimori 672.pngMecanno-manMäh 22:51, 28. Feb. 2016 (CET)
Hmm, ich biete eigentlich schon immer an, dass man mir ZIP-Archive mit Ergänzungen per E-Mail schickt, die dann nach kurzer Überprüfung exakt so auf den Server hochgeladen werden. ~ 418.gif Buoysel 23:57, 4. Mär. 2016 (CET)

Benennung von Artikeln, deren deutscher Name (noch) nicht bekannt ist

Zunächst wird meistens ein Artikel unter seinem japanischen Namen angelegt und sobald der deutsche bekannt ist, der Artikel dorthin verschoben wird. Soweit so gut, jedoch gibt es auch einige Fälle, wo Artikel zwischenzeitlich unter ihrem englischen Namen abgelegt werden (wenn dieser bekannt ist, der deutsche jedoch noch nicht). Auch hier würde ich gerne eine wikiweite Entscheidung haben, ob

  1. Japanisch → Englisch → Deutsch oder
  2. Japanisch → Deutsch.

Ich persönlich wäre für ersteres. 384.gif Jones 12:13, 21. Feb. 2016 (CET)

Ersteres. – shadowtweaker 12:46, 21. Feb. 2016 (CET)
Im TCG-Bereich: Japanisch → Englisch → Deutsch, da dort das Englische dem Deutschen ähnlicher ist als in anderen Bereichen; in anderen Bereichen Japanisch → Deutsch, das andere hätte bloss noch mehr Änderungen zur Folge (z. B. könnten wir den gesamten Manga-Bereich umstrukturieren...) --Datei:Sugimori 672.pngMecanno-manMäh 12:59, 21. Feb. 2016 (CET)
Dachte eigentlich, dass das so wie im ersten Beispiel gehandhabt wird. Wäre auch dafür, besonders weil man nicht immer weiß, ob noch alles ins Deutsche übersetzt wird. Dann tümpel ich lieber bei englisch als bei japanisch rum. --Vorsicht, heiß! Killuu http://i.imgur.com/wVf4WMM.png 18:56, 23. Feb. 2016 (CET)
Man könnte den Manga Bereich ja vorerst außen vor lassen. Oder dort nur Weiterleitungen anlegen (ich weiß nicht, wie genau das aktuell da gehandhabt wird). Ich denke vorallem immer an die Suche, ich für meinen Teil suche eigentlich eher nach englischen Dingen (das verstehe ich wenigstens) als nach japanischen. 384.gif Jones 02:30, 24. Feb. 2016 (CET)
Ich wäre hier ebenfalls für eine einheitliche Lösung und würde die erste Variante bevorzugen. Sollte es, wie Mecanno-man oben bereits genannt hat, dazu kommen, dass sowohl der englische als auch deutsche Name zeitnah/gleichzeitig bekannt werden, so würde ich hier ebenfalls eine direkte Verschiebung von Japanisch zu Deutsch begrüßen. ~ Taisuke 136.gif 03:30, 24. Feb. 2016 (CET)
Ich bin auch für die erste Version. Meines Wissens nach müsste das auch die Variante sein, die am meisten praktiziert wird (jedefalls mache ich das immer so). Wichtig ist halt, wie Tai schon sagt, dass wir das Ganze einheitlich gestalten und wir eine solche Regelung vllt. mal irgendwo für die Zukunft festhalten sollten. -- Liebe Grüße, Moltres 146.gif 15:27, 28. Feb. 2016 (CET)
Abgerufen von „https://www.pokewiki.de/index.php?title=PokéWiki:Allgemeine_Diskussionsseite/Archiv_2016&oldid=1252835“