Wikipedia:Umfragen/Technische Wünsche/Übersicht

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Diese Seite dient als zusammengefasste Übersichtsseite zu Wikipedia:Umfragen/Technische Wünsche, da die Seite in mehrere Unterseiten aufgeteilt wurde.

Die Änderungen können unten angeschaut werden.

Übersicht[Quelltext bearbeiten]

Die [Bearbeiten]-Links an den Abschnitten führen direkt auf die richtige Seite

Bearbeiten[Quelltext bearbeiten]

  • Bearbeitung "live" (wie Office) durchführbar (siehe hier). Wenn möglich mit Synchronisation, sodass man gemeinsam an Texten arbeiten kann (nicht wie bisher "hintereinander").
  • Ein Formeleditor, so dass die Formelzeichen "schöner" und vor allem schärfer werden und sich besser in den Text einfügen (Textstil, Größe,...)
  1. Pro --RöntgenTechniker (Diskussion) 23:33, 16. Nov. 2013 (CET) Kann nur besser werden.[Beantworten]
  2. Kontra Darstellung mit MathJax ist bereits implementiert (und müsste nur noch allgemein zur Default-Einstellung gemacht werden). Mit MathJax ist die Schärfe und Größe der Darstellung in der Verantwortung des WWW-Browsers und hat mit Wikimedia nichts zu tun. Da auch die Darstellung der Fließtext-Schrift Sache des Browsers ist, ist das mit großem Abstand beste Lösung.
  3. Neutral da braucht es eigentlich nur ein besseres png-rendering Patrick Stützel (Diskussion) 21:25, 29. Nov. 2013 (CET)[Beantworten]

Tabellen[Quelltext bearbeiten]

  • Sortieren von Tabellen vor dem Abspeichern, so dass man neue Zeilen einfach am Ende einfügen kann.

Kategorien[Quelltext bearbeiten]

  • Kategorienänderungen durch Nachfragen (Willst du dies wirklich?) zu Autorenwerk ändern. Automatisierte Bot-Massenbearbeitungen für Kategorien abschaffen.
  • (Commons): Bildrepräsentanten für Medienkategorien und Anzeige dieser visuellen Repräsentanten zusammen mit den Namen der Subkategorien. Auswahl des Repräsentanten durch Zufall, FIFO, oder explizit.


Beobachtungsliste[Quelltext bearbeiten]

  • Ein Prioritäts-Parameter für die Beobachtungsliste mit der Möglichkeit nach dieser Priorität sortieren zu lassen.
  • Gebündelte Mailbenachrichtigung wie bei Mailman (täglich, wöchentlich, …)
  • Entfernung von Einträgen auf der Beobachtung direkt in der Liste per Häkchen oder so ermöglichen

Hinweise betreffend alle:

  • Etliche der gewünschten Möglichkeiten sind bereits unter WP:SKRIPT #Beo verfügbar.
  • Die Erfahrung damit hat gezeigt, dass es sehr viele unterschiedliche individuelle Wünsche gibt, wie wann was von wem mit wie vielen Bytes wie oft wie lange angezeigt werden soll, was zu sehr komplexen Konfigurationen führt. Die Notwendigkeit, diese private Wunschvorstellung in Regeln zu übertragen, überfordert jedoch oft die Anwender.
  • Bereits die recht trivialen Möglichkeiten der zusammengefassten Beo unter Einstellungen werden wenig genutzt und meist nicht verstanden. Je mehr Optionen es gibt, desto schwieriger wird es zu bedienen; auch durch Ausblendung eines Expertenmodus würde man anschließend von der Optionsvielfalt erschlagen.
  • Für die optische Gestaltung (Hervorhebungen bestimmter Einträge) gibt es ebenfalls ein breites Spektrum an Möglichkeiten: WP:CSS #Beo und ganz, ganz viele individuelle Vorlieben, die sich damit erfüllen lassen; einschließlich des Verbergens der zugehörigen Disk.
  • Die lange Wunschliste oben macht eindrucksvoll klar, dass es mannigfache unterschiedlichste Konfigurationswünsche gibt, mit denen dann wieder eine größere Zahl anderer Benutzer nichts anfangen kann. Und Automatismen, die das Leben vereinfachen sollten, haben oft unerwartete Auswirkungen, die es dann noch zusätzlich verkomplizieren.

VG --PerfektesChaos 11:10, 5. Nov. 2013 (CET)[Beantworten]

Dateien[Quelltext bearbeiten]

  • Commons: Bearbeiten von SVG-Dateien mit nahtloser Web-Oberfläche für die gängigsten Browser (bugzilla:38271)
  • Commons: Diff für Dateiformate, die üblicherweise lesbaren Text enthalten (Feature: mit zwei Vorschaubildchen und rot eingefärbten Änderungen in der Grafik selbst) (bugzilla:42566)
  • Commons: Bilderuploads in den Benutzernamensraum ermöglichen. Dort ist die Beschriftung und Ergänzung zum einen oft leichter, zum anderen kann man Bilder hochladen und zur Verfügung stellen, die man selbst noch nicht beschreiben/beschriften konnte, die dann aber Andere schon nutzen können, wenn sie wissen was es für ein Bildinhalt ist. Somit kann man größere Bildermengen auch gemeinsam bearbeiten, statt das nur dem Fotografen zu überlassen, der dafür womöglich lange Zeit benötigt.
    1. Pro Matt1971 (Diskussion) 10:42, 2. Nov. 2013 (CET)[Beantworten]
    2. Pro --19:32, 23. Nov. 2013 (CET)
    3. Pro Patrick Stützel (Diskussion) 14:30, 30. Nov. 2013 (CET)[Beantworten]
  • Bildbeschreibungsseiten: Über jedem Bild ein unüberesehbarer und unmissverständlicher Hinweis auf die Nutzungsbedingungen; gerne angelehnt an das Template "Creditline" (und am besten mit Zwansgeingabe beim Upload). Hintergrund des Wunsches: Beim Aufruf der Bildbeschreibungsseite füllt das Bild die Seite; die Optik lädt zum sofortigen Download ein; Hinweise auf Urheber und Nutzungsbedingungen werden viel zu spät sichtbar.

Hochladeassistent (Commons)[Quelltext bearbeiten]

  • Der Hochladeassistent sollte sich den Namen des Uploaders merken.
  • Der Hochladeassistent sollte sich optional den "persönlichen Marker" des Benutzer merken können. Dies kann sein, eine Kategorie (User-Kategorie) oder Vorlage (User-Vorlage mit spez. Lizenz-Hinweisen).
  • Der Hochladeassistent sollte sich alle Eingaben und die File-Keys merken und es im Falle eines Fehlers wiederherstellen (so wie MS Word nach einem Absturz das Dokument wiederherstellt).
  • Der Hochladeassistent sollte automatisch erzeugte Fehlermeldungen an die Entwickler senden (z.B. so wie "Fehlerbericht senden" unter Windows), damit die Probleme schneller behoben werden können und die Community vom Fehlerweiterleiten entlastet wird.
    1. Pro Michi 22:47, 29. Okt. 2013 (CET)[Beantworten]
    2. Pro Patrick Stützel (Diskussion) 14:32, 30. Nov. 2013 (CET)[Beantworten]
  • Der Hochladeassistent sollte für Kunstwerke die Parameter der Vorlage:Artwork anbieten.
    1. Pro--Oursana (Diskussion) 00:26, 4. Nov. 2013 (CET)[Beantworten]
    2. Pro Patrick Stützel (Diskussion) 14:32, 30. Nov. 2013 (CET)[Beantworten]
  • Der Hochladeassistent sollte den Benutzer beim Upload abgeleiteter Werke ("derivative works") von bereits auf Commons existierenden Dateien (z.B. Ausschnitte, Collagen) unterstützen. Man kann vom Gelegenheitsnutzer nicht erwarten, dass er/sie DerivativeFX findet.
  • Im Hochladeassistent an beliebiger Stelle Angaben nach unten kopieren nicht nur von der ersten Stelle an.
  • Das Kopieren (nach unten) funktioniert nicht mit allen Feldern, bei der WLM-Kampagne wird die Denkmalnummer nicht berücksichtigt. bugzilla:40147 (Namen der Gemeinden auch nicht)
    1. Pro Michi 22:47, 29. Okt. 2013 (CET)[Beantworten]
    2. Pro Patrick Stützel (Diskussion) 14:32, 30. Nov. 2013 (CET)[Beantworten]
  • Jemand sollte sich um den Commonist kümmern, ihn weiterentwickeln und für Bugs und Wünsche ansprechbar sein
  • Überprüfbarkeit der Weiternutzung von Commonsbildern in Mediawiki-Homepages außerhalb des Universums von Wikimedia
  • SMW & Co. auf Commons installieren
  • mobile Hochladung (in dem Falle via Android WebKit) sollte Sonderzeichen bringen [1]

Schwesterprojekte (ohne Dateispezifisches)[Quelltext bearbeiten]

Suche[Quelltext bearbeiten]

Einzelnachweise[Quelltext bearbeiten]

15:21, 2. Nov. 2013 (CET) Oder allgemeiner: siehe zwei Vorschläge weiter oben

  • Funktionalität von Vorlage:Cite web softwareseitig umsetzen, Zurverfügungstellen eines Widgets oder Browser-Add-ins, daß dafür Metadaten extrahiert und Auslagern der Einzelnachweise aus dem Artikelquelltext mit eigenem Editfenster dafür (etwa so, wie es Word in der Version 5.0 schon konnte)
    1. Pro --Morten Haan · Wikipedia ist für Leser da 21:42, 4. Nov. 2013 (CET)[Beantworten]
    2. Ganz starkes Pro, Blick übern Tellerrand: Bitte analog der englischen Wikipedia in der Bearbeitungsleiste als vierten Ausklapper nach Erweitert - Sonderzeichen - Hilfe - >"Einzelnachweise" bzw. diesen in das Buchsymbol integrieren. Im linken Fenster dann die Unterausklapper bzw. ohne Unterausklapper diese gleich als Buttons
      • cite web
      • cite Buch (hier wie oben angeführt könnte nach ISBN-Eintrag an erster Stelle ein Auto-Fill-in erfolgen < Dies bitte mal der en.Wikipedia-Softwareabteilung als Riesenfortschritt verklickern. >)
      • cite Zeitschrift
      • cite simple (<ref>EINZELNACHWEIS</ref>)
      Diese Neuerung hätte neben der unheimlichen Arbeitserleichterung für alle, die sonst paste and copy müssen, auch den Vorteil, dass endlich mal eine Vereinheitlichung erreicht würde, insbesondere bezüglich Datumsformat + Formulierung "abgerufen am DD. Monat YYYY". Hierbei das aktuelle Datum unbedingt gebläut schon voreingetragen. Sehnlichster Wunsch von --Frze > Disk 23:22, 4. Nov. 2013 (CET)[Beantworten]
      P.S.: Den Errorcheck könnte man, muss man aber nicht auch gleich mit übernehmen; wenn, dann sollten allerdings dort die drei Haken schon gesetzt sein. < Könntet Ihr das der en.Wikipedia-Softwareabteilung mal verklickern? Auch das mit dem gebläutem Datumsvoreintrag - wäre dort wichtig! > Ist aber in der deutschen Wikipedia kein bzw. kaum ein Problem. "Insert a named reference" ist meiner bescheidenen Meinung nach ebenfalls nicht nötig.
    3. Pro --Daniel749 Disk. (ST–WPST) 00:01, 5. Nov. 2013 (CET)[Beantworten]
    4. Kontra um gotteswillen keine Vorlagen wie cite web, buch und desgleichen mehr! -jkb- 01:26, 5. Nov. 2013 (CET) Du musst sie doch nicht benutzen. Ich finde die absolut sinnvoll, insbesondere z. B. in Bezug Zeitersparnis, Einheitlichkeit, Komfort für neuere Benutzer. In der Bearbeitungsleiste sind die Hilfe und Sonderzeichen vorhanden, ohne dass Du sie jemals bzw. allerhöchst selten benutzt hast. --Frze > Disk 06:43, 5. Nov. 2013 (CET)- - - Es geht nicht darum was ich tue, sondern darum, dass andere den Quellcode derart verunstalten, so dass nicht nur Neulinge aufgeben, dort etwas zu verbessern. -jkb- 12:58, 5. Nov. 2013 (CET) --- Mit "Du" meine ich uns. Der Quellcode wird doch in 0,00% keinster Weise verunstaltet und auch kein Neuling wird aufgeben, sondern sich freuen, wie einfach das Einzelnachweisen jetzt wird. Bitte einfach mal die en.WP ausprobieren - einfach und toll, einfach toll! --Frze > Disk 14:05, 5. Nov. 2013 (CET)[Beantworten]
    5. Pro --Oursana (Diskussion) 09:37, 5. Nov. 2013 (CET)[Beantworten]
    6. Pro --Chewbacca2205 (Diskussion) 19:47, 23. Nov. 2013 (CET)[Beantworten]
    7. Kontra--RöntgenTechniker (Diskussion) 00:28, 17. Nov. 2013 (CET) Keine Browser-Addons.[Beantworten]
    8. Kontra Patrick Stützel (Diskussion) 14:51, 30. Nov. 2013 (CET)[Beantworten]

Programmierung: Lua, Vorlagen, JS, CSS…[Quelltext bearbeiten]

  • Anstatt am Schluß der Editierfenster die verwendeten Vorlagen ansehen zu können (man muß erstmal scrollen, dann den Namen kennen, dann suchen, dann klicken), sollten Hyperlinks der verwendeten Vorlagen alternativ oder zusätzlich am Rand des Textes im Editierfenster neben der eingebundenen Vorlage eingeblendet werden. Evtl. nur als individuelle Benutzerkonfiguration. Realisation wohl nicht im Interface möglich (das weiß nicht welche Zeile gerade oben ist), daher wäre JavaScript-Funktion für ein Pop-Up zu entwickeln.

Autorenzuordnung[Quelltext bearbeiten]

Diskussionen[Quelltext bearbeiten]

Spezialseiten[Quelltext bearbeiten]

  • Auf der Liste der Benutzerbeiträge eines Benutzers kann man zwar über "Unterschied" die Änderungen sehen, dies ist aber nicht möglich, wenn der Artikel neu erstellt wurde. (Hier muss man umständlich über die Versionsgeschichte gehen.) "Unterschied" sollte mit der ersten Version des Artikels belegt werden.
    • Einwand: Auf den Benutzerbeiträgen kann man über den Zeitstempel die erstellte Version erreichen, was bei neu angelegten Seiten der ersten Version der Seite entspricht, ein zweiter Link auf die gleiche Version ist wohl eher irreführend.

Vandalismusbekämpfung/Benutzersperren/Seitensperren[Quelltext bearbeiten]

  • Ein Vorschlag, um edit-wars zu 'kanalisieren': Administratoren sollten einem strittigen Haupt-Artikel einen oder mehrere Positions-Artikel (Ansichten) zuordnen können, auf denen sich die Vertreter der jeweiligen Position 'ungestört' ausdrücken können. Softwaretechnisch ist dazu eine Einschränkung der Schreibrechte sinnvoll: Nur der Haupt-Artikel kann wie seither frei editiert werden. Doch sobald ein User eine Positions-Seite editiert, wird er (automatisch) dieser Sub-Community zugeordnet, und kann künftig keine andere Positions-Seite dieses Themas mehr editieren. Dabei hat der Admin die letzte Verantwortung dieser Autoren-Zuordnung, und kann z.B. auch die 'Konversion' eines Autors zu einer anderen Position - auf Anfrage - durchführen (Regeln?). Damit können kontroverse Positionen als Ansichts-Strömung getrennt entwickelt und wiedergegeben werden, ohne Störungen der Gegenseite, und ohne Anspruch auf Allgemeingültigkeit.
    1. Pro--RöntgenTechniker (Diskussion) 00:48, 17. Nov. 2013 (CET)[Beantworten]
    2. Pro ----Dieter (Diskussion) 12:05, 10. Dez. 2013 (CET)[Beantworten]
    3. Neutral Patrick Stützel (Diskussion) 15:14, 30. Nov. 2013 (CET)[Beantworten]
    4. Kontra RookJameson (Diskussion) 20:18, 30. Nov. 2013 (CET)[Beantworten]

Mobile Version[Quelltext bearbeiten]

  • [Nice-to-Have] Grafische Animation beim Aus- und Einklappen der Sidebar, bspw. durch folgende CSS-Attribute:
  -webkit-transition: margin-right 0.5s, text-indent 0.5s;
  -moz-transition: margin-right 0.5s, text-indent 0.5s;
  transition: margin-right 0.5s, text-indent 0.5s;

Zusätzliche Möglichkeiten zur Formatierung[Quelltext bearbeiten]

  • Mehr Flexiblilität bei der Formatierung von Links:
    1. Kontra das macht die Syntax nur unübersichtlicher Patrick Stützel (Diskussion) 15:22, 30. Nov. 2013 (CET)[Beantworten]
    • Zumindest die zweite Form funktioniert nicht, weil Pipe-Symbol (und auch eckige Klammern) völlig legitime Bestandteile der URL sind und zu Tausenden in der WP vorkommen. Gerade deshalb bildet hier das Leerzeichen die Trennung von Linkziel und Linktitel, weil eine URL nie ein Leerzeichen enthalten kann. Die erste Variante ist ebenfalls problematisch, weil sehr oft einzelne Wörter in eckige Klammern gesetzt werden, wie […] oder [Hrsg.] – also allenfalls mit Pipe-Symbol im Inneren unterscheid- und realisierbar. Damit gäbe es aber zwei verschiedene Syntax-Varianten; Wikilinks mit doppelten Klammern, mit ohne Pipe, mit einfachen Klammern aber niemals ohne Pipe; und insgesamt verwirrend für alle anderen, die den Quelltext lesen müssen. Generell wird eine einheitliche und gleichartige Syntax bevorzugt statt etlicher unterschiedlicher Notationen für den gleichen Effekt. --PerfektesChaos 09:53, 4. Nov. 2013 (CET)[Beantworten]
  • Bei Tabellen (Wikitables) sollte eine Formatierungsoption implementiert werden, die es dem Benutzer ermöglicht, tabellenweit je Spalte die Textausrichtung der Tabellenspalten vorzugeben. Details siehe Abschnitt „Tabellen: tabellenweite Vorgabe der Spaltenausrichtung?“ in dieser Version von WP:FZW.

Versionsgeschichte und Zusammenfassung[Quelltext bearbeiten]

Artikeldarstellung[Quelltext bearbeiten]

Sonstiges[Quelltext bearbeiten]

  • Möglichkeit auch für "normale" Benutzer Softwarefehler zu melden, etwa wie bei Gmail: Nach einem Klick auf "Softwarefehler melden" wird automatisch ein Screenshot erzeugt, auf dem man private Daten schwärzen und die relevanten Stellen hervorheben kann, dazu schreibt man einen kurzen Text als Erklärung und schickt das Ganze automatisch an die richtige Stelle
    • Stellungnahme:
      • Zur Fehlerbehebung sind konkrete Rückfragen erforderlich, siehe beispielsweise die Einführung auf WP:TW.
      • Was du in deinen Erläuterungen schreibst, reicht regelmäßig zur Reproduktion der Fehlersituation nicht aus, und der Screenshot sagt auch nichts darüber, in welcher Situation nach welchen Mausklicks unter welchen Rahmenbedingungen der Fehler auftrat.
      • Firmen wie G lassen solche Aktivitäten gern von ihren Benutzern ausführen. Die sind dann beschäftigt, bauen Frust ab, und glauben, etwas zur Problemlösung beigetragen zu haben – das gibt ein gutes Gefühl. Beruhigungs-Globuli.
      • Deine Nachricht wird dann allenfalls statistisch ausgewertet, ein Strichlein in deinem Benutzerprofil gemacht, und dann kommen screenshot und deine Erläuterungen in den Datenmüll. Du schreibst deutsch, russisch, japanisch; die indischen Entwickler verstehen nur englisch.
      • Die Software ist dort meist gut getestet und funktioniert in allen Standardsituationen. Wenn ein Fehler auftritt, muss es sich um eine ganz spezielle Situation handeln, und die muss so präzise beschrieben werden, dass das nur im Dialog mit dem Entwickler möglich ist. Du selbst hast nicht die Spur einer Ahnung, welche Details man wissen muss, weil irgendwas ungewöhnlich ist.
      • Bei uns kommt ein weiteres Problem hinzu: Der aufgetretene Fehler muss überhaupt nicht an MediaWiki liegen. Er könnte im Quelltext des Artikels liegen, in einer unserer Vorlagen, in einem Benutzerskript/Gadget, in deinem eigenen JavaScript, in deiner Browser-Konfiguration. Die Wikis sind sehr komplex, und die Programmierung bis hin zu Vorlagen liegt auf etlichen Ebenen. MediaWiki muss gar nichts mit dem Fehler zu tun haben, und das herauszufinden wird keine weltweit richtige Stelle für alle Wikis bewerkstelligen können.
    • Mutmaßliche Softwarefehler melden schnell und leicht: WP:FzW, WP:TW.
    VG --PerfektesChaos 15:05, 16. Nov. 2013 (CET)[Beantworten]
    1. Pro--RöntgenTechniker (Diskussion) 01:48, 17. Nov. 2013 (CET)[Beantworten]
    2. Pro Patrick Stützel (Diskussion) 15:52, 30. Nov. 2013 (CET)[Beantworten]
  • Zeitgemäßer Nachfolger für CAPTCHAs ([12] und weitere Threads in dem Umfeld)
  • "In anderen Sprachen" (nur bei Importen): automatische Erstellung eines Links zu der jeweiligen Sprache aus der der Artikel importiert wurde (würde in Zukunft haufenweise Nachträge ersparen)
    • Importe sind eine besondere Spezialität der deWP; Wikipedia:Importwünsche/importUtility kann aber bei Gelegenheit ausgebaut werden, so dass für die Dauer der Übrsetzung dies und anderes ermöglicht wird (Du meinst ein Permalink auf genau die Fremd-Version zum Zeitpunkt des Import-Schnappschusses?). Hierunter fallen auch etliche andere Quelltext-Modifikationen zu Zeit der Übersetzung. Nach Abschluss der Übersetzung ist es aber ein eigenständiger Artikel der deWP und kein Klon, der irgendwie permanent mit Veränderungen in einem anderen Projekt abgeglichen würde, und enthält deshalb auch keine derartigen Links mehr. --PerfektesChaos 10:34, 4. Nov. 2013 (CET)[Beantworten]
    • Gemeint ist damit die Liste unter dem Link "Sprachen" in der linken. oberen Spalte. Hier sollte statt manuell, automatisch ein Link auf die Ursprungsseite z.B. zu der enWp erstellt werden. Kerbal Space Program zum Beispiel kommt ursprünglich aus enWp. Der Verweis auf den englischen Artikel wurde allerdings erst einige Zeit später erstellt. Er wird bei vielen importierten schlicht vergessen. --Translator (Diskussion) 14:16, 15. Nov. 2013 (CET)[Beantworten]
  • Nochmals: Die Links in der linken Spalte entstehen traditionell als Interlanguage, neumodisch aus Wikidata.
    • Solange der Artikel noch im Benutzer-Namensraum steht und erst noch übersetzt wird, darf er noch nicht in der linken Spalte erscheinen; er existiert für die Wiki-Welt noch gar nicht. Während der Übersetzung gibt es ihn schlicht nicht, und er kann allenfalls auf seine Elternversion in dem fremden Wiki verlinken.
    • Erst in dem Moment, wenn er in den Artikel-Namensraum verschoben wird, sollte in der Tat etwas wirksam werden und die linke Spalte aktiv werden.
    • Es gibt die klassische Vorlage:Übersetzung. Ich kann die Anregung aufnehmen dahingehend, dass diese Vorlage mit bestimmten Parametern automatisch beim Import an den Wikitext angehängt werden soll, und sich dies beim Wechsel der Namensräume automatisch aktiviert und auch Wartungskategorien auslöst.
    • Voraussetzung ist, dass der Artikel erst importiert wird und danach übersetzt wird.
  • Was das als Beispiel erwähnte Kerbal Space Program angeht, so verlief das damals völlig anders:
    • 2013-01-02T10:28:12 wurde als C&P aus der enWP eine Übersetzung in die deWP geschrieben: Das war ein reiner Wikitext, der ohne irgendeinen Bezug zur Mutterversion erstellt wurde, und bei dem auch die Interlanguage-Links der englischen Version nicht übernommen wurden.
    • Erst 2013-01-02T21:48:20 wurde nachimportiert, und wir bekamen erst dann offiziell Kenntnis, dass es eine Verbindung dieses Artikels zur enWP gibt. (hier hätte das menschlich-manuell bemerkt werden können; aber auch eine erfahrene Importeurin könnte das mal übersehen, und sie war eigentlich auch überhaupt nicht dafür zuständig)
    • Wenn wie in diesem Fall plötzlich ein Artikel bei uns auftritt, haben weder wir noch irgendeine Software irgendeine Möglichkeit, auf magische Weise in der linken Spalte irgendwelche Verlinkungen zu erzeugen. Selbst wenn wie in diesem Fall in irgendeiner anderen WP ein Lemma gleicher Schreibweise existiert, dürfte keine Software automatisch irgendwelche Links generieren: Es könnte sich um zwei völlig verschiedene Personen gleichen Namens handeln. Oft wird bei gleichem Gegenstand aber auch die Bezeichnung und Schreibweise unterschiedlich sein; und wenn die Autoren nicht vermerken, dass sie den Text aus einer anderen WP übernommen haben und es inhaltlich das gleiche Thema ist, kann das keine Software nachholen.
    • Sowas automatisch irgendwelcher Software zu übergeben, richtet mehr Unsinn an, als dass es hilft; es gibt zu viele unterschiedliche Situationen, Forks usw. Es lässt sich auch nicht mit einem Nachimport verknüpfen, denn längst nicht immer ist die bei uns entstandene Seite themenidentisch mit der Ausgangsversion, aus der Textteile übernommen wurden.
  • Siehe: WP:Übersetzungen zum vorgesehen Ablauf.
Das ist jetzt ein recht langer Abschnitt; ich empfehle, gelegentlich Kopie auf die Disk und Löschung hier.
Schönes Wochenende --PerfektesChaos 13:15, 16. Nov. 2013 (CET)[Beantworten]
  • Ermöglichen, vor Neuanlage geschützte Seiten betreten zu können (Momentan nur über Umwege möglich da in der Suchfunktion der Link ausgeblendet wird) um diese z.B. per Klick auf die Beo zu nehmen
  • Mit Doppelpunkten eingerückte Absätze sollten nicht als Definitionslisten gerendert werden (bugzilla:4521)
  • Anregung: für alle Wikipedia:Tools, die Ergebnislisten liefern ein gemeinsames Werkzeug, damit die Ergebnisse in öffentlichen oder persönlichen Portalen zum Beispiel im Abstand von 1 Monat / 1 Woche / 1 Tag ein per Bot in eine Seite übertragen werden können.
  • Unbenötigt wird eine Anwendung "Gewünschte Artikel" anhand von "was linkt hierher" für eine Kategorie.

Letzte Änderungen[Quelltext bearbeiten]

Keine Änderungen während des angegebenen Zeitraums entsprechen diesen Kriterien.
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Wikipedia:Umfragen/Technische_Wünsche/Übersicht&oldid=124095420“