Wikipedia Diskussion:Meinungsbilder/Vereinheitlichung der Infoboxen

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

Wieso eigentlich "zusammenlegen, wenn es wünschenswert wäre"?[Quelltext bearbeiten]

welche argumente gibt es dafür, alles in eine box zu stopfen, bzw, welche argumente gibt es dagegen, mehrere boxen (so wie mehrere kategorien oder navileisten) in einen artikel zu setzen, wenn das thema über mehrere aspekte beschrieben werden kann? --W!B: 06:47, 8. Dez. 2008 (CET)Beantworten

  • Pro "all-in-one":
  • Contra "all-in-one":
    • überfrachtete einheiten haben sich im computerwesen nicht bewährt: schlanke programmierung und modularer aufbau ist langfristig stabiler
  • Pro "mehrere boxen:"
    • wartungsfreundlicher durch schlanken code der box
    • lesefreundlicher, weil die daten beim kapitel des diesbezüglichen inhalts stehen
  • Contra "mehrere boxen:"

Beispiele für mehrfachbestückung:

  • Atlantische Hurrikansaison 2008 - IB der Saison zum artikel, IBs der einzelereignisse je kapitel
  • Langbathseen: zwei seen in einem artikel - weil es keine möglichkeit gibt, poskarte und zweites bild wegzudrücken (trotz KEINGEOARTIKEL=1), sehr unschön - besser Ödseen (aber nur unter dem kompromiss, werte leerzulassen), ganz böse trotz kurzbox: Gosauseen
  • Ikarus (Software): eine firma und ihr programm in einem artikel


in der Infobox See lässt sich mittels POSKARTE=none die Postitionskarte wegdrücken, auch in Langbathseen. --Herzi Pinki 02:02, 9. Dez. 2008 (CET)Beantworten
danke Dir, stimmt, das hilft - es gibt also schon ein paar akzeptable einzellösungen, KEINGEOARTIKEL=1 ist nicht dokumentiert - ist das neu? --W!B: 23:58, 9. Dez. 2008 (CET)Beantworten
gibt es schon länger und in anderen Boxen heißt der Parameter NEBENBOX/Nebenbox, etwa in Vorlage:Infobox Schule. Ein Parametername, den ich vorziehen würde, mit der Semantik, alles mit Auswirkungen auf den Artikel zu unterdrücken. KEINGEOARTIKEL ist bloß ein Spezialfall davon. --Herzi Pinki 00:18, 10. Dez. 2008 (CET)Beantworten
oh fein, den könnte man obligatorisch vorgeben: das wär schon mal ein erster klarer punkt fürs allfällige MB --W!B: 00:56, 10. Dez. 2008 (CET)Beantworten

In der Form nicht[Quelltext bearbeiten]

Dieses MB noch diesen Monat zu starten, halte ich für unklug. Soweit ich die Diskussionen, die unter "Motivation" aufgeführt sind, gelesen habe, sind diese noch nicht mal einen Monat alt und es gibt bereits ein Meinungsbild, welches ich auch Inhaltlich für Übertrieben halte. Ich seh ja den Sinn hinter der Vereinheitlichung von NKs und dem Bau von Unterinfoboxen, aber wieso bitte soll dann auch das Layout vereinheitlicht werden? Überschriften? Umfang? Sollte das nicht lieber in Portalhänden bleiben?--HarryDisk+/-Bau 11:48, 8. Dez. 2008 (CET)Beantworten

Die WP behandelt tausend unterschiedliche Themen, diese lassen sich nicht vereinheitlichen. Es hat auch seinen Grund, warum Vorlage:Infobox Militärischer Konflikt nicht gestaltet ist wie etwa Vorlage:Infobox Gemeinde in Deutschland. Ja selbst bei der Breite der Infoboxen gibt es Meinungsverschiedenheiten. Im geographischen Bereich wird man unter einer Breite von 300 px kaum auskommen, während viele technischen IBen oder solche zu Sportler sicher schmäler sein können. Bevor man hier ein MB beginnt, wäre zunächst einmal eine Bestandsaufnahme notwendig. --Matthiasb 12:39, 8. Dez. 2008 (CET)Beantworten

Ich denke auch, dass die Unterschiede zwischen den Infoboxen durchaus berechtigt sind. Allerdings könnte man überlegen, ob man nicht ein paar allgemeine Formatierungsregeln einführt, die für alle Infoboxen gelten, hier muss man vielleicht üebrlegen, was portalunabhängig ist. --Roterraecher !? 17:29, 8. Dez. 2008 (CET)Beantworten

Ich habe das MB jetzt entschärft und versucht, nur mehr auf layoutspezifische Probleme einzugehen, die mit der Individualität der Fachgebiete nicht mehr zu tun haben sollte. Die Forderung nach einer einheitlichen Breite für alle war aber auch vorher noch nicht drin ;-) --Farino 01:50, 9. Dez. 2008 (CET)Beantworten
stimmt einheitliche breite wär ein unding, maximalbreite und -länge aber sinnvoll (siehe eins unterhalb) --W!B: 00:14, 10. Dez. 2008 (CET)Beantworten

Überlegungen zur Pluralität[Quelltext bearbeiten]

Sowohl durch die Kollision von Infoboxen, als auch durch die - von mir aufgeworfene - Frage nach IBs, die den Artikelinhalt nicht zentral beschreiben wird es notwendig, mal gründlich über deren Funktion nachzudenken. Meine These ist:

  • Infoboxen sind ein Mittel der Kategorisierung. In verschiedenen Artikeln werden dieselben IBs verwendet, das klammert diese Artikel zusammen. Den Lesern soll das auch durch die tabellierten Informationen vermittelt werden. Es wird die Individualität eines Lemmas in einer zusammengehörigen Gruppe vorgeführt: links stehen Merkmale, die allen gemein sind (Berg hat eine Höhe), rechts solche, die sie von anderen unterscheidet (das Matterhorn ist 4'478 Meter hoch).
  • Lemmas gehören nicht nur einer Kategorie an. Genauso zwingt nichts dazu, dass die in Infoboxen enthaltenen Informationen sich nur mit der Zugehörigkeit zu genau einer Kategorie befassen.
  • So gesehen würden Infoboxen in ihrer Funktion beschränkt, wenn nicht jede von ihnen selbst Klassifizierungen und Ausprägungen herausarbeiten würde. Dies kollidiert mit dem Anspruch, eine Information nicht mehrfach aufzuführen. Wenn eine Insel gleichzeitig eine Gemeinde ist, wo stehen dann die Geokoordinaten?
  • Die meisten Infoboxen gehen durch ihr Layout stillschweigend davon aus, dass die durch sie beschriebene Kategorie den Artikelgegenstand umfassend charakterisiert. Oft wird das Lemma in der Titelzeile wiederholt; direkt darunter ist Platz für ein großes Bild vorgesehen, denn es wird davon ausgegangen, dass die Box gleich rechts oben eingebaut wird. Dieser Umfassungsanspruch ist falsch.

Meine Schlussfolgerung ist deshalb: Infoboxen müssen immer so gestaltet werden, dass mehrere gleichbererchtigt in einem Artikel Verwendung finden können. Ob dies Layout-Vereinheitlichung meint, weiß ich nicht. Es wird jedoch deutlich, dass die Vermeidung von Redundanzen (und dem damit verbundenen Platzverbrauch) und der Anspruch auf sachgerechte Darstellung in einen Interessenkonflikt geraten können. --Hk kng 20:22, 8. Dez. 2008 (CET)Beantworten

stimmt, insbesondere aber, Infoboxen müssen immer so gestaltet werden, dass sie den Artikel nicht dominieren
neben dem unding, eine ganze gallery (BILD1–7) einzubauen, oder breiten über 270px (1/3 der standardbreite, 300px goldener schnitt wär ausnahmsweise passabel: siehe oben geobereich/karten), betrifft das auch den inhalt: der artikel müsste mit .infobox {display:none;} in der CSS (wir haben noch keine class infobox, das aber mal angedacht: das würde viel IB-aversion vermeiden) genauso lesbar sein: sie muss also vollständig redundant zu artikel sein
der grössenwahn (sorry: wortwörtlich), der etlichen IBs zugrunde liegt, wird zunehmend auch in bezug auf die PDF-version, die die vollkommen in vergessenheit geratene druckfunktion wiederbeleben wird, bedeutend: so wäre etwa eine maximallänge von einer DIN A4 (standard-CSS, 12pt druckschrift) zwingend vorzuschreiben: bei mehreren boxen sinnvoller umbruch auf nächstes blatt (hurenkind/schusterjunge-regel)
--W!B: 00:10, 10. Dez. 2008 (CET)Beantworten
Das Abschalten von Infoboxen ist fragwürdig, weil einige Angaben (z.B. Fläche oder Einwohnerzahl) gar nicht mehr im Artikel vorkommen. Das hat Vor- und Nachteile, ist m.W. aber nie ausdiskutiert worden. --Farino 00:18, 10. Dez. 2008 (CET)Beantworten
class inxobox haben wir (glaub ich) bei SteveK mal ausführlich diskutiert, ich hab aber komplett vergessen, wo die diskussion gelandet ist - das modell war aber schon recht weit gediehen --W!B: 01:09, 10. Dez. 2008 (CET)Beantworten
Also Infofoxen sind ein Mittel der Kategorisierung würde ich mal glattweg unterschreiben. Nun würde ich natürlich den Ball für die Gestaltung der einzelnen Untermodule –«Kategorien»– an die Fachbereiche und Projekte zurückgeben. Grundvoraussetzung wäre erst mal zu jeder Box die betreuenden Portale zu ermitteln. Aus den Schnittmengen ergeben sich dann zwangsläufig die Module.-- visi-on 04:45, 10. Dez. 2008 (CET)Beantworten
streng genommen sind sie nicht ein mittel, sondern eine folge - sie sind ein mittel der Klassifizierung (sie betonen ja die eigenheiten des speziellen objekts innerhalb einer Objektklasse - also einer kategorie): und genau darum gehts - objekte konnen mehreren Klassen angehören, und ein „rang“ wird sich nur in ausnahme fällen feststellen lassen (ist eine Schule mehr Organisation oder Bauwerk? ist Steinsalz mehr Chemischer Stoff, oder mehr Mineral? ist Purpur mehr Chemikalie oder mehr Farbstoff)
Was war zuerst? Das Huhn oder das Ei ;-) aber klar doch ...
  • Eine Schule ist Organisation, mit mindestens einem zugeordneten Bauwerk (Altbau, Neubau, Turnhalle / Universitäten sind Typischerweise über die Ganze Stadt verteilt)
  • Ein Stausee ist ein See ist ein Stillgewässer ist ein Gewässer und hat mindestens ein zugeordnetes Stauwerk
  • Steinsalz ist ein Sediment ist ein Mineral mit chemischer Zusammensetzung
  • Purpur ist ein organischer Farbstoff (das ist konfliktfrei)
aus ISA-Beziehung und 1:m-Beziehung lassen sich klare Hierarchien ableiten. Nur eine Frage wie Fit man in Relationenalgebra ist. -- visi-on 04:06, 11. Dez. 2008 (CET)Beantworten
 ;) - was tun, wenn in einem gebäude zwei schulen sind.. (ok, die sind dann vielleicht nicht so relevant..) was tun, wenn der stausee natürlichen ursprungs ist (ok., dann ist er kein Stausee im Sinne der WP) - Steinsalz hast Du Dich nicht tratzen lassen: ist korrekt ein mineral, die chemikalie heisst Natriumchlorid
Du hast aber vollkommen recht: es ergeben sich typen,
  • die unvereinbar sind, und nur nacheinander stehen können
  • solche, wo typischerweise eine spezialisiertere Box besser ist
  • oder aber eine two-in-one-konstruktion mit unterboxen sinnvoll wäre: gerade bei der chemikalienbox hatten wir das vor sicher zwei jahren mal angedacht, zuerst bzgl. pharmazeutischen Wirkstoff, dann bzgl. Farbstoffen, ob eine infobox noch eine zweite einbinden könnte (die ist aber eh schon so übertrieben lang, und ist ein primärkandidat für optische straffung: massig sinnloser platzverbrauch und unnötige anmerkungen), auch Wien mit handgestrickter Box ist so ein fall
  • und solche, wo ein aspekt einen anderen artikel bekommt
--W!B: 07:21, 11. Dez. 2008 (CET)Beantworten
Ob der See natürlich oder künstlich ist, ist ein Attribut des Sees, darum ist auch die Lösung der Schweizer Stauseen besser, dort sind die Daten der Bauwerke extra. ... und nach mehr als einem Semester Chemie musst du dir etwas besseres einfallen lassen, mich zu erwischen -- visi-on 09:59, 12. Dez. 2008 (CET)Beantworten

Viele der Probleme entstehen aber erst durch das Unvermögen ein Lemma klar abzugrenzen. Dem Atomaren Ansatz stehen die Stub-Löscher gegenüber und bei den alles zum Ding Zusammenfassern fällt schliesslich alles aus dem Rahmen. -- visi-on 10:18, 12. Dez. 2008 (CET)Beantworten

Pottasche müsste eigentlich auch ein eigener Artikel sein, denn im Grunde beschreibt der Name ein Gewinnungsverfahren der Chemikalie. -- visi-on 10:25, 12. Dez. 2008 (CET)Beantworten

Klassendeklaration[Quelltext bearbeiten]

Es hat in der Vergangenheit mehrmals Anläufe zur Gestaltung der wichtigsten eigenschaften per CSS-Klasse gegeben. Das ist jedesmal an mangelnder Unterstützung gescheitert. Da wird es erst recht nicht funktionieren, noch genauere Regeln einzuführen. Insbesondere Admins ziehen da nicht mit. Cäsium137 (D.) 23:23, 8. Dez. 2008 (CET)Beantworten

tu nicht mit "admins" pauschalisieren: viele unserer admins sind alte hasen mit langer erfahrung, die nicht die infoboxen an sich, aber die infoboxitis durchaus kritisch sehen (aber das tun auch viele andere benutzer, mich eingeschlossen) - es gilt, plausible konzepte zu präsentieren, und per MB fragen, ob sie mehrheitlich tragfähig sind, nicht, diffus unzufriedenheiten zu äussern --W!B: 21:44, 9. Dez. 2008 (CET)Beantworten

Requirements an zentrale Infoboxen[Quelltext bearbeiten]

Ich versuche mal hier eine Requirementliste an zentralere Infoboxen zusammenzufassen, kann bitte gerne ergänzt und fortgesetzt werden:

  1. Vereinheitlichung der Parameternamen und -semantiken (kann sofort begonnen werden, GROSS vs. Kleinschreibung, Space vs. hyphen vs. underscore, ....)
  2. gemeinsame Blöcke herausfaktorisieren (z.B. Koordinate + Positionskarte, Bild+Bildbeschriftung, Koreanische Namen (Name ist immer orthogonal zur Objekteigenschaft Berg, Stadt, etc.; ) und Einbau in verschiedene Infoboxen. Dieses Drum ist ziemlich kompliziert, es wäre was gewonnen, das zentral zu machen. Dabei ist von außen die unterschiedliche Breite der Infobox und damit des Bildes zu erben, ebenso für Farben.
  3. Es muss weiter möglich sein, sinnvoll aus Parametern Kategorien zu generieren. Die Ortsboxen wären also um die länderspezifischen #switch:-statements zu bereinigen. Es braucht einen generellen Mechanismus, um solche komplizierten Parameterauswertungen per add-on oder Parameter zu übergeben. (z.B. Vorlage:Infobox Ort in Ungarn)
  4. generell Ausrichtung festlegen (Vorschlag: obenbündig, rechtsbündig, unter aber mit Abstand zur nächsten Infobox. Die Infoboxen rechts oben sind akzeptiert.)
  5. allgemeine Layoutregeln erarbeiten: Doppelpunkt oder nicht, Schriftgrößen und -auszeichnungen, Rahmen oder kein Rahmen
  6. Klappmechanismen, ja, nein, je nachdem? Ist zu klären.
  7. Vererbung von Farben in Subboxen muss möglich sein.
  8. class="infobox" in allen infoboxen, siehe oben.
  9. Trennung von Inhalt und Formatierung
  10. Die meisten Infoboxen sind 2spaltig, aber es gibt zumindest eine mir bekannte 3spaltige Ausnahme: Vorlage:Infobox Pass. Subboxen sollten auch in solchen Kontexten funktionieren.
  11. Umstellplan ist wichtig, ausreichend motivierte Mitarbeiter sind notwendig (die Umstellung auf die neue Koordinatenvorlage läuft seit fast einem Jahr, etwa 60 % umgestellt. GV?) viel kann botunterstützt oder zentral in existierenden Infoboxen erfolgen.
  12. wie ist mit Referenzen in Infoboxen umzugehen? Mein Vorschlag, keine Referenzen in Infoboxen, außer das <references />-tag kann abhängig vom Vorkommen der <ref>s erzeugt werden. Statt dessen lieber direktverlinken.
  13. Infoboxen müssen immer so gestaltet werden, dass mehrere gleichberechtigt in einem Artikel Verwendung finden können.
  14. Regeln zur homogenen (mehrere gleiche Boxen) und heterogenen (nterschiedliche Boxtypen) Mehrfachverwendung sollten definiert werden.
  15. bevor ein MB abgehalten werden kann, muss unbedingt eine funktionierende Probeimplementierung erstellt und getestet worden sein und ein Umstellplan existieren. Man muss die neue Box angreifen können! Bei der Koordinatenumstellung hat das auch nur funktioniert, weil ein weit entwickelter Prototyp vorhanden war.
  16. werden infoboxen aus einzelnen Blöcken zusammengestellt, sollte auch die Dokumentation der Parameter aus einzelnen Blöcken zusammengestellt werden.

(nicht vollständig) --Herzi Pinki 01:03, 10. Dez. 2008 (CET)Beantworten

  • Lösung für importe aus en ua.: parameter beibehalten? beide datensätze implementieren? oder in eine deutsche box wrapen (engl. name ruft deutsche box auf und übergibt die werte auf die de-variable)? oder umgekeht, die deutsche box ruft eine en: auf (vorteil: WP:Tellerrand, ansatz zu interwiki-vereinheitlichung und internationale boxen: ist aber zb mit de:Coordinate und commons:Location selbst so nicht einfach)
ad 7 Farbe könnte aber auch zur Identikation der einzelnen Module beitragen und müsste dann nicht vererbbar sein. -- visi-on 04:51, 10. Dez. 2008 (CET)Beantworten
Halte deine Anmerkung zu Punkt 7 wichtig. Zu Punkt 6: Klappmechanismen sind schlecht, da sie die Barrierefreiheit behindern und beim Ausdruck total bescheuerte Ergebnisse liefern. Man sollte diese Unart völlig eliminieren, es sei denn über CSS würde gesteuert, daß beim Ausdruck vernünftige Ergebnisse kommen. Sinnvoll wäre es, wenn eine Ausklappbarkeit etwa in den Benutzer-Einstellungen festgelegt werden könnte. --Matthiasb 11:20, 15. Dez. 2008 (CET)Beantworten
verstehe das schon mit der Farbe zur Themenidentifikation, aber bei drei Themen in einer Box muss zumindest darauf geachtet werden, dass die Box nicht knallbunt wird. Oder wir verwenden generell nur unbunte Farben. --Herzi Pinki 00:20, 16. Dez. 2008 (CET)Beantworten
Was sind „unbunte“ Farben? Etwa wie in Vorlage:Infobox Brücke oder Vorlage:Infobox Fluss? Sind die Farben, wie sie etwa Vorlage:NRHP (zu einem allerdings anderen Zweck, siehe etwa hier.) verwendet zu grell? --Matthiasb

Vorhande Ansätze zu Vereinheitlichungen[Quelltext bearbeiten]

Easiest First[Quelltext bearbeiten]

Ich nehme mal Herzi Pinkis Liste in einem Punkt auf und bitte um Stimmungsbild zu den Parameternamen am Beispiel eines Parameters zum Stand der Einwohnerzahl (--Farino 01:34, 10. Dez. 2008 (CET)):Beantworten

Einwohner-Stand (Groß/Kleinschreibung mit Bindestrich)

  1. --Farino 01:34, 10. Dez. 2008 (CET)Beantworten

Einwohner Stand (Groß/Kleinschreibung mit Leerzeichen)

  1. ...

Einwohner_Stand (Groß/Kleinschreibung mit Unterstrich)

  1. ...

EINWOHNER-STAND (Großschreibung mit Bindestrich)

  1. ...

EINWOHNER STAND (Großschreibung mit Leerzeichen)

  1. ...

EINWOHNER_STAND (Großschreibung mit Unterstrich)

  1. ...

EinwohnerStand (MixedCase)

  1. ...

(schlechtes Beispiel, da diese Information in Zukunft aus den Metadaten kommen könnte und sollte) --Herzi Pinki 01:03, 12. Dez. 2008 (CET)Beantworten

((Gut, jetz habe ich auch verstanden, warum sich hier niemand beteiligt)) --Farino 22:49, 12. Dez. 2008 (CET)Beantworten
Also MixedCase halte ich für inakzeptabel, mir gefällt die Version mit Bindestrich besser als mit Unterstrich. --Matthiasb 11:14, 15. Dez. 2008 (CET)Beantworten

Abbruch des MB[Quelltext bearbeiten]

Ich finde die Diskussion hier interessant, nützlich, nur ein MB wird das so nicht. Daher: Abbruch des noch nicht begonnenen MBs, Lösungsvorschlag entwickeln, ev. dann MB. --Herzi Pinki 01:05, 12. Dez. 2008 (CET) Die Diskussion sollte dann woanders erfolgen, etwa Wikipedia:WikiProjekt Vorlagen/Werkstatt/Vereinheitlichung der Infoboxen --Herzi Pinki 01:14, 12. Dez. 2008 (CET)Beantworten

full acc, vielleicht nur Wikipedia:WikiProjekt Vorlagen/Vereinheitlichung der Infoboxen - die werkstatt behandelt konkrete einzelfälle.. --W!B: 08:14, 12. Dez. 2008 (CET)Beantworten
Sind die Vorbereitungszeiten von MBs nicht genau dafür gedacht? --//[[Wuzur]] 19:46, 12. Dez. 2008 (CET)Beantworten

Ich werde nicht mit den 2½ bis 3 aktiven Mitarbeitern im WP:WikiProjekt Vorlagen in dahinsiechenden Diskussionen einen komplexen Vorschlag erarbeiten, um dann, wenn die erste Infobox entsprechend angepasst wird, von jedem einzelnen Portal/Redaktion/Projekt zu hören, dass sich die Vorlagen-Technokraten bitte aus der Hoheit der Fachleute raushalten sollen weil es keine Beschluss gab, überhaupt etwas an dem so bewährten System zu ändern. Danke für Eure Beiträge, bis irgend wann einmal wieder. --Farino 22:49, 12. Dez. 2008 (CET)Beantworten