Wikiup:Verbesserungsvorschläge/Archiv/2011/November

aus Wikipedia, der freien Enzyklopädie
< Wikiup:Verbesserungsvorschläge‎ | Archiv
Dies ist die aktuelle Version dieser Seite, zuletzt bearbeitet am 31. Mai 2022 um 18:45 Uhr durch imported>PerfektesChaos(310926) (lf).
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

E-Mail-Sende-Hinweis

Gibt es eine Möglichkeit hierfür?
Wenn ein Wiki-Benutzer einem anderen über die Werkzeug-Funktion „E-Mail an diesen Benutzer“ angeklickt hat und er danach unten auf der Seite „E-Mail an Benutzer“ (nachdem er seinen E-Mail-Text verfasst hat) auf „Senden“ geklickt hat, dass der angesprochene Benutzer auf seiner Diskussionsseite einen kleinen (anonymen) Hinweis (z. B. „jemand hat an Dich eine E-Mail geschickt“, „Du hast E-Mail erhalten“ oder noch schlichter „E-Mail-Postfach prüfen“; o. ä.) bekommt? So muss man nicht dauernd sein E-Mail-Postfach (egal bei welchem Provider) prüfen!
MfG --TOMM 17:17, 3. Nov. 2011 (CET)

Bug 32177 eröffnet. -- ianusius: (↔ Diskussion) 17:40, 3. Nov. 2011 (CET)
Wurde abgelehnt. Ein Benachrichtungssytem gibt es aktuell noch nicht. Bei der E-Mail ist aber das Problem zu erfahren, wann die E-Mail gelesen wurde und somit der Hinweis verschwinden soll. Ich denke auch, das Wiki-Mails in den meisten Fälle keine so höhe Dringlichkeit haben, wie ein Hinweis auf der Benutzerdiskussionsseite. Dies sollte sich der Schreiber immer Bewusstsein. Ich würde es als erledigt ansehen, wenn nicht, dann einfach den Baustein entfernen. Der Umherirrende 15:13, 19. Nov. 2011 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: Der Umherirrende 15:13, 19. Nov. 2011 (CET)

Käptscher bitte auf Deutsch umstellen

Seit doch bitte mal so freundlich, und stellt diese störenden Käptscha- oder Käptscher-Abfragen (englisch „CAPTCHA“ geschrieben) – also den automatischen Turing-Test – wenigstens auf Deutsch um. Daß die dort abgefragten Wörter oder Wortkombinationen auf Englisch sind, erschwert die richtige Beantwortung unnötigerweise zusätzlich sehr. --92.225.56.223 08:50, 5. Nov. 2011 (CET)

Das wird schon lange gewünscht: bugzilla:5309. Falls du Firefox mit Greasemonkey verwendest, gibt es zumindest eine Rechtschreibprüfung für die CAPTCHAS: [1]. --Schnark 09:20, 5. Nov. 2011 (CET)
Siehe auch mailarchive:wikitech-l/2011-November/056078.html ff. --Schnark 09:35, 5. Nov. 2011 (CET)

Literaturhinweise aus ISBN generieren

Falsch formatierte Literaturnachweise fallen oft negativ auf. Dieses Problem könnte umgangen werden, wenn wir eine Vorlage oder ein Toolserverscript hätten das bei Angabe einer ISBN eine saubere Literaturangabe erstellt, durch Rückgriff auf die DNB oder die LoC. Ist so etwas machbar?--Antemister 13:13, 5. Nov. 2011 (CET)

Es gibt die Vorlage:BibISBN. -- Jesi 14:21, 5. Nov. 2011 (CET)
Es gibt ein Javascript, das man als angemeldeter Benutzer in seine common.js einbinden kann: includePage('Benutzer:Dietzel/proveit-de-min.js');
Bei mir funktioniert's, allerdings weitgehend ungetestet. Bei Angabe einer ISBN wird eine entsprechende Vorlage:Literatur ausgegeben. --Dietzel 15:43, 5. Nov. 2011 (CET)
Schon, das es bei den meisten meiner Fragen hier schon ein solches Skript gibt... @Dietzel, wie funktioniert es?--Antemister 18:43, 6. Nov. 2011 (CET)
Wenn du einen Artikel bearbeitest, solltest du rechts unten einen blauen "prove it"-Kasten haben. Wenn du damit einen neuen Nachweis erstellst und die ISBN angibst, versucht das Javascript, die offenen Felder auszufüllen. Die Daten kommen von openlibrary.org --Dietzel 19:25, 6. Nov. 2011 (CET)

toolserver-links auf den versionsgeschichten der lemmata

...analog zu den sehr nützlichen weblinks (nach aufrufen der benutzer-edits (mittels Spezial:Beiträge/xyz) könnte ich mir sowas ähnliches auch im ANR vorstellen: z.b.

Wikipedia Article Traffic | Finde den Hauptautor | o.ä.m, unter der letzten zeile jeder versionsgeschichte angebracht

→Benutzerin:Nicola nannte es bei sich "Praktische Tools"...

(damits nich missverstanden wird: ich meine lediglich die nackten links - insofern isses ein kompromiss zum abgewiesenen vorschlach in FAQ no.1 ...) lg, --ulli purwin fragen? 13:59, 7. Nov. 2011 (CET)

Wenn du so etwas wie luxo:Ulli Purwin meinst, dann solltest du auf meta:Talk:Interwiki map vorstellig werden, wobei ich selbst dagegen bin, für alles Mögliche und Unmögliche einen Interwikilink einzuführen. Dann doch eher eine Vorlage, die die Seite als Parameter übernimmt. --Schnark 10:38, 8. Nov. 2011 (CET)
...häh? nur nochmal zum verständnis:
wenn du Spezial:Beiträge/Schnark aufrufst, haste ganz unten deine unterseiten, editcounter etc.
wenn du die versionsgeschichte von Artikel aufrufst, könnten da nach meinem vorschlach ähnlich sachbezogene links stehen(wie oben beschrieben) - und zwar "blank", so daß es rein statisch wäre, und keine weitere rechenzeit benötigt, solange man da nix eingibt. oder nich? da steht bis jezz aber nur der button "gewählte versionen vergleichen"...

ich sehe halt eine gewisse parallele zwischen den "beiträgen eines benutzers" und den "versionen eines lemmas" - deshalb kam ich drauf. lg, --ulli purwin fragen? 11:22, 8. Nov. 2011 (CET)

Jetzt meine ich zu verstehen, was du meinst: Du willst {{Artikel-DC}} (oder etwas ähnliches) automatisch auf jeder Versionsgeschichte sehen. Unten geht nicht, da ist nämlich keine Systemnachricht, in die man etwas einbauen könnte, es würde allenfalls oben in der Legende gehen, wenn ein Administrator das in MediaWiki:Histlegend einbaut, so wie es auch in en:MediaWiki:Histlegend ist. --Schnark 11:31, 8. Nov. 2011 (CET)
PS: Wenn du (vermutlich um "Links auf diese Seite" reinzuhalten) keine normale Wikilink-Syntax in deiner Signatur verwendest, dann setzte den Link bitte auf //de.wikipedia.org/wiki/Benutzer_Diskussion:Ulli_Purwin ohne das Protokoll, dann funktioniert das auch für Benutzer die wie ich mit https surfen. --Schnark 11:34, 8. Nov. 2011 (CET)
ganz doof ausgedrückt: wer inne versionsgeschichte schaut, will genaueres über die sache wissen. son link wie "wer iss hauptautor" wäre ein paradebeispiel - sicher gibts noch weitere sinnvolle, die man ergänzen könnte... son kasten halt, wos gesammelt auf einen blick vorliegt. die derzeitige alternative iss doch, daß sich jeder benutzer sowas selbst auf ner eigenen unterseite basteln muß... redundant hoch drei! --ulli purwin fragen? 11:44, 8. Nov. 2011 (CET)
Das ganze wurde schonmal gewünscht. Die Seitenbetreiber hatten damals keine Einwände gegen die Verlinkung ihrer Tools. Es hat sich nur kein Admin gefunden der dies macht. Steht auch in m:MediaWiki:Histlegend drin, was damals als Beispiel genannt wurde. (Wikipedia:Verbesserungsvorschläge/Feature-Requests/Archiv/2011#Externe Tools unter Reiter Versionsgeschichte)
@Ulli Purwin: Externe Links in Signaturen sind verboten, dazu gehört alles was mit http anfängt. Der Umherirrende 20:55, 8. Nov. 2011 (CET)
...danke, ich habs jezz korrigiert (frage mich allerdings, warum diese offensichtliche mediawiki-lücke(via 'plainlinks') überhaupt besteht... besser wärs doch, das generell unmöglich zu machen!) lg, --ulli purwin fragen? 12:39, 9. Nov. 2011 (CET)

Sprache der Interwikis

Die Angabe der Interwikis in der Originalsprache ist sinnlos und nervt. Wenn ich mir z.B. den Artikel in der litauischen Wikipedia anschauen will, muss ich erraten das ich auf "Lietuvių" klicken muss. Früher hat das nicht gestört weil man nur die litauische Seite nur aufrief wenn man Litauisch konnte, aber heutzutage übersetzt Google jede Webseite automatisch ins Deutsche. --Uranus95 20:42, 8. Nov. 2011 (CET)

Es gibt eine Benutzerskript, das sie dir automatisch ändert. Schreib dazu folgende Zeile in Benutzer:Uranus95/common.js (Weitere Hilfe für dich als Programmierer auch unter Wikipedia:JS, vielleicht verlinkst willst du auch direkt auf GoogleTranslate linken):
importScript('Benutzer:Revolus/monobook.js/sidebartranslate.js');
hilft -- ✓ Bergi 22:57, 8. Nov. 2011 (CET)
Für mich ist die Angabe der Interwikilinks in der Originalsprache nicht sinnlos oder nervig, da sie für jeweilige Muttersprachler gedacht ist. Wikipedianer werden in der Regel wissen, welche Sprache sich jeweils hinter dem Link verbirgt. Falls nicht, lässt sich das mithilfe von Artikeln ganz schnell klären. Die Kürzel sind ebenfalls ganz leicht zu merken und schon ist alles klar. Diese Bezeichnungen sind weltweit gleich und nicht nur für Mitteleuropäer gedacht... Ich schlage auch mal in Sprachausgaben nach, deren Sprache ich nicht wirklich beherrsche, um mir die Artikel aus reiner Neugier anzuschauen (Tellerrand). -- JCIV 20:55, 9. Nov. 2011 (CET)
Ich finde die Originalsprache auch sinnvoll, aber z.B. ein Mouseovertext mit der deutschen Bezeichnung wär schon nett. --Svíčková na smetaně 21:24, 9. Nov. 2011 (CET)
+1 - das fände ich auch gut. Außerdem wäre es sinnvoll wenn sie wirklcich in alphabetischer Reihenfolge wären. Denn es hilft nix hu nach g kommt aber magyar erst nach dem l --K@rl (Verbessern ist besser als löschen) 21:39, 9. Nov. 2011 (CET)
+1 Wenn die Links alphabetisch sein sollen, dann muss die Bezeichnung auch komplett in deutsch sein, sonst führt das wieder zu Verwirrungen. Ich habe mich allerdings an die jetztige Sortierung gewöhnt, da sie in den meisten Sprachversionen so üblich ist. -- JCIV 22:04, 9. Nov. 2011 (CET)
+1: Bug 32332 für deutsche Tooltips. -- ✓ Bergi 22:47, 9. Nov. 2011 (CET)
BTW: meta:Interwiki sorting order und Bug 8078 (wontfix) für deutsche Linktexte. -- ✓ Bergi 22:47, 9. Nov. 2011 (CET)

Ungesichtete Seiten auf der Beobachtungsliste

In Magnus Tool Deep out of Sight gibt es die Möglichkeit alle 10 aufgelisteten Artikel mit ungesichteten Änderungen in Tabs öffnen zu lassen. Das fände ich auch für die Spezialseite die mir die ungesichteten Seiten auf meiner Beobachtungsliste anzeigt, sehr nützlich. Es grüßt --Coatilex 09:30, 10. Nov. 2011 (CET)

Sortierung innerhalb der Kategorie

Es ist derzeit möglich innerhalb einer Kategorie einen Artikel unter dem ersten Zeichen einzuordnen, sowir beispielsweise Mayer|1Mayer nicht unter M sondern unter 1 eingeordnet. Praktisch wäre dieses feature für sie Sortierung z.Bsp. 4-stellig , so könnte man den Herrn Mayer mit Mayer|1989Mayer unter 1989 einreihen in einer Kategorie einreihen. Bei 1989Muller käme so der Müller nach dem Mayer im Jahr 1989. So könnte man Sortierungen z.Bsp. bei Verleihungen oder Siegen etc. -- vielleicht gibts da eh was ähnliches --K@rl (Verbessern ist besser als löschen) 15:16, 16. Nov. 2011 (CET)

Man kann so sortieren, nur wird immer nur der erste Buchstabe angezeigt, was hier vermutlich nicht gewünscht ist. Eine Möglichkeit, diesen Unterpunkt zu beinflussen kenne ich gerade nicht. Da Kategorien aber meistens zur Alphabetischen Auflistung genutzt werden, weiß ich nicht, ob es umbedingt notwendig ist. Die Entwickler fragen kann man über Bugzilla. Der Umherirrende 15:06, 19. Nov. 2011 (CET)
Genau das ist ja der Wunsch, nur so könnte man auch die Beziehung zu der Verwendung von Kategorien noch verbessern. --K@rl (Verbessern ist besser als löschen) 14:57, 21. Nov. 2011 (CET)
Allerdings sehe ich das insofern problematisch, weil dann unterschiedliche Auffassungen über die Sortierreihenfolge durchgesetzt werden würden, was am Ende zu keiner (erkennbaren) Sortierung führen könnte. -- Jesi 17:06, 21. Nov. 2011 (CET)
Für so etwas wäre eine Liste in Form einer sortierbaren Tabelle geeignet. Wollte man das wirklich in Kategorien machen, dann müsste die Software mehrere Sortierschlüssel zur Auswahl anbieten. Wäre natürlich toll wenn man in jeder Kategorie nach den anderen Kategorien sortieren könnte, also nach Geburtsjahr, Sterbejahr, Beruf, Staat, Flusssystem, Taxonomie, wasweissich. Aber ... --Diwas 23:03, 21. Nov. 2011 (CET)
Na so weit wollte ich es ja nicht treiben, aber ich wollte z.Bsp Preistrager wie folgt einordnen
1999
Hans Mayer
Franz Müller
2000
Fritz Anders
Hanso So

Eingetragen sollten sie dann werden als

Kategorie:Preisträger xy|1999Mayer, Hans
Kategorie:Preisträger xy|1999Muller, Franz etc.

so sollte es in der Kategorie erscheinen. --K@rl (Verbessern ist besser als löschen) 23:45, 21. Nov. 2011 (CET)

Das wäre schon mal technisch problematisch, weil die Software wissen müsste, wo der Sortierschlüssel aufhört und der Eintrag beginnt. Und dann würde dieses Feature mit Sicherheit auch in anderen Zusammenhängen benutzt werden, z.B. für Geburtsjahre von Philosophen usw, weitere Beispiele hat ja Diwas genannt. Dann käme das Chaos zustande. Obiges Beispiel sollte doch – wenn es denn erforderlich erscheint – mit Unterkategorien gelöst werden können. -- Jesi 09:21, 22. Nov. 2011 (CET)
Man könnte das schon so machen, wenn man sich einig wäre, dass in einer Kategorie nur die Jahreszahl wichtig ist, nur wird es vermutlich genauso viele Leute geben, die vorrangig nach den Namen sortieren wollen. ... Jetzt verstehe ich erst das Problem, du gibst dich nicht mit der Reihenfolge zufrieden und mit dem Jahrtausend als Überschrift, sondern du willst auch die Jahreszahl als (Zwischen-)Überschriften. Da wäre dann schon irgendwie eine erweiterte Software und ein erweiterter Syntax nötig. Naja zumindest müsste die Software eine Auswahl auf der Kategorienseite erlauben, ob man nach dem ersten Zeichen oder den ersten vier Zeichen Gruppieren will. Würde die Software noch erlauben, zu entscheiden ob man den Sortierschlüssel ab der ersten oder ab der fünften Stelle nutzen will, wäre das tatsächlich möglich. Aber ob du für sowas jemanden motivieren kannst? Grundsätzlich wäre ich sehr für zusätzliche Möglichkeiten Kategorien darzustellen. (Beispielsweise, alle Einträge aus den Unterkategorien gruppiert auf einer Seite anzeigen, oder Schnittmengen ... Immerhin werden ja jetzt schon 200 Unterkategorien und gleichzeitig 200 Artikel angezeigt, was teilweise sehr viel Zeit spart.) --Diwas 13:26, 22. Nov. 2011 (CET)
Es ist deutlich einfacher zu implementieren als einstellbare Sortierreihenfolge… Daher war ich mal optimistisch und habe Bug 32585 angelegt. Nach Jahr sortierte Kategorien wird man erst in der Community durchsetzen müssen, ich sehe aber größere Vorteile darin ewig große Kategorien (Kategorie:Frau etc) nicht nur per Vorlage:TOC Große Kategorie übersichtlich zu machen, sonderen auch längere Überschriften (Aa, Ab, Ac … Zz) zu ermöglichen. -- ✓ Bergi 15:10, 22. Nov. 2011 (CET)
Das {{#categorysections:4}} setzt man auf die Kategorieseite, richtig? Nicht schlecht. Die Bedeutung der Parameter 2 und 3 kann ich mir aber bisher nur grob zusammenreimen, aber das muss ich ja nicht unbedingt wissen. --Diwas 15:44, 22. Nov. 2011 (CET)
Das wäre auch nur die komplizierte Lösung. Dort könnte man dann festlegen, dass die Anzeige mit 4 Stellen nur für bestimmte Bereiche gilt, z.B. alles was mit 1 oder größer und 9 oder kleiner beginnt, also nur die Zahlen. Oder dass alle mit M beginnenden mit 2 Stellen statt mit einer angezeigt werden etc., vgl vielleicht die Biographielistenüberschriften. -- ✓ Bergi 16:03, 22. Nov. 2011 (CET)
Danke an Bergi, nur zur Erläuterung, warum ich sowas gerade für Preisträger etc. möchte. Unterkategorien wären dann interessant wenn ich jährlich 20 Preisträger habe, aber meist sind das nur 1- 5, wo sich die U-Kat nicht auszahlen. Vielleicht erübrigt sich das, wenn auch eine flache Darstellung aller U-Kat als eine möglich wird - aber das ist halt auch Wunschdenken :-) --K@rl (Verbessern ist besser als löschen) 16:14, 22. Nov. 2011 (CET)

Beobachtungsliste

In der Beobachtungsliste erscheint folgende Anzeige

Es sind aktuell ungesichtete Bearbeitungen von gesichteten Seiten auf deiner Beobachtungsliste.

Anzeigeoptionen

279 beobachtete Seiten

76 Änderungen der letzten 3 Tage (Stand: 24. November 2011 um 19:28 Uhr) 1 | 2 | 6 | 12 Stunden, 1 | 3 | 7 | 30 Tage

Erstmal konnten die Leerzeilen vor und nach Es sind aktuell... wingespart werden. Und die folgenden 3 Zeilen

279 beobachtete Seiten

76 Änderungen der letzten 3 Tage (Stand: 24. November 2011 um 19:28 Uhr) 1 | 2 | 6 | 12 Stunden, 1 | 3 | 7 | 30 Tage

könnten zu einer Zeile zusammengefasst werden. Dann rückt die erste Zeile der Beobachtungsliste schon mal weiter rauf. Natürlich bleibt das Scrollen nicht erspart, aber ein wenig Einsparung von Weissraum wäre trotzdem nicht schlecht.--Ohrnwuzler 20:35, 24. Nov. 2011 (CET)

Versuchs mal mit folgendem in Benutzer:Ohrnwuzler/common.css:
/* schönere Beobachtungsliste (von [[Benutzer:✓|Bergi]]) */
#mw-watchlist-options > hr {
    display: inline;
    content: ": ";
    color:inherit;
    background: none;
}
#mw-watchlist-options > br {
    display: none;
}
div#mw-fr-watchlist-pending-notice + div /*.mw-specialpage-summary */ + fieldset#mw-watchlist-options {
    margin-top: 0;
}
#contentSub {
    margin-bottom: 0;
}
Die ersten beiden Regeln rücken die 3 Zeilen zusammen. Die letzteren beiden entfernen die Abstände (nicht Zeilen) zwischen Untertitel („Beo von…“), dem Satz zu ungesichteten Änderungen und dem Kasten. Sieht imho aber nicht mehr gut aus; die letzte Regel greift auch auf anderen Seiten – die würde ich rauslassen (oder zumindest nicht mit 0 Abstand). -- ✓ Bergi 21:57, 24. Nov. 2011 (CET)

Editor für die Druckversion

Hey, mir ist gerade mal wieder aufgefallen, wie nützlich es wäre, wenn ich meine Artikel vor dem Drucken noch fix formatieren könnte. Z.B. einfaches löschen von Grafiken/Bildern oder ganzen Abschnitten. Klar, das kann man auf 100 andere Arten lösen, aber weshalb nicht auch so? ;) Oder gibts das schon...? --Sagehorn 17:25, 16. Nov. 2011 (CET)

Benutze einfach die Entwicklerwerkzeuge deines Vertrauens, mit denen kann man gut im Quelltext herumpfuschen… Wie genau stellst du dir das vor, ein Kontextmenü "löschen"? Welche Druckansicht meinst du überhaupt, ?printable=yes oder einfach nur das Druck-CSS? Bei letzterem ließe sich was komfortables zusammenskripten (stell ich mir jetzt mal wie einen Textmarker vor, sobald man versucht die Seite zu drucken verschwindet das markierte dann). Wenn du an einem Userscript dafür interessiert bist, verschiebe diesen Abschnitt einfach in die Skin-Werkstatt – wenn dabei was nettes herauskommt kann man es ja vielleicht auch als Gadget anbieten. -- ✓ Bergi 16:08, 22. Nov. 2011 (CET)

Hey. Danke für die Antwort. Ja, ich spreche von "printable=yes" und wenn ich das richtig einschätze, müsste man da erst ein bisschen mehr verändern, um das allgemein möglich zu machen.. Dafür bräuchte man wohl eine Art Interface (etwa so wie beim Schreiben/Editieren eines Artikels), welches Wikipedia aber meiner Meinung nach mehr als verdient ;) Bin da leider nicht allzu sehr involviert, mich würde mal interessieren, wie sich bei Wikipedia überhaupt solche technischen Aspekte über die Zeit verändern. Das passiert ja nicht hier, sondern eher auf der Developer-Ebene oder? Wie gesagt: Klar - Ich kenn viele Möglichkeiten, meine Texte gut zu formatieren, aber so wäre es natürlich besonders elegant. Vor allem würde ich mir auch ne Option wünschen, mit der die Beschriftungen in Kopf- und Fußzeile deaktivierbar sind. Und zu guterletzt sollte es nicht passieren, dass die erste/letzt Zeile im Text abgeschnitten wird. Bitte versteht das bloß nicht als Flaming.. Ich erwarte mir hier eher sowas wie ein Feedback auf das Feedback ;) --Sagehorn 10:25, 25. Nov. 2011 (CET)

Ein netter kleiner Hack (funktioniert nicht nur bei Wikipedia, sondern auch auf anderen Webseiten): Gib javascript:document.body.contentEditable='true'; document.designMode='on'; void 0; in die Adresszeile ein, und schon kannst du die Seite nach Belieben verändern und dann so ausdrucken. --Schnark 11:47, 25. Nov. 2011 (CET)

Falschschreibungen

Für Falschschreibungen werden kein Weiterleitungen angelegt. Für häufige Falschschreibungen wird ein Artikel mit der Vorlage:Falschschreibung angelegt. Die Vorlage zeigt einen Falschschreibungshinweis an. Der Hinweis selbst ist pädagogisch sinnvoll. Der dazu angelegten Artikel hat aber den Nachteil, dass nun unter der Falschschreibung ein Artikel existiert. Das Lemma ist somit existent. Dies hat folgende Auswirkungen:

  • Unter Spezial:Alle Seiten, unter Spezial:Präfixindex und viele weiteren Spezialseiten wird der Titel aufgeführt.
  • Spezial:Suche findet diesen Artikel wie einen normalen Artikel und leitet gegebenenfalls direkt auf diesen Artikel weiter.
  • Die Suchvorschläge des Suchfeldes bieten dieses Lemma an.
  • Externe Suchmaschinen finden unter dem Titel eine Seite und indizieren diese Seite.
  • Falschschreibungshinweise sind kein enzyklopädischer Inhalt und gehören daher nicht in eine Enzyklopädie.
  • verlinkte Falschschreibungen sind blau.

Verbesserungsvorschlag: Der Falschschreibungshinweis wird statt von einer existenten Seite von einer gelöschten Seite ausgegeben. Die oben beschriebenen Nachteile wäre damit alle beseitigt. Mit dem Löschlogbuch oder dem Sperrlogbuch können Hinweise auf gelöschten Seiten angebracht werden. Vielleicht kann mit einer speziellen Erweiterung die Darstellung für Falschschreibungshinweise verbessert werden.

Ich bitte um Meinungen zu diesem Verbesserungsvorschlag. --Fomafix 14:54, 26. Nov. 2011 (CET)

Eine Ausgabe übers Löschlogbuch ist hässlich und wird von vielen Lesern vermutlich gar nicht wahrgenommen. Außerdem hat der Falschschreibartikel den Vorteil, dass er verlinkt werden kann und man (mit dem BKL-Gadget) in der Vorschau sofort sieht, dass man auf eine Falschschreibung verlinkt hat. Würde dort nur ein roter Link stehen, würde man sich vielleicht denken, dass der Artikel noch nicht existiert und dies nicht weiter überprüfen. --32X 15:32, 26. Nov. 2011 (CET)
Ein Hinweis im Löschlogbuch alleine ist kein ausreichender Falschschreibungshinweis. Die Darstellung muss verbessert sicherlich werden. Dass ein Link auf eine Falschschreibung rot ist, ist vollkommen richtig, denn es existiert auch kein Artikel unter dem falschen Titel. Falschschreibungen müssen weiterhin als solches markiert werden, damit sie weiterverarbeitet werden können: Das BKL-Gadget muss dann statt auf die Kategorie:Wikipedia:Falschschreibung auf die neue Markierung prüfen. Weiterhin können Bots wie bisher Falschschreibungslinks korrigieren. Die neue Falschschreibungsmarkierung benötigt also weiterhin ein Verweis auf die richtige Schreibweise. Die technischen Details müssen noch ausgearbeitet werden. Zunächst müssen aber erst die Anforderungen zusammengetragen werden und die Community muss das wollen. --Fomafix 16:14, 26. Nov. 2011 (CET)
Dann wäre ein __NOINDEX__ in Verbindung mit schnellen Bots die einfachere Variante. Ich habe jedoch schon mehrfach von der FS-Vorlage bei Google-Suchen profitiert, so dass ich alles beim Status Quo belassen würde (zumal die Entwicklerkapazitäten derzeit wohl für andere wichtige Projekte wie Bildfilter vergeudet werden). --32X 16:45, 26. Nov. 2011 (CET)
Ein __NOINDEX__ würde nur externen Suchmaschinen empfehlen die Seite nicht zu indizieren. Die weiteren oben genannten Probleme bestehen dann weiterhin. Wie hat Dir die Falschschreibungsvorlage bei einer Google-Suche geholfen? Meinst Du damit, dass bei einer Suche nach einer Falschschreibung Wikipedia als erster Treffer ausgeführt wurde und dort wurde Dir gesagt, dass Du eine Falschschreibung verwendet hast? Vielleicht können die bestehenden Funktionen von MediaWiki bereits schon so konfiguriert werden, um den dazu notwendigen Prozess abzubilden. In diesem Fall müssten die Entwickler nicht mal etwas tun. --Fomafix 16:56, 26. Nov. 2011 (CET)
Google-Suche: Ja, "ist falsch" mit prompter Lieferung eines richtigen Stichwortes. --32X 20:36, 27. Nov. 2011 (CET)
Google findet auch Seiten in anderen Namensräumen. Wenn Du bei Google nach Falschschreibung suchst, sind die ersten drei Treffer Vorlage:Falschschreibung, Kategorie:Wikipedia:Falschschreibung und Wikipedia:Häufige Falschschreibungen. Falschschreibungshinweise müssen also nicht im Artikelnamensraum stehen, um von Google gefunden zu werden. --Fomafix 21:17, 27. Nov. 2011 (CET)
Hallo. Zu einen übersiehst Du hier die Vorlage:Obsolete Schreibung, die neulich eingeführt wurde. Soll die dann auch wieder abgeschafft werden? Zum anderen gilt das Argument "verlinkte Falschschreibungen sind blau" nicht wirklich, da es im ANR keine beständigen Links auf Falschschreibungsseiten gibt. Weiterhin sind z.B. Begriffsklärungsseiten und Weiterleitungen auch kein enzyklopädischer Inhalt, jedoch hier technisch erforderlich. Falschschreibungsseiten hingegen könnte es analog in einer gedruckten Enzyklopädie auch geben. Dass die Suche die Falschschreibungsseiten auch findet, empfinde ich nicht als störend, immerhin kommt man ja schließlich zur gewünschten Seite, was immerhin besser ist, als wenn das Suchergebnis leer wäre. Insgesamt sehe ich hier kein Problem, das gelöst werden müsste, oder zumindest keins, was den dargestellten Aufwand (Mediawiki-Edits nur durch Admins, oder gar Softwareentwicklung) rechtfertigen würde. --Krd 18:49, 28. Nov. 2011 (CET)
Obsolete Schreibweisen könnten prinzipiell auch mit der hier vorgeschlagenen Änderung behandelt werden. Hier ist es das bisherige Vorgehen aber auch in Ordnung, denn eine obsolete Schreibweise war mal eine gültige Schreibweise. Eine Falschschreibung war, ist und bleibt eine Falschschreibung. Die Bots korrigieren Links auf Falschschreibungen. Das ist richtig. Ein neu eingebender Text mit einem Link auf eine Falschschreibung hat zunächst mal einen blauen Link, obwohl die Schreibweise falsch ist. Begriffsklärungsseiten und Weiterleitungen sind sehr wohl enzyklopädischer Inhalt. Schau mal in eine Enzyklopädie Deiner Wahl. Falschschreibungen hingegen gibt es in keiner Enzyklopädie. Mit meiner hier vorgeschlagenen Änderung wird unter dem Falschschreibungslemma weiterhin die richtige Schreibweise verlinkt. Die entscheidende Änderung ist, dass nicht zuerst Falschschreibungen mit angeboten werden, sondern nur richtige Schreibweisen. Ich finde es sehr störend, wenn in den Suchvorschläge des Suchfeldes mehrere Schreibweisen angeboten werden und ich mich erst durchklicken muss, bis ich die richtige Schreibweise gefunden habe. --Fomafix 20:47, 28. Nov. 2011 (CET)

Technische Umsetzung 1

Hier eine mögliche Umsetzung eines Falschschreibungshinweis auf nicht existenten Seiten am Beispiel der Falschschreibung Reagensglas:

Andere technische Umsetzungen sind auch denkbar. --Fomafix 12:05, 27. Nov. 2011 (CET)

Damit wird das Erstellen einer Falschschreibung aber deutlich erschwert. Wikipedia wurde ja schon mehrfach für immer größere Hürden für neue Autoren kritisiert. --32X 20:36, 27. Nov. 2011 (CET)
Das Erstellen eines Falschschreibungshinweis ist kein enzyklopädischer Beitrag. Der einzige Unterschied gegenüber bisher ist, dass der Falschschreibungshinweis in einem anderen Namensraum erstellt wird, damit im Artikelnamensraum keine Falschschreibungen sind. --Fomafix 21:17, 27. Nov. 2011 (CET)
Mir gefällt die Lösung ganz gut. Nur der Umbau von Bots und Gadget könnte etwas komplizierter sein, da dann auch für Rotlinks die Api abgefragt werden muss - zurzeit werden die einfach ignoriert. Was für andere technische Umsetzungen fielen dir denn ein? -- ✓ Bergi 22:27, 27. Nov. 2011 (CET)

Derzeit können mit einem API-Aufruf zu allen Links eines Artikels ausgewählte Kategorien geliefert werden. Mit dem obigen Vorschlag befinde sich die Kategorie:Wikipedia:Falschschreibung nicht mehr im Artikel Reagensglas, sondern im Artikel Vorlage:Falschschreibung/Reagensglas. Der bisherige API-Aufruf wird daher die Links nur als Link auf einen nicht existenten Artikel angeben. Um einen Link auf eine markierte Falschschreibung zu überprüfen sehe ich für das BKL-Gadget folgende Möglichkeiten:

  • Für jeden Rotlink wird eine separate API-Anfrage mit dem Präfix Vorlage:Falschschreibung/ gestellt.
  • Möglicherweise bietet die API auch die Möglichkeit für eine Sammelanfrage, bei der mehrere Rotlinks auf einmal geprüft werden können.
  • Die Liste der angelegten Falschschreibungshinweise in der Kategorie:Wikipedia:Falschschreibung kann über die API heruntergeladen werden. Daraus kann eine clientseitige Falschschreibungsliste gehalten werden. Die Liste muss nicht bei jeder neuen Seite mitgeschickt werden, sondern sie kann asynchron aktualisiert werden.
  • Über die oben beschriebene Methode wird der Inhalt einer Vorlage auf eine nicht existente Seite geladen. Die Vorlage beinhaltet auch die Kategorie:Wikipedia:Falschschreibung. Theoretisch müsste damit eine nicht existente Seite mit der Kategorie markiert werden. Wenn dass funktioniert, dann könnte die bisherige API-Abfrage weiterverwendet werden.
  • Sollte dies nicht funktionieren, könnte diese Funktionalität bei den Entwicklern beantragt werden.

--Fomafix 09:50, 28. Nov. 2011 (CET)

Ich habe einen Test durchgeführt. Über MediaWiki:Noarticletext und bei uns zusätzlich über Vorlage:MediaWiki Noarticletext NS kann neben Text auch eine Kategorie in einen nicht existenten Artikel eingebunden werden. Diese Einbindung kann durch #ifexists auf bestimme Seitentitel beschränkt werden. Auf der nicht existenten Seite wird diese Kategorie angezeigt. Die nicht existente Seite wird aber nicht in die Kategorie eingetragen. --Fomafix 15:04, 28. Nov. 2011 (CET)
  • (BK) Ein Request pro Rotlink: Vergiss es, da bricht der Server zusammen und du hast die Seite schon wieder verlassen, bevor alle Infos geladen wurden
  • Ja, eine Sammelanfrage ist durchaus möglich. Dennoch wird das Datenvolumen deutlich steigen, wenn auch sämtliche Rotlinks überprüft werden müssen – das ist mein eigentlicher Kritikpunkt.
  • Die Liste aller Falschschreibungen zu cachen… Könnte bei vielen Rotlinks sinnvoll sein, ist aber nicht ganz trivial. Und würde ebenfalls das Datenvolumen erhöhen.
  • Nein, nicht existente Seiten können keiner Kateorie zugeordnet werden (und sollen auch nicht). Eine in der Bearbeitungsansicht angezeigte Vorlage kann dies sowieso nicht auslösen.
meint -- ✓ Bergi 15:19, 28. Nov. 2011 (CET)
Danke für die Hinweise. Das habe ich auch so vermutet. Für das BKL-Gadget benötigen wir daher entweder eine serverseitige Erweiterung von den Entwicklern oder die Liste der Falschschreibungen aus der API wird clientseitig gecached. --Fomafix 15:35, 28. Nov. 2011 (CET)

Technische Umsetzung 2

Zuerst mal muss ich Krd beipflichten (bis auf das falsch verstandene MediaWiki-Nr-Admin editieren). Dabei fällt mir aber auch eine andere Möglichkeit ein: Eine neue MediaWiki-Kategorie für Falschschreibungen, exakt so umgesetzt wie bei Begriffsklärungen. Das bedeutet eigene Spezialseiten, API und als Neuerung könnte man die Suche modifizieren, sodass bei gefundener Falschschreibung der Hinweis gleich auf der Suchseite angezeigt wird. -- ✓ Bergi 20:30, 28. Nov. 2011 (CET)

Zusätzliche Spezialseiten und Optimierungen der Suchvorschläge und Suchergebnisse sind natürlich immer gut. Du versuchst hier Falschschreibungen im Artikelnamensraum zu behalten, aber per zusätzliche Erweiterungen teilweise zu verbergen. Mit einem Verschieben der Falschschreibungen in einen anderen Namensraum lässt sich das verbergen einfacher erreichen und lässt einen normalen Zugriff per Namensraumpräfix weiterhin zu. Im Gegensatz zu Begriffsklärungsseiten sind Falschschreibungen kein enzyklopädischer Inhalt. --Fomafix 21:09, 28. Nov. 2011 (CET)

Symbole für Geburts- und Sterbedaten

Liebe Wikis, mir ist aufgefallen, dass Geburts- und Sterbedaten bei Wikipedia grundsätzlich mit * und † gekennzeichnet werden. Dies sind allerdings rein christliche (!) Zeichen (Stern quasi Geburt Jesu, Kreuz Tod Jesu)! Aber sie werden bei wikipedia auch bei Personen nichtchristlichen Glaubens verwendet wie z. B. beim jüdischen Violinisten Yehudi Menuhin. Klar ist eine Vereinheitlichung der Einfachkeit halber sinnvoll, allerdings wird da nichtchristlichen Personen etwas Fremdes übergestülpt, mit dem sie sich ggf. überhaupt nicht bzw. niemals identifiziert haben. Eigentlich kann man so was nicht bringen...bei Muslimen würde das Kreuz ja auch fatal wirken/aussehen...Lösungsvorschlag: (X.X.XXXX - Y.Y.YYYY), oder bei lebenden Personen: (geb. X.X.XXXX). Das würde allen gerechter werden und wäre noch einfacher umzusetzen. Bitte um Diskussion :) --Susanne Wosnitzka 16:58, 28. Nov. 2011 (CET)

Auf dieser Seite bist du falsch, hier gehts um technische Vorschläge. Du könntest dich auf Wikipedia:Projektdiskussion melden, beachte aber bitte, dass das Thema schon zig Mal durchgekaut wurde. Die diversen Diskussionen sind mit der Suche schnell gefunden. XenonX3 - (☎:✉) 17:05, 28. Nov. 2011 (CET)
Siehe: Wikipedia:Meinungsbilder/Verwendung des genealogischen Kreuzzeichens --Krd 20:08, 28. Nov. 2011 (CET)

Suche

Ich habe heute über das Wikipedia-Suchfeld nach dem Film "Tree of Live" gesucht und die Ergebnisliste weit runtergescrollt und nix passendes gefunden. Erst als ich ganz korrekt "The Tree of Live" eingegeben habe, wurde der Artikel gefunden. Ähnliches ist mir schon öfter passiert. Die Suche scheint sehr pingelig zu sein. Geht das nicht heutzutage besser? (nicht signierter Beitrag von 178.5.183.242 (Diskussion) 01:20, 29. Nov. 2011 (CET))

live~ tree zeigt es an erster Stelle. live~ tree~ an zweiter, hmm, könnte man unter den Suchergebnisliste einen Link einbauen, der die Ähnlichkeitssuche startet? --Diwas 02:20, 29. Nov. 2011 (CET)

Automatischer Koordinateneinbau aus anderen Sprachversionen

Wäre es realisierbar, die Koordinaten bei Ortsartikeln usw. aus anderen Sprachversionen irgendwie automatisiert eingebaut zu bekommen? (Natürlich nur bei Artikeln, wo noch keine drin sind.) --77.183.112.27 12:49, 14. Nov. 2011 (CET)

Ich habe die Diskussion zu dieser Frage nach Wikipedia Diskussion:GEO#Automatischer Koordinateneinbau aus anderen Sprachversionen verschoben, ist dort besser aufgehoben. Hier bitte nicht weiter diskutieren. --PM3 01:57, 3. Jan. 2012 (CET)
Abgerufen von „https://de.wikiup.org/index.php?title=Wikiup:Verbesserungsvorschläge/Archiv/2011/November&oldid=223327756“