Wikibooks:Verbesserungsvorschläge

Aus Wikibooks
Wechseln zu: Navigation, Suche

Häufig gestellte Fragen · Ich brauche Hilfe · Meinungsbilder · Verbesserungsvorschläge
Rundschau · Schwarzes Brett · Bots  · Import

Crystal Clear app wp.png
Abkürzung:
WB:VV
Willkommen

Du hast Verbesserungsvorschläge zu Wikibooks? Hier kannst du sie vorstellen.

Für folgende Punkte gibt es eigene Seiten:

Neuer Vorschlag[Bearbeiten]

Archive

Ältere Vorschläge und Diskussionen:

Hilfe: Erste Schritte | FAQ | Kommunikation: Chat

Archivierung: Themen, die ausdrücklich als erledigt bezeichnet wurden, sind über das Archiv zu finden. Gleiches gilt für Themen, die „eingeschlafen“ sind und seit mindestens zwölf Monaten nicht mehr besprochen wurden. Genutzt wird das Archiv des Jahres, in dem der letzte Beitrag gespeichert wurde.

Default-Upload auf Commons[Bearbeiten]

Hallo,

wäre dieser Vorschlag für Wikiversity auch was für uns: v:Wikiversity:Cafeteria#Dateien_hochladen.2C_Assistent_zum_Hochladen_von_Dateien.3F? Vorteil: Wir müssten uns nicht mehr um die Verwaltung der meisten zukünftigen Bilder kümmern. Damit wäre der Verwaltungsaufwand für Admins und Co in Zukunft reduziert. Die für Bücher hier erstellten Dateien könnten einfacher in andere Wiki-Projekte eingebunden werden.

Grüße, Stephan Kulla 19:52, 19. Sep. 2014 (CEST)

Interessant. Vorteil außerdem: Sehr viele Dateien, die bisher bei de-WB hochgeladen werden, passen von vornherein zu Commons.
Andererseits gibt es diverse Probleme: Viele Autoren von Grafiken berücksichtigen die Wiederverwendung nicht (vor allem mit Beschriftungen als Teil der Datei, nicht separat als Teil der Dokumentation). Bei Commons müssen Dateien kategorisiert werden, was von den "Gelegenheits-Hochladern" nicht beachtet werden dürfte und sie tendenziell auch überfordern könnte. Schließlich gibt es schon bei uns das Problem der ungeeigneten Dateinamen (siehe die Löschankündigungen); auch wenn solche Dateien bei Commons wohl schnell wieder gelöscht werden, bleibt die Arbeit von Prüfung, Diskussion und Löschung. (Nun ja, das wäre auch ein Vorteil, nämlich dass diese Arbeit abgeschoben wird. 8-])
Fazit: Ich bin mir sehr unsicher, ob wir das anstreben sollten. Hauptgrund dafür ist am ehesten unsere personelle Situation. -- Jürgen 11:55, 20. Sep. 2014 (CEST)

Nur ein paar zusätzliche Anmerkungen:

  • Nicht kategorisierte Bilder werden per Bot schnell als „nicht kategorisiert“ markiert. Die Community übernimmt dann die Kategorisierung. Der Autor wird auch über die Benutzerseite informiert, dass er in Zukunft Bilder kategorisieren muss. Der Upload-Manager von Commons ist auch um einiges besser als unserer. Hier wird an entsprechender Stelle auf die Kategorisierung hingewiesen.
  • Commons hat viel mehr ehrenamtliche Mitglieder als wir (ist ja auch ein Gemeinschaftsprojekt aller Sprachen) und auch eine Community, die sich auf die Verwaltung der Medien-Dateien spezialisiert hat. Für uns ist diese Aufgabe zusätzliche Arbeit.
  • Die Sache mit ungeeigneten Dateinamen scheint auf Commons normal zu sein. Ich habe dort viele Dateien mit schlechten Namen gefunden (in der Regel die meisten Dateien).
  • Text in Dateien ist kein Problem (auch wenn dabei die Wiederverwendbarkeit reduziert ist). Für „Mathe für Nicht-Freaks“ liegen alle Bilder auf Commons und die meisten sind im Bild beschriftet. Hierzu hat sich in den letzten 5 Jahren noch niemand bei mir beschwert. Es gibt sogar Vorlagen, die auf eine Übersetzungsmöglichkeit der Bilder hinweisen.

Grüße, Stephan Kulla 19:53, 20. Sep. 2014 (CEST)

Gibt es hier Mediendateien die grundsätzlich nicht geeignet sind, auf Commons hochgeladen zu werden? Mir fallen keine ein also vorerst Symbol support vote.svg Pro. -- Qwertz84 13:52, 24. Sep. 2014 (CEST)

Wie bereits anderweitig diskutiert - hier eignet sich das besser für Dateien, die spezifisch für ein spezielles Buch sind. Etwa gibt es im SVG-Buch zahlreiche Graphiken, die von dem Vorschaubildermacher falsch interpretiert werden. Da es in dem Buch nicht um den Vorschaubildermacher geht, ist das für das Buch nicht wichtig, sondern vielmehr der korrekte Inhalt der Datei. Auf commons kann es hingegen Leute geben, die solche Graphiken für die mangelhafte Interpretation des Vorschaubildermachers 'optimieren' wollen, dafür gibt es dort sogar spezielle Anleitungen - das wäre aber unsinnig für das SVG-Buch. Ansonsten gibt es doch auf der Hochladeseite ohnehin schon einen entsprechenden Hinweis, Bilder mit allgemeingültigem Inhalt bei commons hochzuladen. Doktorchen 17:29, 24. Sep. 2014 (CEST)

„Ansonsten gibt es doch auf der Hochladeseite ohnehin schon einen entsprechenden Hinweis, Bilder mit allgemeingültigem Inhalt bei Commons hochzuladen.“ – welcher aber in der Vergangenheit oft ignoriert wurde.

Man kann ja „Datei hochladen“ in der Seitenleiste auf Commons schicken und ein Link auf Spezial:Hochladen irgendwo anders unterbringen (zum Beispiel auf einer Hilfeseite oder links unter "Datei speziell auf WB hochladen“). Die Sache mit den Bildern für das SVG-Buch ist eher speziell und betrifft nur die wenigsten. Stephan Kulla 19:57, 24. Sep. 2014 (CEST)

Die Diskussion hier entspricht dem Umfang bei anderen Themen auf de-WB und kann kaum als repräsentativ angesehen werden. Wenn ich mir aber ansehe, welche Art von Dateien in der letzten hochgeladen wurden und wie oft Stephan zuletzt Werbung für Commons gemacht hat (machen musste), sollten wir diesen Weg tatsächlich einrichten. Allerdings verstehe ich (noch) nicht, was alles zu ändern ist. Den Link auf Wikiversity (allererste Zeile) verstehe ich nur teilweise; auch ist mir unklar, was in Zusammenhang mit m:User:Nemo bis/Unused local uploads (einem dort enthaltenen Link) zu machen wäre. Vielleicht kann mir jemand dabei helfen und eine Arbeitsanleitung schreiben.

Als Tipp für die weitere Untersuchung: Hänge an die URL ?uselang=qqx (als ersten Parameter) bzw. &uselang=qqx (als weiteren Parameter) an und lade eine Seite neu. Dann werden alle möglichen internen Angaben angezeigt. Beispielsweise versteckt sich links in der (toolbox) unter (upload) die Angabe (tooltip-t-upload)(word-separator)(brackets: (accesskey-t-upload))(word-separator)(brackets). Vor allem der accesskey ist in diesem Zusammenhang von Bedeutung; aber auch in anderen Fällen könnte nach solchen Informationen gesucht werden.

Danke für die Unterstützung! -- Jürgen 14:48, 2. Mär. 2015 (CET)

Ich denke, wir müssen auf MediaWiki:Sidebar die Zeile

** c:Special:UploadWizard?uselang=de | Datei hochladen

hinzufügen (siehe zum Beispiel w:sv:MediaWiki:Sidebar, siehe auch mw:Manual:Interface/Sidebar). Ich hoffe, dass danach auch der Reiter "Datei hochladen" in "Werkzeuge" verschwindet. In der Hilfeseite zum Hochladen von Bildern, sollte dann auf Spezial:Hochladen verwiesen werden. Stephan Kulla 17:01, 2. Mär. 2015 (CET)

Ich habe den Eindruck, dass es komplizierter wird. Der UploadWizard gehört meiner Ansicht nach eindeutig zu den Werkzeugen (Toolbox). Aber die Toolbox kann nicht so einfach geändert werden, siehe mw:Manual:Interface/Sidebar#Add or remove toolbox sections (JavaScript). Aber ob dazu Common.js (oder eine globale Variante) zuständig ist oder ob man lokal für jeden skin eine eigene Anpassung schreiben muss, dazu finde ich noch keine gut verständlichen Tipps (abgesehen von meinen so gut wie nicht vorhandenen JS-Kenntnissen). Es läuft wohl wirklich darauf hinaus:

  • Zur Toolbox gehört das "Datei hochladen", das sollte zum Verfahren auf Commons führen.
  • Zur Änderung der Toolbox benötige ich eine eindeutige Schritt-für-Schritt-Anleitung mit Code, den ich per Copy&Paste an die passende Stelle setzen kann. (Andernfalls kann ich die Anpassungen nicht vornehmen.)
  • Die lokale Variante wird (nur) über eine Hilfe-Seite zur Verfügung gestellt.

Übrigens müssen auch die Seiten Hilfe:Bilder gravierend überarbeitet werden und ebenfalls Commons als Standard vorsehen. -- Jürgen 19:27, 4. Mär. 2015 (CET)

Ich verstehe es so: Die Toolbox wird automatisch durch MediaWiki erzeugt und kann durch MediaWiki:Sidebar nicht angepasst werden. Wir müssten hierzu MediaWiki durch eine Extension oder extra Skin ändern, was sicherlich nicht sinnvoll ist. Wir könnten irgendwo fragen, ob die Administratoren unserer Server hier eine spezielle Anpassung vornehmen können.

Die einfachste Lösung ist es aber, den Dateiupload-Link über ein JavaScript-Befehl zu entfernen. Hierzu müssten wir in MediaWiki:Common.js einfach folgendes einfügen:

$("#t-upload").remove();

Dadurch wird der Link entfernt. Ergebnis, nachdem man zusätzlich ** c:Special:UploadWizard?uselang=de | Datei hochladen in der Sitebar eingetragen hat:

  1. 99% der Benutzer sehen danach nur den Link auf Commons (weil sie JavaScript aktiviert haben, siehe auch http://stackoverflow.com/questions/9478737/browser-statistics-on-javascript-disabled für Referenzen zur Prozentzahl von 99%)
  2. 1% der Benutzer sehen den Link auf Commons in der Hauptnavigation + den Link auf Special:Upload in der Toolbox (weil sie kein JavaScript unterstützen).

Ich denke, wir sollten obigen Weg gehen. Das doppelte Auftauchen der beiden Links für 1% unserer angemeldeten Besucher ist eine Sache, die vernachlässigt werden kann. Viele Grüße, Stephan Kulla 20:39, 4. Mär. 2015 (CET)

1. Schritt erledigt: Link eingefügt. (Damit die oberste Rubrik nicht zu groß wird, habe ich die Admins und die Logbücher nach "Mitmachen" verschoben. Wenn das nicht gefällt, bitte ich um Alternativvorschläge.) Außerdem habe ich Hilfe:Menüpunkte angepasst. -- Jürgen 10:27, 5. Mär. 2015 (CET)

2. Schritt erledigt: Direkten Link zu Spezial:Hochladen durch MediaWiki:Common.js entfernt. (Ob das funktioniert, kann ich noch nicht sehen; ich habe wiederholt mehrere Versuche benötigt, bis der Cache aktualisiert wurde.) -- Jürgen 10:27, 5. Mär. 2015 (CET)

Nachtrag: In der Regel funktioniert es. -- Jürgen 16:47, 14. Mär. 2015 (CET)


Qsicon inArbeit.png
todo
Alle Seiten von Hilfe:Bilder müssen überarbeitet werden. Vor allem muss klar werden, dass das Hochladen auf Commons (mit geeignetem Dateinamen sowie Lizenz und Kategorien) der Standard ist. Das Hochladen auf Wikibooks ist nur in Ausnahmefällen (bei manchen Lizenzproblemen) vorgesehen. -- Jürgen 10:27, 5. Mär. 2015 (CET)


Ich denke darüber nach, diese Änderungen (Schritte 1 + 2) wieder rückgängig zu machen. Niemand (auch der Initiator dieses Wunsches) hat sich innerhalb der letzten sechs Wochen mit den Hilfe-Seiten beschäftigt. Damit die Hilfe und die Verfahren übereinstimmen, muss das Verfahren wieder auf den vorherigen Stand zurückgesetzt werden. -- Jürgen 08:24, 13. Apr. 2015 (CEST)

@Jürgen: Bitte mache diese Änderung nicht rückgängig. Ich werde die Hilfeseiten überarbeiten. Dabei werde ich die Inhalte auch gleich zusammenfassen und aktualisieren. Dies wird das nächste sein, was ich außerhalb von Mathe für Nicht-Freaks machen werde (neben der Beteiligung an aktuellen Diskussionen und der normalen Wartungsarbeiten). Viele Grüße Stephan Kulla 22:28, 14. Apr. 2015 (CEST)

Überarbeitung von Hilfe:Bilder[Bearbeiten]

Ich habe angefangen, die Seite Hilfe:Bilder und ihre Unterseiten zu überarbeiten. Alte Diskussionsseiten habe ich zur Löschung vorgeschlagen (@Admins: Am besten macht einen Löschantrag aus der SLA, wenn ihr gegen die Löschung widerspricht. Wenn ihr vor der Löschung ein Archivierung der Seite wünscht, dann meldet euch bei mir).

Dabei habe ich auch begonnen, auf die Hilfeseiten von Commons zu verweisen. Diese sind um einiges aktueller und ausführlicher als unsere. Entsprechende Hilfeseiten auf Wikibooks können dann (nach einer entsprechenden Zeit) gelöscht werden. Grund: Nachdem wir auf externe Hilfeseiten verweisen, müssen wir diese nicht mehr aktuell halten und ersparen uns damit sehr viel Wartarbeit. Wenn es in den nächsten 14 Tagen kein Widerspruch gegen diese Vorgehensweise gibt, werde ich damit fortfahren. Viele Grüße, Stephan Kulla 17:54, 28. Jun. 2015 (CEST)

Die Überarbeitung von Hilfe:Bilder habe ich nun abgeschlossen. Stephan Kulla 21:27, 22. Aug. 2015 (CEST)
Locked.svg

Erledigt! Die Diskussion ist zu einem (vorläufigen) Ende gekommen, und es gibt derzeit keinen weiteren Diskussionsbedarf.

Vorlage:TOC, Vorlage:TOC extern und Vorlage:TOCdetails zusammenfassen[Bearbeiten]

Vorlage:TOC und Vorlage:TOCdetails sind (soweit ich es sehe) identisch. Ich würde gerne alle Einbindungen von Vorlage:TOCdetails durch Einbindungen von Vorlage:TOC ersetzen und danach die Vorlage Vorlage:TOCdetails löschen.

Bei der Gelegenheit würde ich auch Vorlage:TOC extern mit Vorlage:TOC zusammenfassen. Die Einbindung bei Vorlage:TOC extern wäre dann

{{TOC|extern=ja}}

Maßnahme werde ich (wenn es keine Widersprüche gibt) frühestens ab dem 24.11 umsetzen. Stephan Kulla 18:09, 10. Nov. 2014 (CET)

Ich zweifle, ob ich diesen Plan für gut halten soll. Grundsätzlich ist es natürlich sinnvoll, Vorlagen, die sich nur wenig unterscheiden, zusammenzufassen. Insbesondere scheint es keine einzige Seite zu geben, die bei TOCdetails den Parameter suffix verwendet. Andererseits wird "TOC extern" auf etwas über 100 Seiten verwendet.

  • Lohnt sich dieser Aufwand, um eine einzige Vorlage einzusparen?
  • Für eine (neue) Nutzerin, die nach einer Vorlage für eine bestimmte Aufgabe sucht, könnte es hilfreicher sein, wenn es eine spezielle Vorlage gibt (natürlich nur soweit vorhanden) als wenn sie eine nur ähnliche Vorlage findet.
  • Unter Umständen fängt sie dann sogar an, sich eine neue, genau passende Vorlage zu basteln.

Ich will dich nicht an diesen Änderungen hindern. Aber vielleicht solltest du nochmals über das Verhältnis von Aufwand und Ertrag nachdenken. -- Jürgen 20:36, 13. Nov. 2014 (CET)

@Jürgen: Danke für das Feedback. Zum Aufwand: Die Zusammenführung von TOC extern würde ich zum Anlass nehmen, mir ein Tool zur Hilfe bei einer solchen Zusammenführung zu programmieren. Hier ist natürlich noch nicht klar, ob ich es schaffe. Sollte es sich als zu aufwendig erweisen, würde ich die Zusammenführung wegen zu wenig Nutzen nicht umsetzen...

Zum Finden von Vorlagen: Weniger Vorlagen sollten in meinen Augen sogar beim Finden von Vorlagen helfen, da nicht viel durchsucht werden muss. Auch sollte der Wartungsaufwand danach geringer sein. Viele Grüße, Stephan Kulla 19:42, 17. Nov. 2014 (CET)

Hilfe-Seiten zu VisualEditor[Bearbeiten]

Ich habe Wikibooks:VisualEditor (VE) mit etwas Inhalt versehen: Es sollte wenigstens eine Einleitung geben; aktuelle Informationen sollten auf einer speziellen Seite zu diesem Thema gesammelt werden und nicht auf dem Schwarzen Brett "vergammeln". Neben dem Verweis auf w:Hilfe:VisualEditor habe ich noch ein paar Links eingefügt. Dieses Thema muss in die Hilfe-Seiten eingebaut werden.

Ich bitte um Hinweise, wo und wie der VE in der Hilfe berücksichtigt werden sollte. Bei klarer Situation kann eine Hilfe-Seite auch sofort geändert werden; wenn es unterschiedliche Meinungen geben kann, dann bitte ich erst einmal hier um Diskussion. -- Jürgen 12:52, 7. Feb. 2015 (CET)

Ich meine, Wikibooks:VisualEditor sollte ziemlich weit vorne einen Hinweis beinhalten, daß dieser 'Editor' sowohl eine relativ neue Brauser-Version benötigt und daß die Interpretation von java-script aktiviert sein muß, sonst ist das Teil gemäß der Beschreibung von wikipedia wohl nicht brauchbar und nicht relevant. Kann viel Zeit sparen, wenn solche Voraussetzungen gleich im ersten Absatz stehen oder dort referenziert werden ... (da Autoren hier ja selbst keine Dokumente hochladen/erzeugen können, die java-script enthalten, was ich auch für angemessen halte, scheint mir der Hinweis durchaus relevant zu sein, daß dieser 'Editor' offenbar nicht zugänglich und barrierefrei umgesetzt ist - die barrierefreie und zugängliche Variante also wie gehabt der normale Editor ist) Doktorchen 14:31, 7. Feb. 2015 (CET)

Danke für diese Hinweise (angenehm kurz und sogar beim ersten Lesen verständlich). Ich werde die Seite gleich ergänzen. -- Jürgen 10:20, 8. Feb. 2015 (CET)

Hilfe-Seiten zu Wikidata[Bearbeiten]

Ich habe Wikibooks:Wikidata (WD) neu eingerichtet: Es soll jetzt auch für Wikibooks zur Verfügung gestellt werden. Das betrifft in erster Linie die Interwiki-Links; ob WB auch hinsichtlich „richtiger Daten“ davon profitieren kann, muss man sehen. Ich habe erst einmal eine Einleitung geschrieben und die Ankündigung vom Schwarzen Brett übernommen. Dieses Thema muss in die Hilfe-Seiten eingebaut werden.

Ich bitte um Hinweise, wo und wie WD in der Hilfe berücksichtigt werden sollte. Bei klarer Situation kann eine Hilfe-Seite auch sofort geändert werden; wenn es unterschiedliche Meinungen geben kann, dann bitte ich erst einmal hier um Diskussion. -- Jürgen 12:52, 7. Feb. 2015 (CET)

Die Meta-Unterseite für Vorlagen[Bearbeiten]

Bei der allgemeinen Diskussion über Vorlagen gibt es die Anregung, auf die Meta-Unterseite zu verzichten. Auf der verlinkten Seite gibt es bereits eine Reihe von Argumenten. Bitte kommentiert dies deshalb dort. -- Jürgen 08:02, 2. Mär. 2015 (CET)

Erledigt: Künftig kann/soll auf die Meta-Unterseite verzichtet werden. Hilfe-Seiten und Vorlage wurden entsprechend geändert. -- Jürgen 14:59, 27. Apr. 2015 (CEST)

Schwesterprojekte in der Sidebar verlinken[Bearbeiten]

Es kommt immer mal wieder vor, dass ich aus Wikibooks heraus zu einem Schwesterprojekt wechseln möchte, ohne dass ein direkter Link vorhanden ist. Das bedeutet: Wechseln zur WB-Hauptseite, dort an das Ende der Seite gehen, dann das gewünschte Projekt aufrufen. Diese drei Klicks möchte ich durch einen ersetzen, indem in die Navigation links ein zusätzlicher Abschnitt "Schwesterprojekte" mit den direkten Links auf die Hauptseite eingerichtet wird. Muster siehe en:MediaWiki:Sidebar.

Wenn es keinen Widerspruch oder andere Vorschläge gibt, werde ich das einrichten (frühestens nach dem 21. April 2015), und zwar nach den Links auf andere Sprachen. -- Jürgen 17:15, 21. Mär. 2015 (CET)

Hinweis 1: Bei den Einstellungen gibt es die Beta-Funktion "Seitenleiste anderer Projekte", die ebenfalls Links auf Schwesterprojekte anzeigt. Dabei handelt es sich aber (sofern aktiviert und angezeigt) immer um Links, die zur aktuellen Seite passen; sie werden über Wikidata verknüpft. Bei den meisten Seiten wird es keine derartigen Links geben, sodass sich diese Funktion mit meinem Vorschlag nicht "beißt". Ich muss nur darauf achten, dass es keine Verwechslung gibt, und beabsichtige deshalb, den zusätzlichen Abschnitt Projekt-Hauptseiten zu benennen. -- Jürgen 14:52, 17. Apr. 2015 (CEST)

Hinweis 2: Unter Umständen ist die Liste der Sprachen sehr lang, sodass der neue Link erst weit unten erscheint. Das lässt sich mit den Einstellungen über die Beta-Funktion "Kompakte Sprachlinks" beeinflussen. -- Jürgen 14:52, 17. Apr. 2015 (CEST)

  • Symbol support vote.svg Pro Ein sehr hilfreiches Feature. Kann mich Deiner Begründung nur anschliessen.--Xeno06 17:21, 21. Mär. 2015 (CET)
  • Symbol support vote.svg Pro -- Stephan Kulla 18:44, 22. Mär. 2015 (CET)

Ich werde diesen Vorschlag noch nicht verwirklichen. Das scheint inzwischen ein Standard der MediaWiki-Software zu werden, allerdings bisher nur auf manchen Seiten. Aufgefallen ist es mir bei Spezial:Letzte Änderungen und Vorlage:Dokumentation. Es ist deshalb zunächst zu prüfen:

  • Welche Regel gibt es dafür? Die Existenz eines Wikidata-Objekts oder was sonst?
  • Auf welchen Seiten oder Namensräumen steht es bereits?
  • Planen die Programmierer, weitere Bereiche einzubeziehen?
  • Auf welche Weise wird der Abschnitt wikibase-otherprojects eingebunden? Wie kann unterschieden werden, ob er schon per Software vorhanden ist oder per JavaScript anzuzeigen ist?

Mal sehen, wie es weitergeht. -- Jürgen 12:54, 27. Apr. 2015 (CEST)

Überarbeitung der Sidebar[Bearbeiten]

In den beiden Threads Rundschau, Schwarzes Brett, Portal wurden bereits Verbesserungen der Sidebar vorgeschlagen. Ich habe auch hier auch einige Verbesserungsvorschläge. Es folgt die aktuelle Navigationsleiste. Bitte notiert hier, was ihr gerne ändern wollt. Allgemeine Diskussionen können weiter unten geführt werden.

Vorschläge zur Veränderung der Sidebar

Bitte haltet hier eure Vorschläge kurz. -- Stephan Kulla 19:07, 22. Mär. 2015 (CET)

  • Hauptseite
  • Aktuelles
  • Buchkatalog
  • Alle Bücher
  • Bücherregale
    • vor "Alle Bücher" einsortieren
  • Zufälliges Kapitel
  • Dateihochladen
    • verschieben in die Rubrik "Mitmachen" -- Stephan Kulla 19:07, 22. Mär. 2015 (CET) nur für Autoren wichtig
  • Rubrik "Mitmachen"
    • Wikibooks-Portal ⇒ siehe Rundschau, Schwarzes Brett, Portal
    • Letzte Änderungen
      • Vor dem Punkt "Logbücher" verschieben -- Stephan Kulla 19:07, 22. Mär. 2015 (CET)
    • Hilfe
      • sollte der zweite Punkt bei "Mitmachen" sein -- Stephan Kulla 19:07, 22. Mär. 2015 (CET)
    • Verbesserungen
    • Administratoren
    • Logbücher
    • Spenden
      • verschieben nach dem Punkt "Zufälliges Buch" -- Stephan Kulla 19:07, 22. Mär. 2015 (CET) Dieser Punkt richtet sich an Leser und nicht an Autoren
  • Rubrik "Werkzeuge" ⇒ kann nicht geändert werden

Diskussion

  • Bitte aufpassen, dass nicht wieder (wie im Vorjahr) zu viele Punkte gleichzeitig und durcheinander behandelt werden. Bisher gilt das noch nicht, aber durch den Zusammenhang mit der obigen Diskussion über Rundschau / Schwarzes Brett / Portal besteht die Gefahr. (Schlimmstenfalls werde ich die Notbremse ziehen und meine Vorschläge zum Portal für ungültig erklären.) -- Jürgen 15:14, 23. Mär. 2015 (CET)
    • @Jürgen: Bitte gebe mir Bescheid, wenn dir die Anzahl der aktuellen Vorschläge zuviel sein sollte. Lieber ziehe ich einen Vorschlag für eine Weile zurück, als dass du deine Vorschläge zum Portal für ungültig erklärst, da sie notwendig sind und zu einer verbesserten Übersicht führen und gleichzeitig unsere Strukturen vereinfachen. Viele Grüße, Stephan Kulla 01:45, 24. Mär. 2015 (CET)
Das war ein vorsorglicher Hinweis. Schließlich haben meine obigen Vorschläge auch Auswirkungen auf die Sidebar. Außerdem müssen nach allen derartigen Änderungen die Hilfe-Seiten überarbeitet werden, und das geschieht nach den Erfahrungen überaus zögerlich oder gar nicht. Wenn aber Funktionalität und Hilfe nicht zusammenpassen, schreckt das potenzielle Autoren auch ab. -- Jürgen 08:40, 26. Mär. 2015 (CET)
@Jürgen: Wir haben eine Hilfe für die Sidebar?! Du meinst Hilfe:Menüpunkte, oder? Mir scheint diese Hilfe unnötig. Entweder ist das Menü intuitiv verständlich oder es muss überarbeitet werden. Aus meiner Sicht sollte es nicht notwendig sein, dass es eine Hilfe für das Menü gibt. Stephan Kulla 01:38, 27. Mär. 2015 (CET)
Richtig, zunächst meinte ich Hilfe:Menüpunkte. Aber es geht auch umgekehrt darum, dass in Hilfe:Bilder usw. auf die richtigen Links in der Sidebar verwiesen wird oder dass richtig zwischen den Mitmachen-Funktionen in der Sidebar und dem (ggf. geänderten) Portal gewechselt werden kann. All diese "Wechselwirkungen" sind zu bedenken – jedenfalls bei der Umsetzung. -- Jürgen 08:07, 27. Mär. 2015 (CET)
  • Ich habe mich entschlossen, sämtliche eigenen Stellungnahmen zurückzuziehen. In der derzeitigen Situation bei Wikibooks möchte ich mich mit den Namensräumen Wikibooks und Hilfe nur noch bei Kleinigkeiten beschäftigen. Primäres Ziel muss die Bearbeitung von (guten) Büchern sein. Alles andere, was mehrere Punkte (oder Seiten) betrifft und bei dem die Umsetzung zusätzliche Arbeit erfordert, hält von der eigentlichen Arbeit ab. Ich möchte (wieder) die richtigen Prioritäten setzen. -- Jürgen 15:27, 14. Apr. 2015 (CEST)
  • Finde ich auch. Beispielsweise halte ich Löschdiskussionen zu Hilfeseiten für Zeitverschwendung. -- Klaus 21:26, 28. Apr. 2015 (CEST)

Erweiterte Löschregel für Löschankündigungen[Bearbeiten]

Dank Jürgen werden aktuelle Löschankündigungen gut abgearbeitet. Da Jürgen aktuell der einzige Admin ist, der die Löschankündigungen bearbeitet, bleiben seine Löschankündigungen unbearbeitet. Deswegen schlage ich folgende Ergänzung vor

„Ein Admin kann bei Löschankündigungen, die einen Monat alt sind, direkt eine Entscheidung treffen und durchführen (selbst wenn die Löschankündigung von ihm stammt).“

Ein Monat sollte ausreichend sein, damit die AutorInnen der betreffenden Seite oder auch andere BenutzerInnen Widerspruch äußern können. Viele Grüße, Stephan Kulla 21:42, 7. Apr. 2015 (CEST)

Abstimmung

  • Symbol support vote.svg Pro -- Stephan Kulla 21:42, 7. Apr. 2015 (CEST)
  • Symbol oppose vote.svg Contra -- Jürgen 08:43, 8. Apr. 2015 (CEST)
  • Symbol oppose vote.svg Contra -- Klaus 21:22, 28. Apr. 2015 (CEST)

Diskussion

  • Löschankündigungen sind relativ unproblematische Fälle, bei denen eine Löschdiskussion durch das 4-Augen-Prinzip ersetzt wurde. Es hat aber eine ganz andere Qualität, wenn auf das zweite Paar Augen verzichtet würde. Es hat schließlich seinen Grund, wenn ein Admin eine solche Seite nicht per Schnelllöschung entfernt. In den konkreten Fällen gehe ich eher davon aus, dass ich diese Löschankündigungen nach sechs Monaten als "abgelehnt" mangels Bestätigung erklären werde. -- Jürgen

Buch in Kapitel untergliedern[Bearbeiten]

Aus aktuellem Anlass schlage ich vor, dass ein Buch oder ein Kapitel eine bestimmte Größe (Zeichenzahl) in der Regel nicht überschreiten soll. Mein Vorschlag lautet dafür 50.000 Zeichen. Gleichzeitig möchte ich Hilfe:Buch in Kapitel untergliedern eindeutiger formulieren. Die entsprechenden Vorschläge stehen auf der Diskussionsseite. Ich bitte dort um Kommentare. -- Danke! Jürgen 17:03, 11. Apr. 2015 (CEST)

Editor überarbeiten[Bearbeiten]

Ich habe vor den Editor etwas zu überarbeiten, Diskussionen dazu sollen unter dieser Überschrift geführt werden. Ausgangspunkt dazu war das Hinzufügen des Unicode Zeichens  , welches ein Leerzeichen mit der Breite einer Ziffer erzeugt. Jürgen hat bereits auf meiner Diskussion ein paar Anmerkungen hinterlassen, die ich hier auch gleich einfüge um alles beieinander zu haben:

Zu MediaWiki:Edittools habe ich noch ein paar Anmerkungen:

  • Seit ein paar Wochen kann ich die Liste der Sonderzeichen nicht mehr ausklappen, siehe Wikipedia und meine Diskussionsseite.
  • Direkt in die Liste kann wohl kein Tooltip eingebaut werden. (Ich habe nicht danach gesucht, aber da es sich um eine „normale“ Systemnachricht handelt, kann ich es mir nicht vorstellen.)
  • Wikipedia hat inzwischen eine völlig andere Lösung (mit Tooltips) über Onlyifediting.js, die mir gefällt. Aber dazu müssten wir unser System komplett überarbeiten; ob sich das bei unserer sehr aktiven Gemeinschaft lohnt?

Gruß Jürgen 14:39, 13. Aug. 2015 (CEST)

Beim Durchschauen unserer Gadgat-Infrastruktur ist mir aufgefallen, dass das alles nicht mehr auf dem aktuellen Stand ist, seit der ResourceLoader eingeführt wurde. Ich schau erst mal ob ich das beheben kann, dann geht es an den Editor.

Ich würde vorschlagen MediaWiki:Edittools komplett zu entfernen und in die Erweiterte Bearbeiten-Werkzeugleiste zu integrieren. Außer in sehr alten Browsern wird diese inzwischen überall unterstützt und ehrlich gesagt schweren mich Uralt-Browser wie Firefox 1 oder IE 6 nicht mehr. Wer so was noch benutzt, sollte ich ohnehin überlegen, was er im Internet zu suchen hat, allein schon aus Gesichtspunkten der Sicherheit. --Prog 19:59, 15. Aug. 2015 (CEST)

Alte Gadgets löschen[Bearbeiten]

Ich habe eben mal alle unsere Gadgets so verändert, dass sie mit dem ResourceLoader funktionieren und noch 2 neue hinzugefügt. Die beiden unter "Reiter/Tabs" funktionieren nicht mehr, wahrscheinlich waren die auf Monobook gemünzt, den Vector-Skin zerschießen sie jedenfalls. Ich plädiere dafür sie zu löschen, oder hat das noch jemand in Verwendung? In dem Fall bitte ich um Rückmeldung ob sie mit Monobook funktionieren und würde einen entsprechenden Hinweis in die Beschreibung aufnehmen. --Prog 22:20, 15. Aug. 2015 (CEST)

Bin auch dafür, die alten Gadgets zu löschen. Stephan Kulla 23:31, 17. Aug. 2015 (CEST)

Missbrauchsfilter gegen falsches HTML und veraltete Vorlagen[Bearbeiten]

Ich schlage vor, einen Missbrauchsfilter hinzuzufügen, der bei veralteten HTML-Tags und Vorlagen aktiv wird. -- David23x 22:00, 29. Aug. 2015 (CEST)

Support! Der Missbrauchsfilter sollte so gestaltet werden, dass er nur neu geschriebene Texte filtert. -- Stephan Kulla 22:18, 29. Aug. 2015 (CEST)

Schon klar, aber damit könnte man zumindest das Anlegen neuer Artikel mit veralteten Vorlagen oder Tags verhindern. Der Zweck der Missbrauchsfilter ist es doch, unerwünschtes Verhalten zu unterbinden. Es gibt zum Beispiel einen, der das Benutzen von dem Source-Tags verhindert, weil man stattdessen die Source-Vorlage benutzen soll. Und was meintest du eigentlich mit „Support!“? -- David23x 13:23, 30. Aug. 2015 (CEST)

Dass ich deinen Vorschlag unterstütze... :) Stephan Kulla 13:53, 30. Aug. 2015 (CEST)

Ich Trottel. -- David23x 20:06, 30. Aug. 2015 (CEST)

Mißbrauch ist da ja eigentlich die falsche Wortwahl. So oder so sollte man Autoren natürlich mit solch einer Fehlermeldung nicht alleine lassen, sondern eine genaue Anleitung geben, wie man es besser macht. Bei dem genannten Beispiel zu source ist bislang etwa immer noch nicht klar, was daran falsch oder veraltet sein soll, wird glaube ich auch nur noch hier behauptet. Das Problem bei alten Seiten kommt bei der Bearbeitung oder Ergänzung des Inhaltes auf. Nimmt man etwa das Beispiel mit source, so ist es naheliegend, daß wenn es solche Strukturen im bisherigen Inhalt schon gibt, daß ein Autor das dann auch bei Ergänzungen einfach weiter verwenden will. Da staunt man dann natürlich, wenn solch eine Meldung aufkommt, die behauptet, das Ergänzte sei veraltet, dieselbe alte Struktur von früheren Autoren aber in Ordnung. Das kommt dann auch einer Zumutung für Autoren gleich, auch den alten Kram zu überarbeiten, um das einheitlich hinzubekommen. Von daher könnte es also sinnvoll sein, solch einen Filter, solche eine Warnung nur auszugeben, wenn der bereits vorhandene Inhalt nicht bereits dieselben Strukturen enthält.
Ferner sollte man natürlich genau klären, was man wirklich für veraltet hält oder für eine Warnung wert - wenn ich das richtig in Erinnerung habe, haben die hiesigen Programme irgendwann auch schon einmal die (X)HTML-Versionsangabe hinterrücks geändert (nicht nur für neu angelegte Projekte, sondern für alle), man kann da also wohl ohnehin nicht viel mehr als Markierungssuppe erwarten, weil es ohnehin nicht in der Kontrolle der Autoren liegt, was dieses Programm letztlich aus ihren Eingaben macht - eventuell auch erst Jahre später durch den spontanen Einfall eines Programmierers.
Hinweis, Warnung kann für Autoren also sinnvoll sein, wenn sie sinnvoll gemacht ist, was aber nicht notwendig einfach sein muß. Doktorchen 12:43, 31. Aug. 2015 (CEST)

Zum 27. Mal: Der Hinweis zu <source ist entstanden aus folgendem Hinweis (zwischenzeitlich gab es noch einen klareren Grund):

In older versions (before MediaWiki 1.16), the extension used the tag <source>. This is still supported, but <syntaxhighlight> may help avoid conflicts if your source code itself contains <source> tags (for example XML). – MediaWiki logo without tagline.svg Extension:SyntaxHighlight_GeSHi

Es handelt sich um eine Warnung, die nur aktiv wird, wenn "source" im bisherigen Text nicht enthalten war, siehe Spezial:Missbrauchsfilter/26. Die Alternativen "syntaxhighlight" und Vorlage:Syntax werden vorgeschlagen. Und weil es eine Warnung ist, wird niemand gehindert, einen Text mit <source> zu speichern.

Die Startseite für die "Missbrauchsfilter" heißt seit langem Eingabeprüfungen und Missbrauchsfilter und erklärt beide Begriffe. Bitte wenigstens einmal nachlesen!!! Wer meine Versuche, falsche Bearbeitungen zu verhindern, für unangemessen hält, sollte das deutlich machen; ich kann auch darauf verzichten und alles deaktivieren.

Zum eigentlichen Wunsch: Der muss nach Lage der Dinge sehr konkret werden: Welche Tags und welche Vorlagen sollen vermieden werden, unter welchen Bedingungen, mit welchen Alternativen? -- Jürgen 11:03, 3. Sep. 2015 (CEST)

@Doktorchen: Stell dir vor, du möchtest folgendes in <source>-tag packen:

<collection>
  <source>...</source>
  <source>...</source>
</collection>

Mit <source> funktioniert es nicht. Deswegen fand wohl in die Umbenennung in <syntaxhighlight> statt. @Jürgen: Danke an dieser Stelle für die Arbeit an den Missbrauchsfiltern, die genrell die Wartungsarbeit minimiert. -- Stephan Kulla 13:22, 3. Sep. 2015 (CEST)

Analoges gilt ja für
<collection>
<syntaxhighlight>...</syntaxhighlight>
<syntaxhighlight>...</syntaxhighlight>
</collection>
Aber auch das löst natürlich nicht das Problem, daß man bei XML vielleicht auch beide Elementnamen verwenden möchte, etwa wenn man etwas über die Syntax dieses Wiki-Systems schreiben will. Das zeigt allenfalls, daß insgesamt solche Konstruktionen mit Markierungen bei der Syntax problematisch ist, man hat das Problem also nicht wirklich gelöst.
Jedenfalls entnehme ich obigem Zitat nicht, daß man etwas nicht mehr verwenden soll, weil es veraltet ist, eher daß das Neue bei alten Wikis (die hier nicht verwendet werden) nicht funktionieren würde ;o) Es ist allenfalls ein Hinweis, daß man die neue Struktur verwenden kann, wenn man mit der alten Probleme bekommt. HTML5 hat allerdings ein neues Element source, da könnte es dann häufiger Probleme geben, wenn man darüber ein Buch schreiben will. Ansonsten kommt das Element dort nur innerhalb bestimmter Elemente vor, hinsichtlich der hiesigen Markierungssuppe gibt es da wohl keine echten Konflikte.
Ich habe eben auch noch entdeckt, daß Mißbrauchfilter Regel 26 zu einem weiteren lustigen Konflikt führt, erst bekommt man dafür eine Warnung, dann falls man die Zusammenfassung nicht geändert hat, dann wieder für Regel 26, man kann wohl nur speichern, wenn man etwa die Zusammenfassung ändert, sonst kann man den Teufelskreis nicht durchbrechen und kann nichts abspeichern. Doktorchen 18:14, 3. Sep. 2015 (CEST)


@alle: Ich schlage vor, bei folgenden Dingen eine Warnung anzuzeigen:

  • Neuer Text enthält Überschrift 1. Ordnung
  • Neuer Text enthält Tags: <font>, <big>, <center>

Liste kann gerne vervollständigt werden... -- Stephan Kulla 13:22, 3. Sep. 2015 (CEST)

  • strike, xmp, blink, nobr (einige weitere sind in XHTML1.1 veraltet, in HTML5 aber nicht und umgedreht, also nicht eindeutig zu entscheiden), diverse andere eindeutige sind hier vermutlich nicht relevant. Doktorchen 18:14, 3. Sep. 2015 (CEST)


Zum Vorschlag "Überschrift 1. Ordnung": Das ist leider kritisch zu bewerten. Auf manchen Diskussionsseiten ist es sinnvoll (z.B. Trennung zwischen Autorenliste, Archiv und aktuellen Themen), ebenso bei Druckversionen und vergleichbaren Zusammenfassungen wie Computerhardware für Anfänger. Ich begrüße eigentlich diesen Vorschlag, sehe aber große Probleme bei der Umsetzung, sodass z.B. Ausnahmelisten (wie bei Filter 10) es (zu) kompliziert machen könnten, auch wenn "nur" eine Warnung angestrebt wird. -- Jürgen 17:28, 3. Sep. 2015 (CEST)

Ich würde vorschlagen, alle in HTML5 veralteten Tags, die hier verwendbar sind, aufzunehmen:

  • acronym
  • applet
  • basefont
  • big
  • center
  • dir
  • fpnt
  • frame
  • frameset
  • noframes
  • s
  • strike
  • tt
  • u
  • xmp

(Quelle: http://blog.mixable.de/nicht-mehr-unterstutze-bzw-veraltete-tags-in-html5/)
und außerdem welche, die nie im HTML-Standard waren, aber haüfig genutzt werden:

  • marquee
  • nobr

(Quelle: http://wiki.selfhtml.org/wiki/HTML/deprecated#inoffizielle_Elemente).

Außerdem die veralteten Attribute:

  • align (außer bei col, colgroup, tbody, td, tfoot, th, thead und tr)
  • alink
  • autosave
  • bacground
  • bgcolor
  • border (außer bei table)
  • clear
  • compact
  • height (außer bei iframe, img und object)
  • hspace
  • language
  • link
  • name
  • noshade
  • nowrap
  • size (außer bei input und select)
  • start
  • text
  • type (außer bei a, object, param, input, button, script und style)
  • value (außer bei input, option, param und button)
  • version
  • vlink
  • vspace
  • width (außer bei ifram, img, object, table, col und colgroup)

(Quelle: http://wiki.selfhtml.org/wiki/HTML/deprecated#missbilligte_Elemente), (Bis auf name waren alles in HTML 4 missbilligte, aber ich gehe davon aus, dass sie alle inzwischen obsolete geworden sind. Einge dieser Tags werden aus Sicherheitsgründen eh nicht zu HTML-Tags, aber ich weiß nicht genau welche, daher habe ich einfach alle aufgelistet.

Das Problem an einer solchen Liste ist, dass es lange dauert, bis der Server sie durchgegange ist.

Zumindest tt würde ich noch mit aufnehmen.

Es dürfen natürlich keine Tags erkannt werden, die in <nowiki>s, oder <pre>s stehen. Eine so lange Liste hat natürlich den Nachteil, dass es lange dauert, bis sie durchgegangen ist und dass es mehr Arbeit ist, sie einzubauen. -- David23x 18:04, 3. Sep. 2015 (CEST)

Wie Doktorchen sagte: Wer eine Änderung an einem Text vornehmen will, darf nicht gezwungen werden, den gesamten alten Kram zu überarbeiten, um das einheitlich hinzubekommen. Und eine Filtermitteilung wegen "altem HTML" sollte einen Hinweis enthalten, wie das Konstrukt im "neuen HTML5" aussieht. In diesem Zusammenhang sehe ich es als nicht hilfreich, wenn veraltete Konstruktionen aus Hilfeseiten entfernt werden, statt sie durch HTML5-konforme Konstrukte zu ersetzen. -- Klaus 12:07, 4. Sep. 2015 (CEST)
Man sollte dazu anmerken, daß HTML5 nicht die einzige aktuelle Variante von (X)HTML ist, daneben gibt es auch noch XHTML+RDFa, für welches die Empfehlung ähnlich aktuell ist. Das basiert weitgehend auf Modulen von XHTML1.1 und der RDFa-Erweiterung (die es ähnlich auch für HTML5 gibt) - da die beiden Empfehlungen sich nicht einig sind, was als veraltet gilt und HTML5 auch diverse unnötige Elemente reanimiert hat, die in XHTML 1.1 schon entsorgt wurden, kann man nicht davon sprechen, daß all die genannten Elemente veraltet sind, erst recht nicht jene, die nur in HTML5 als veraltet gekennzeichnet sind, das ist eine mehr oder weniger willkürliche Auswahl nach dem persönlichen Geschmack von Ian Hickson, dem ursprünglichen Editor der HTML5-Arbeitsentwürfe. Insbesondere aufgrund der Willkür der Auswahl in HTML5 und der dortigen Umdefinitionen von Bedeutungen kann sich die Auswahl natürlich mit jeder weiteren Version von HTML wieder ändern, eben weil es da kein durchgehend logisches Konzept gibt, warum man etwas tut oder eben auch nicht. Mal abgesehen von recht eindeutigen Fällen wie font sollte man das entspannt sehen. Selbst hinsichtlich center gab es da in der HTML-mailing-Liste schon Diskussionen, ob man dem nicht eine inhaltliche Bedeutung zuschreiben kann und deshalb nicht mehr als veraltet ansehen sollte. Gibt es überhaupt eine Übersicht, was man hier sinnvoll verwenden kann?
Könnte man etwa object, iframe, audio oder video verwenden, um externe Inhalte einzubinden? Wie naheliegend ist es, daß Autoren, die hier tätig sind, wirklich in den Untiefen von HTML nach alten Elementen suchen, statt vorrangig die hiesige Syntax zu verwenden, die deren Erfinder ja für irgendwie einfacher halten als (X)HTML? Einige der obigen Vorschläge sind schon deshalb skurril, weil man sie hier sicher gar nicht korrekt und sinnvoll einsetzen könnte, etwa frame; Elemente wie s und u sind in HTML5 zudem gar nicht veraltet, sondern lediglich in XHTML1.1. Das Attribut version etwa wird man hier rein technisch gar nicht selbst als Autor verwenden können. Man sollte sich also schon mit (X)HTML auskennen, wenn man solche Listen erstellt ;o)
Der HTML5-Kram findet sich hier: http://www.w3.org/TR/html5/ Obsoleter Kram ist hier verzeichnet: http://www.w3.org/TR/html5/obsolete.html#obsolete (immerhin schreiben die da sogar konkret, was man stattdessen verwenden soll, was lobenswert ist). Veraltete Elemente mit noch gewissem Nutzwert von XHTML1.1 sind in einem speziellen Modul zusammengefaßt, welches bei Version 1.1 nicht eingebunden wird: http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_legacymodule
Doktorchen 13:22, 4. Sep. 2015 (CEST)

@Doktorchen: Mir war klar, dass einige Tags nicht wirklich sinnvoll verwendet werden können nd einige aus Sicherheitsgründen gar nicht nterpretiert werden können. natürlich ist auch Frame unter den aus Sicherheitsgründen blockierten Elementen. da ich mir abe nicht ganz sicher sein konnte, was dazu gehört und was nicht, habe ich einfach alle aufgelistet. Ob HTML5 das neueste ist, ist nicht so wichtig, entscheidend ist, dass Wikibooks es benutzt, wie ein Blick in den Quelltext verrät. Ansonsten sind deine Einwände aber berechtigt. Mir erscheint es auch sehr seltsam, dass es zum Beispiel <b> in den HTML5-Standard geschafft hat. Schön wäre es natürliche, wenn der Bearbeitungsfilter auch noch anzeigen könnte, welche Alternativen es gibt, sodass man sich nicht so sehr mit der Thematik befassen muss, ich bin mir abe ziemlich sicher, dass das sehr schwer umzusetzen wäre.

Du hast natürlich auch bei deinem älteren Einwand Recht, dass eine Warnung am besten nur dann angezeigt werden sollte, wenn noch kein ähnlicher Fehler im Dokument war. -- David23x 14:00, 4. Sep. 2015 (CEST)

Formal ist nicht erkennbar, was hier verwendet wird, weil keine Versionskennung angegeben ist, das war vor ein paar Jahren noch anders, aber man hat die Versionskennung hier irgendwann einfach so entfernt. HTML5 hat selbst gar keine eigene Versionskennung, daher kann man auch schlecht feststellen, ob es verwendet wird, die Interpretation von HTML5 ist im Grunde auf jegliche Textdateien anwendbar, unabhängig davon, ob das sinnvoll ist oder nicht. Aufgrund solcher Absurditäten ist HTML5 eben eine Empfehlung zur Interpretation von Markierungssuppe - einschließlich veralteter Elemente. Wenn es bei der Version ein Konzept gibt, dann das, irgendwie zu interpretieren, was Autoren so veröffentlichen, von daher ist im Grunde nichts veraltet oder unsinnig oder falsch für HTML5. Die Empfehlung ist sozusagen für Autoren immer 'in den Wind gesprochen', wenn viele Autoren etwas anderes veröffentlichen, als in der Empfehlung steht, im Zweifelsfalle wird einfach die Empfehlung/Implementierung angepaßt. Man kann sich drauf verlassen, daß wenn viele Leute wieder font verwenden würden, würde es in HTML5.1 oder 5.2 wieder als nicht veraltetes Element auftauchen. Wie sich bei den jahrelangen Diskussionen in den entsprechenden mailing-Listen des W3C immer wieder herausgestellt hat, ist es vergeudete Zeit, bei HTML5.x ein inhaltliche sinnvolles Konzept, eine saubere Sprache umzusetzen, das ist letztlich eine ähnliche Situation wie bei Version 3.2, das Jahrzehnt ist hinsichtlich Qualität einfach verloren, vielleicht gleich die Zukunft des ganzen Formates... Doktorchen 20:34, 4. Sep. 2015 (CEST)

Wieso ist es formal nicht erkennbar? Es gibt genau eine HTML-Version, die keine Versionsnummer verlangt, und die muss es sein. AB HTML5 hört die Nummerierung der HTML-Versionen übrigens auf, daher gibt es kein HTMl5.1 oder HTML5.2. Daher hat man sich wohl auch entschieden, die Versionsnummer aus dem HTML5-Doctype zu entfernen. -- David23x 16:16, 5. Sep. 2015 (CEST)