Vorlage Diskussion:Infobox Gemeinde in Deutschland

Häufige Fragen (FAQ)

Darf ich die Vorlage für Ortsteile verwenden?

Nein.

… Ämter, Samtgemeinden und andere Verwaltungsgemeinschaften?

Ja. Die passende Kategorie wird automatisch gewählt.

… Landkreise?

Nein.

Warum fehlt das Land?

Weil die Zeile keinen Informationsgewinn gegenüber der Karte und dem Bundesland bringt.

Warum gibt es keinen Parameter für den Ausländeranteil?

Die Zahl allein ist nichtssagend. Ein Parameter führt zum gedankenlosen Einsatz ohne Erläuterungen.

… Verwaltungssitz?

Bei Gemeinden, die von außerhalb verwaltet werden, |Adresse-Verband = Musterstraße 1<br />12345 [[Musterstadt]] eintragen.

… E-Mail?

Weil gänzlich unklar ist, ob und wo die E-Mail ankommt. Die Website bietet mehr Transparenz.

Warum verschwindet der rote Punkt beim Vergrößern der Karte?

So lange diese technische Einschränkung besteht, bitte die Koordinaten anklicken.

Muss ich dezimale Koordinaten umrechnen?

Nein. Einfach |lat_deg = 1.2345 eintragen und die Parameter dahinter löschen.

Warum funktioniert meine Fläche nicht?

Zahlen müssen ohne Tausendertrennzeichen und mit Punkt statt Komma eingegeben werden.

Warum nennt die Stadt eine größere Einwohnerzahl?

Verbindlich sind nur die Zahlen der statistischen Ämter, die Zweitwohnsitze nicht mitzählen.

Warum soll ich keine Postfächer und Großempfänger eintragen?

Weil verwässerte Angaben wie „52231–52249“ anstelle von „52249“ kein Postleitzahlen-Verzeichnis ersetzen.

Warum werden NUTS und LOCODE nicht angezeigt?

Die Metadaten dienen der Suche. Beim normalen Lesen wären sie nicht hilfreich.

Warum steht bei meiner Stadt „Gemeindeverwaltung“?

Bitte die Zeile |Art = Stadt ergänzen.

Sind Adresse und Straße das selbe?

Ja. Der Parameter Straße sollte wenn möglich bevorzugt werden. Die andere Zeile jeweils löschen.

Warum fehlt bei unserer Bürgermeisterin das „in“?

Bitte die Zeile |Bürgermeistertitel = Bürgermeisterin ergänzen.

Darf ich auch |Partei = parteilos schreiben?

Ja, natürlich.

Warum heißt die Vorlage nicht „Infobox Gemeinde“?

Weil sie nicht nur für Gemeinden sondern auch für Verwaltungsgemeinschaften benutzt wird.

Schreibt man „Geographie“ nicht mit „f“?

Beides ist richtig. In der Wikipedia wird nach einem Meinungsbild einheitlich „ph“ verwendet.

Parameter im Detail

Art

Gemeindeart, typischerweise Art = Stadt. Andere mögliche Werte: Ortsgemeinde, Amt, Gemeindeverwaltungsverband, Samtgemeinde, Verbandsgemeinde, Verwaltungsgemeinschaft, Verwaltungsverband. Kann bei Gemeinden weggelassen werden.

Name

Offizieller Name der beschriebenen Stadt oder Gemeinde. Sollte weggelassen werden, wenn der Artikelname den Namen der Gemeinde bereits korrekt (ohne Präfix, Klammerzusatz o. ä.) wiedergibt. Wird für die Alternativtexte des Wappenbildes und der Karte, für die Einsortierung innerhalb der Kategorie und im Zusammenhang mit dem Parameter Straße benötigt.

Wappen

Dateiname des Wappens ohne „[[Bild:“ etc., z. B. Wappen = Coat of arms of Berlin.svg. Kann weggelassen werden (). Bei Ortschaften, die kein Wappen führen, bitte Wappen = kein einsetzen (). Vor dem Hochladen neuer Wappen bitte die Hinweise unter Wikipedia:Wappen beachten!

Wappengröße

Für sehr kleine Wappengrafiken, die beim standardmäßigen Vergrößern auf 140 Pixel Breite unschöne Artefakte zeigen, kann die Originalgröße angegeben werden. Sollte nur in begründeten Ausnahmefällen angewandt werden.

lat_deg | lat_min | lat_sec | lon_deg | lon_min | lon_sec

Geographische, nördliche Breite und östliche Länge zur automatischen Kartenerstellung, z. B. lat_deg = 52 | lat_min = 31 | lon_deg = 13 | lon_min = 23 in sexagesimaler (Grad, Minuten und Sekunden) oder lat_deg = 52.52 | lon_deg = 13.38 in dezimaler Schreibweise. Die Angabe von Bogenminuten bzw. zwei Nachkommastellen (Genauigkeit ≈ 2 km) ist im Allgemeinen ausreichend. Insbesondere bei kleineren Orten empfiehlt sich aber auch die Angabe der Bogensekunden bzw. drei oder vier Kommastellen. Im Zweifelsfall sind die Daten des Bundesamtes für Kartographie und Geodäsie zu verwenden.

Karte

Dateiname einer vorbereiteten Deutschlandkarte, z. B. Karte = Dresden in Germany.png. Nur für Ausnahmefälle, in denen die automatische Kartenerstellung mit lat_deg etc. unzureichend ist.

Lageplan | Lageplanbeschreibung

Detailkarte, die üblicherweise die Lage des Ortes im Landkreis zeigt. Wird als 299 Pixel großes Bild am unteren Ende des Kastens angefügt. Eine passende Lageplanbeschreibung nach dem Muster „Lage der Gemeinde/Stadt/andere Art … im Landkreis/Kreis …“ wird automatisch ergänzt, wenn sie fehlt.

Bundesland

Name des Bundeslands ohne eckige Klammern, z. B. Bundesland = Bayern. Von dieser Schreibweise darf nicht abgewichen werden, da die Angabe auch für die Zuordnung zur Kategorie:Ort in Bundesland genutzt wird.

Regierungsbezirk

Name des Regierungsbezirks, wenn benötigt, z. B. Regierungsbezirk = [[Regierungsbezirk Dresden|Dresden]] oder kurz Regierungsbezirk = Dresden.

Landkreis | Kreis

Art und Name des Landkreises, in dem der beschriebene Ort liegt, z. B. Landkreis = [[Landkreis Ulm|Ulm]] oder kurz Landkreis = Ulm. Es sollte immer nur einer der beiden Parameter verwendet werden.

Amt | Gemeindeverwaltungsverband | Samtgemeinde | Verbandsgemeinde | Verwaltungsgemeinschaft | Verwaltungsverband

Art und Name der Verwaltungsgemeinschaft, der die beschriebene Gemeinde eventuell zugeordnet ist, z. B. Amt = [[Amt Grube|Grube]] oder kurz Amt = Grube für Gemeinden in diesem Amt. Die Angaben sind vom Bundesland abhängig und können in den meisten Fällen weggelassen werden.

Höhe

Mittlere Höhe (keine von-bis-Angabe) in Meter über Normalnull, z. B. Höhe = 115. Im Zweifelsfall sind die Daten des Bundesamtes für Kartographie und Geodäsie zu verwenden.

Fläche

Fläche in km², z. B. Fläche = 10.75. Achtung: Alle Zahlen müssen in der englischen Form, also mit Punkt statt Komma und ohne zusätzliche Tausendertrennzeichen eingegeben werden. Sie werden bei der Anzeige automatisch in die lokal übliche Form umgewandelt.

Einwohner

Vom Statistischen Bundes- oder Landesamt herausgegebene amtliche Einwohnerzahl ohne Zweitwohnsitze, z. B. Einwohner = 15350. Tausenderpunkte werden in der Anzeige automatisch ergänzt.

Stand

Stand der Einwohnerzahl im Datumsformat JJJJ-MM-TT nach ISO, z. B. Stand = 2005-12-31. Wird bei der Anzeige automatisch in die lokal übliche Form umgewandelt.

PLZ

Zustell-Postleitzahl oder Zustell-Postleitzahlenbereich des Ortes (ohne Postfächer und Großempfänger), z. B. PLZ = 09111–09112 (mit Bis-Strich).

PLZ-alt

Alte, vierstellige Zustell-Postleitzahl, wenn vorhanden.

Vorwahl

Telefonvorwahl oder Vorwahlbereich.

Kfz

Kfz-Kennzeichen ohne <tt> o. ä.

Gemeindeschlüssel

Achtstelliger amtlicher Gemeindeschlüssel im Format XX X XX XXX. Die in einigen Bundesländern vergebenen 10-stelligen Schlüssel bitte nicht verwenden, da mit diesen nicht bundeseinheitlich recherchiert werden kann.

NUTS | LOCODE

Zusätzlich zum Gemeindeschlüssel können die NUTS-3-Region der EU und der LOCODE der UN erfasst werden. Diese Angaben werden als Metadaten gehandhabt, so dass u. a. danach gesucht werden kann, sie werden jedoch nicht angezeigt.

Gliederung

Anzahl der Ortsteile oder Stadtbezirke, z. B. Gliederung = 4 [[Ortsteil]]e oder Gliederung = 5 [[Stadtbezirk]]e. Bei nur einem Ortsteil bitte weglassen.

Adresse | Straße

Vollständige Postanschrift des Verwaltungssitzes, z. B. Adresse = Musterstr. 1<br />12345 Musterstadt oder kurz Straße = Musterstr. 1. Der Parameter Adresse sollte nur verwendet werden, wenn der Parameter PLZ nicht zur Bildung der offiziellen Postanschrift geeignet ist.

Adresse-Verband

Adresse des Verwaltungsitzes bei Gemeinden, die von außerhalb verwaltet werden. Bei Gemeinden, die zwar einem Verband (Amt, Samtgemeinde etc.) angehören, aber nach wie vor über einen eigenen Verwaltungssitz verfügen, hat der Parameter Adresse den Vorrang.

Website

Link zur offiziellen Webpräsenz der Gemeindeverwaltung, z. B. Website = [http://www.berlin.de/ www.berlin.de] oder (bei besonders langen Adressen) Website = [http://www.doberschau-gaussig.de/ www.doberschau-<br />gaussig.de]. Am Ende des Artikels sollte der Link nur wiederholt werden, wenn er die allgemeinen Grundsätze für Weblinks („vom Feinsten“, „keine Unterbegriffe“) erfüllt.

Bürgermeister | Bürgermeistertitel

Name und evtl. abweichender Titel des Ortsvorstehers, z. B. Bürgermeister = Maria Musterfrau und Bürgermeistertitel = [[Bürgermeister]]in oder kurz Bürgermeistertitel = Bürgermeisterin. Es sollten nur Links zu existierenden Artikeln eingesetzt werden.

Partei

Politische Partei des Ortsvorstehers, z. B. Partei = [[Christlich Demokratische Union Deutschlands|CDU]]. Für die großen Volksparteien CDU, CSU und SPD kann auch verkürzt z. B. Partei = CDU notiert werden.

Kategorisierung

Durch den Einsatz der Infobox werden alle Artikel automatisch den jeweils passenden Gemeinde-, Verbands- und Landkreis-Kategorien zugeordnet, zum Beispiel Kategorie:Gemeinde in Bundesland für Städte (mit Art = Stadt) und Gemeinden (ohne Art =), Kategorie:Samtgemeinde (Bundesland) für Samtgemeinden (mit Art = Samtgemeinde) usw. Die sonst üblichen Quelltextzeilen am Ende der Artikel können (müssen jedoch nicht) weggelassen werden.

Es gibt zwei Ausnahmen, in denen die Abänderung der von der Vorlage vorgebenen Kategorien dennoch notwendig ist:

1. Die MediaWiki-Software ist augenblicklich nicht in der Lage, Umlaute den im deutschsprachigen Raum gültigen Regeln entsprechend zu sortieren. Der Artikel Bächingen an der Brenz beispielsweise würde unterhalb von Buxheim auftauchen und Öhringen sogar hinter Zwingenberg. Für alle Ortsnamen mit Umlauten muss daher am Ende des Artikelquelltextes die Zeile {{DEFAULTSORT:Bachingen an der Brenz}} (ä→a, ö→o, ü→u, ß→ss), {{DEFAULTSORT:Ohringen}} usw. eingefügt werden.
2. Samtgemeinden, Ämter etc. sind im Allgemeinen nach dem Schema Samtgemeinde Bardowick o. ä. benannt und würden demnach unter „S“ einsortiert werden. Die korrekte Sortierung sollte bevorzugt durch Ausfüllen der Vorlagen-Zeile Name = Bardowick oder mit {{DEFAULTSORT:Bardowick}} hergestellt werden.

Die in solchen Fällen eigentlich doppelten Kategorie- oder DEFAULTSORT-Zeilen werden von der MediaWiki-Software korrekt weiterverarbeitet und nur die im Quelltext unterhalb der Infobox stehenden Angaben zur Sortierung herangezogen.

Werkzeuge

• Werkzeug zum komfortablen Ausfüllen des Vorlagen-Quelltextes (benötigt JavaScript)
• Wikipedia:WikiProjekt Georeferenzierung (WP:GEO) hilft bei der Ermittlung geographischer Koordinaten.
• Geographische Namen Deutschlands (GN-DE) beim Bundesamt für Kartographie und Geodäsie
• Suche im Gemeindeverzeichnis des Statistischen Bundesamtes
• Digitales Postleitzahlenbuch der Deutschen Post (Postlagerausgaben und Großempfänger nicht in die Artikel übertragen)
• Postleitzahlen-Auskunft der Universität Stuttgart zur Suche nach alten Postleitzahlen
• Liste aller NUTS-3-Regionen für Europa
• Liste aller UN/LOCODEs für Deutschland

Wartungslisten mit Hilfe des Projekts Vorlagenauswertung

Leere oder ganz fehlende Vorlagenparameter

• Fehlende Höhen.  Ok (nur Nicht-Verbandsgemeinden) 7. Aug. 2007
• Fehlende Flächen.  Ok 7. Aug. 2007
• Fehlende Einwohnerzahlen.  Ok 7. Aug. 2007
• Fehlende Postleitzahlen.  Ok (alle außer Verbandsgemeinden, Ämter und Samtgemeinden) 7. Aug. 2007
• Fehlende Vorwahlen.  Ok (alle außer Verbandsgemeinden, Ämter und Samtgemeinden) 7. Aug. 2007
• Fehlende Gemeindeschlüssel. Muss bei manchen Verwaltungsverbänden leer bleiben.  Ok 9. Jul. 2007
• Fehlende Adressen. Mindestens einer, maximal zwei der drei Parameter sollten gefüllt sein.  Ok 7. Aug. 2007
• Fehlende Bürgermeister  Ok (bis auf einige Gemeinden des Amt Uecker-Randow-Tal) 29. Aug. 2007

Sonstiges

• Vorbereitete Kartenbilder. Löschen, wenn sie nur einen Punkt enthalten.  Ok 6. Jul. 2007
• Manuell eingesetzte Wappengrößen. Ist beim SVG-Format Unfug.  Ok 6. Jul. 2007
• Ungültige Wappengrößen. Darf maximal 139 sein, ohne px dahinter.  Ok 28. Aug. 2007
• Ungültige Fehlt-Wappen. Der Parameter muss in diesem Fall leer gelassen werden.  Ok 28. Aug. 2007
• Ungültige Höhen. In die Infobox gehört nur die mittlere, auf ganze Meter gerundete Höhe. Sonstige Angaben bitte in den Artikeltext in den Abschnitt „Geographie“ verschieben.
• Alte Postleitzahlen im falschen Parameter.  Ok 28. Aug. 2007
• Ungültige LOCODEs. Das DE darf nicht fehlen.  Ok 28. Aug. 2007
• Ungültige NUTS-Codes. Das DE darf nicht fehlen.  Ok 28. Aug. 2007
• Ungültige Gemeindeschlüssel. Müssen dem Format „XX X XX XXX“ entsprechen.  Ok 28. Aug. 2007
• Bürgermeister, die mit Vornamen „Herr“ heißen. Möglichst auch in allen anderen Wikipedias korrigieren.  Ok (DE) 30. Aug. 2007
• Bürgermeisterinnen mit besonders häufigen weiblichen Vornamen (Beispiel-Anfrage). Die Liste der Vornamen in der Adresszeile kann beliebig erweitert werden.

Diskussion

Adresse bei gemeindefreien Gebieten

Bei gemeindefreien Gebieten (z.B. in Gutsbezirk Münsingen) gibt es diese unschöne Ausgabe: Adresse der Gemeindefreies Gebietverwaltung. --217.237.151.117 23:18, 11. Jun. 2007 (CEST)

Ist „Adresse der Gebietsverwaltung“ korrekt oder nennt man das in diesem Fall anders? Und ist die Doppelkategorisierung als „Gemeinde“ und „Gemeindefreies Gebiet“ richtig? --TM 10:41, 12. Jun. 2007 (CEST)

Zu Letzterem: Neihen, denn ein gemeindefreies Gebiet gehört eben zu keiner Gemeinde (und ist schon gar keine!) -- PvQ 10:46, 12. Jun. 2007 (CEST)

Die Doppelkategorisierung ergibt sich aufgrund der Verwendung der Infobox - meines Erachtens sollte diese in gemeindefreien Gebieten nicht verwendet werden --Roterraecher ^Diskussion 14:53, 12. Jun. 2007 (CEST)

Würde ich auch so sehen, denn die anderen beiden bewohnten gemeindefreien Gebiete verwenden die Infobox ebenfalls nicht (Lohheide und Osterheide). Lagekarten 16:17, 12. Jun. 2007 (CEST)

Ok, aber warum steht dann in allen diesen Artikeln ein Gemeindeschlüssel? Ich meine, wenn ein Gebilde einen amtlichen Gemeindeschlüssel hat, muss es doch eine Gemeinde sein, oder? --TM 16:34, 12. Jun. 2007 (CEST)

Zitat aus Amtlicher Gemeindeschlüssel (Hervorhebung von mir):

Der Amtliche Gemeindeschlüssel (AGS), früher auch Amtliche Gemeindekennzahl (GKZ) oder Gemeindekennziffer, ist eine Ziffernfolge zur Identifizierung politisch selbständiger Gemeinden oder gemeindefreier Gebiete.

Zitat aus gemeindefreies Gebiet:

Ein Gemeindefreies Gebiet ist ein Ausdruck aus dem Verwaltungsrecht und bezeichnet ein abgegrenztes Gebiet, das zu keiner politischen Gemeinde gehört.

Nur weil das Ding so heißt, ist ein gemeindefreies Gebiet noch lange keine Gemeinde. Der Name würd sonst zu lang, das ist alles. -- PvQ 16:40, 12. Jun. 2007 (CEST)

Ok, also keine Doppelkategorisierung Gemeindefreier Gebiete als „Gemeinde“. Ich habe die Vorlage entsprechend angepasst (die Änderung war wirklich minimal). Zusammenfassend bin ich dennoch der Meinung, dass die Infobox auch für die Gemeindefreien Gebiete verwendet werden sollte, und zwar ganz pragmatisch deshalb, weil sie in der Verwaltungshierarchie auf der selben Stufe mit den Gemeinden stehen (im Gegensatz zu z. B. Ortsteilen). --TM 09:22, 13. Jun. 2007 (CEST)

Nö. Stehen sie nicht, mangels kommunaler Selbstverwaltung. Da stehen sie eher auf der Ebene von Ortschaften. -- PvQ 09:27, 13. Jun. 2007 (CEST)

Ich würde mir eine pragmatische Herangehensweise wünschen. Schau dir den Artikel Gutsbezirk Münsingen an und sage mir, ob dort durch den Einsatz der Infobox inhaltlich/sachlich etwas falsch ist. Das Gemeindefreie Gebiet hat einen Gemeindeschlüssel, es ist einem Landkreis untergeordnet und es wird im Geodatenzentrum mit Fläche und Einwohnerzahl aufgeführt. Diese Bedingungen, mit denen wir uns bisher immer gegen den Einsatz der Infobox bei Ortsteilen verwehrt haben, sind bei den Gemeindefreien Gebieten erfüllt. --TM 18:16, 13. Jun. 2007 (CEST)

Leider hat ja auch das Wehren gegen Infoboxen in Ortsteilen nichts geholfen... Nachdem selbst Ortsteile eine Infobox bekommen, kann man es dem gemeindefreien Gebiet wohl auch nicht absprechen - allerdings sollten die dann wohl auch eher die Orsteilinfobox verwenden, die Gemeindeinfobox ist nunmal nur für Gemeinden da. --Roterraecher ^Diskussion 12:20, 14. Jun. 2007 (CEST)

Breite der Infobox

Oft folgt nach der Infobox ein Foto einer typischen Ortsansicht, das einen ersten Eindruck vermitteln und darum größer als die nachfolgenden Fotos dargestellt werden soll. Für solche Fotos hat sich die Breite „300px“ eingebürgert (oder „upright=1.65“, was das Selbe bewirkt). Leider passt unsere Infobox nicht dazu – sie ist effektiv 3px zu klein. Ich würde das gern ändern, aber es hat auch Nachteile:

• Die Infobox wird breiter (zwar nur 3px, aber immerhin).
• Die Spalten lassen sich dann nicht mehr gleichmäßig verteilen, eine wird 1px breiter als die andere (das liegt an der Trennlinie in der Mitte).
• In Artikeln, in denen jetzt Fotos bündig mit 297px eingebunden sind, erscheint das Foto dann zu klein.

Einwände? --TM 13:09, 14. Jun. 2007 (CEST)

Einwand. Die Box ist eh schon unnötig breit, sie sollte schmaler und nicht breiter werden, mindestens reduziert auf 275px. --Roterraecher ^Diskussion 13:36, 17. Jun. 2007 (CEST)

Mir ist die Infobox persönlich auch schon etwas zu breit. Außerdem wurden die Landkreis-Lagekarten SWIW in Berücksichtigung der Boxbreite angefertigt, sodass zu den bereits genannten Nachteilen ein weiterer käme. Außerdem bezweifle ich, dass ein represäntatives Foto direkt unter die Box sollte und dann auch noch in der Größe. Daher lieber so lassen wie es ist.--Eigntlich (w) 13:45, 17. Jun. 2007 (CEST)

Mir persönlich eigentlich gleich, 3px machen hin oder her meiner Ansicht nach keinen großen Unterschied. Nur eins wollte ich klarstellen: upright=1.65 bewirkt, wie auch angegeben, nur bei der Standardeinstellung einer Bildbreite von 180px ein Bild, das 300px breit ist. Ich beispielsweise habe standardmäßig 300px eingestellt, bei mir kommt da also ein überbreites Bild (500px) raus. Das gilt so ähnlich für alle, die sich eine größere Bildbreite als 180px eingestellt haben. In Kombination mit einer Box mit fester Breite ist der Upright-Parameter deshalb m. E. ungeeignet. Viele Grüße --Rosenzweig δ 14:57, 17. Jun. 2007 (CEST)

Tabelle mit 307px Breite (alt)

Tabelle mit 281px Breite (neu)

Ok, ok, überzeugt. Reden wir über eine Verkleinerung der Infobox. Andere Infoboxen sind 280px breit. Hier brauchen wir eine ungerade Zahl, also 281px. Nach Abzug aller Rahmenlinien (3 × 1px) und Innenabstände (4 × 2px) würden 135px für die Inhalte verbleiben. Nachteile:

• Die Karte muss kleiner werden (135px statt bisher 140px).
• Das Wappen muss kleiner werden (im Beispiel rechts 127px statt bisher 140px). Bei hochaufgelösten Wappen oder SVG-Grafiken macht das nichts aus, es gibt aber auch Wappen, die gezielt in 140px Größe erstellt wurden. Diese wären dann leicht verwaschen.
• Lange Wörter und Weblinks haben noch weniger Platz als bisher schon. Bevor jemand fragt: Nein, eine Verkleinerung der Schriftgröße kommt nicht in Frage.

Habe ich ein Argument vergessen? --TM 17:39, 19. Jun. 2007 (CEST)

Unschöne Umbrüche werden wohl die Regel. (Zumindest in Villingen-Schwenningen sehe ich jetzt schon einige volle Zeilen, die Adresse der Stadtverwaltung hat schon so einen Umbruch.)

Um die nötigen Pixel frei zu bekommen, wird wohl hauptsächlich die linke Seite dran glauben müssen, was wiederum zu schlechterer Lesbarkeit führt und damit den Nutzen der Infobox (wichtige/prägnante Fakten/Informationen schnell und übersichtlich präsentieren) ad absurdum führt. --32X 13:54, 20. Jun. 2007 (CEST)

Vermeintlicher Fehler in der Deutschlandkarte

Hallo alle zusammen! Kann vielleicht kurz mal jemand hier vorbeischauen: Diskussion:Heilbronn#Deutschlandkarte Ich vermute, dass das Problem bekannt ist und irgendwo schon mal ausdiskutiert wurde, ich weiß nur nicht wo. Danke im Voraus.--Peter 13:09, 20. Jun. 2007 (CEST)

Für das Archiv: Der rote Punkt wurde fehlerfrei positioniert – auch in dem vom Benutzer verwendeten Webbrowser. Es schien, als würde die Ausgabe der Infobox nicht zur Vorstellung des Benutzers passen, wo der rote Punkt seines Ortes liegen müsste. --TM 11:54, 3. Jul. 2007 (CEST)

Praktische Relevanz der UN/LOCODEs

Ja, ich habe die FAQ gelesen wonach die LOCODEs nicht angezeigt werden, weil sie nur als Metadaten verwendet werden. Ich fände es aber bedeutend besser, wenn diese Codes angezeigt werden. Dieser Standard führt noch immer ein Nischendasein, dabei erlaubt er die standardisierte Adressierung von Orten auf der ganzen Welt, von dem viele Menschen in ihrer Kommunikation und Datenverarbeitung profitieren können. Natürlich kann man ihn in den UNECE-Listen nachlesen, aber warum soll man ihn nicht gleich auch über Wikipedia bekommen, wenn man sich über eine Stadt informiert. Durch die Stadt-Info hat man zum Beispiel auch die Sicherheit, dass die Zuordnung stimmt, schliesslich gibt es viele Orte in Deutschland mehrfach und es ist mitunter mühsam einen LOCODE über die UNECE-Website sicher zu ermitteln (man muss z. B. erst Koordinaten checken, sofern welche gegeben sind, womöauch noch Wikipedia und telefonbuch.de um nachzusehen wieviele andere Orte dieses Namens es noch gibt usw.). Ich finde daher, dass man den Lesern diese Info nicht vorenthalten sollte, sondern die LOCODEs darstellen. Mir würde es in meiner Arbeit wirklich oft helfen, wenn die LOCODEs in Wikipedia dargestellt werden würden und diese ohnehin vorhandene Info nicht versteckt würde. Schließlich könnte man den Nutzern ebensogut die Telefon-Vorwahlen, die Kfz-Kennzeichen, die Gemeindeschlüssel usw. vorenthalten. Daher meine dringende Bitte, die Vorlage entsprechend zu ändern. --141.30.203.4 22:26, 23. Jun. 2007 (CEST)

Lass es mich mal so formulieren: Du bist seit Jahren der erste, der diese Information benötigt. --TM 08:53, 25. Jun. 2007 (CEST)

Ich bin vielleicht der erste, der sich hier in der Infobox-Diskussion meldet. Andere Nutzer der Wikipedia kommen gar nicht so weit, sondern vermissen die Info bloß / können sie ja gar nicht finden, weil sie eben nicht dargestellt wird. Es gibt keinen sinnvollen Grund, diese Info zu verbergen. Bitte änderet die Vorlage, so dass LOCODEs angezeigt werden. Ich habe die Gründe ausführlich erörtert. Oder diskutiert handfest. --141.30.203.4 19:32, 28. Jun. 2007 (CEST)

Wie gesagt, bisher hat sich noch nie einer dieser „anderen“ Nutzer dazu geäußert. Ansonsten kann ich nur das wiederholen, was bereits in der Dokumentation steht: Der LOCODE dient der Suche. Ihn anzuzeigen, wäre nicht sinnvoll, da er für 99,9 % der Leser nicht nur bedeutungslos wäre sondern auch verwirrend und die Infobox nur künstlich aufgebläht würde. Anders formuliert: Es ist nicht die Aufgabe der Wikipedia, „Kommunikation und Datenverarbeitung“ zu vereinfachen oder „Standards, die ein Nischendasein führen“, zu propagieren. Die Wikipedia ist eine Enzyklopädie, nicht mehr und nicht weniger. --TM 09:18, 29. Jun. 2007 (CEST)

Eure Argumentation gegen ein Anzeigen der LOCODEs ist so sinnlos. Ebensogut könntet Ihr den Gemeinseschlüssel ausblenden. Der ist nicht weniger „verwirrend“ oder „nutzlos“ und nach dem hat sich bestimmt auch noch niemand erkundigt. Diese eine Angabe mehr bläht auch die Infobox nicht so auf, dass das den Informationsgewinn nicht kompensieren würde. Der LOCODE gehört zu jeder Gemeinde genau so wie es das Kfz-Kennzeichen, die Vorwahl, der Gemeindeschlüssel tut. Niemand will hier was propagieren. LOCODE ist ein Weltstandard der Vereinten Nationen, nicht irgendwas willkürliches. Dieser Standard ist noch relativ jung - daher das bisherige Nischendasein. Ich will die Info nur zugänglich bekommen. Immerhin ist ein Datenfeld dafür in der Infobox vorgesehen und diese Codes sind wirklich sehr hilfreich. Und zwar eben gerade für eine Enzyklopädie! Er ermöglicht mit gerade einmal fünf Zeichen die Adressierung jeder Gemeinde auf der Welt. Dadurch ist für nicht Ortskundige und zum eindeutigen Identifizieren von Orten (deren Namen sich oft doppeln und mehr) sehr hilfreich. Ich finde es ziemlich ignorant, wenn Ihr davon ausgeht, nur weil Ihr ihn nicht braucht, braucht ihn sonst niemand. Und das Argument, dass ich der erste bin, der sich meldet, das lasse ich überhaupt nicht zählen. Otto Normal-Wikipedia-Nutzer, der selbst nicht editiert, der findet gar nicht bis hierher in die Infobox-Diskussion. Der muss nur am Frontend mit dem leben, was die hochnnäsigen Autoren ihm eben geben oder nicht. Nehmt das jetzt bitte nicht persönlich, aber ich bin über Eure (Nicht-)Argumentation entsetzt. Letztlich betreibt Ihr so etwas wie Zensur. --141.30.203.4 00:57, 1. Jul. 2007 (CEST)

„Ich will die Info nur zugänglich bekommen.“ – Ich schlage eine CSS-Lösung vor, wie sie auch bei den Personendaten existiert: standardmäßig sind die Personendaten ausgeblendet, wer sie sehen will, aktiviert sie mittels CSS. --32X 01:36, 1. Jul. 2007 (CEST)

Es geht hier nicht nur um mich, sondern um die Allgemeinheit. „Ich will die Info nur zugänglich bekommen.“ meint für alle, nicht nur für Spezialisten. Diese CSS-Lösung ist etwas für Poweruser. Ich schlage die ganz normale Anzeige vor, wie für die anderen Daten. --141.30.203.4 01:51, 1. Jul. 2007 (CEST)

Liebe IP. Ich betrachte die Diskussion an dieser Stelle als beendet, da ich deinen unsachgemäßen, beleidigenden Beiträgen keine neuen Argumente entnehmen kann außer, dass du es so willst. Der Vorteil der eindeutigen Identifizierung, den du forderst, ist bereits durch den Gemeindeschlüssel gegeben. --TM 11:05, 1. Jul. 2007 (CEST)

Darf ich diese Diskussion nochmal eröffnen? Ich habe bis jetzt folgende Gründe für’s Ausblenden identifiziert:

1. Verwirrt Leser.
2. Bläht die Infobox auf.

Dazu fallen mir folgende Gegenargumente ein.

1. Das erinnert mich irgendwie an die Geschichte, warum Mc Donald's in den USA keinen heißen Kaffee mehr ausschenkt. Es könnte sich ja jemand dran verbrühen, weil er nicht weiß, dass Kaffee heiß ist. ;-) Aber ernsthaft: Unterschätzt unsere LeserInnen nicht.
2. Es sind ja beispielsweise in Deutschland nur 3554 Orte, die einen LOCODE haben. Eine spontane Durchsicht scheint mir darauf hinzudeuten, dass diese Orte bereits recht umfangreiche Artikel haben. Daher denke ich, dass eine Infobox auch mit zwei zusätzlichen Codes noch in einem angemessenen Verhältnis zum Text steht.

--jpp ?! 15:00, 4. Jul. 2007 (CEST)

Den wichtigsten Grund (siehe auch mein abschließender Kommentar vom 1. Juli) hast du vergessen:

3. In Deutschland werden Gemeinden anhand ihres Gemeindeschlüssels eindeutig identifiziert. Im Rahmen der Ortsartikel vermittelt der LOCODE keine Information, die über das hinaus geht, was man jetzt schon dem Gemeindeschlüssel entnehmen kann.

Es ist natürlich interessant zu wissen, welche Orte von der UN als so herausragend betrachtet werden, dass sie einen eigenen LOCODE erhalten. Aber das ist eine Information, die sehr viel mehr über das System der LOCODEs aussagt als über den Ort und dementsprechend in den Artikel UN/LOCODE gehört, nicht in 3554 Ortsartikel. --TM 15:45, 4. Jul. 2007 (CEST)

Mein Gegenargument zu Punkt 3: Die über den Gemeindeschlüssel hinausgehende Information ist der LOCODE an sich. --jpp ?! 15:56, 4. Jul. 2007 (CEST)

Verstehe ich das richtig? Ich bin gegen die Anzeige des LOCODEs, weil es eine Information um ihrer selbst Willen wäre, und du führt genau das als Pro-Argument an? --TM 16:34, 4. Jul. 2007 (CEST)

Jetzt nähern wir uns endlich dem Kern der Diskussion: Du sagst, niemand interessiert sich für LOCODEs. Ich sage, doch, es gibt Menschen, die sich für LOCODEs interessieren – m. a. W. die Information an sich ist relevant.

Also sollten wir uns fragen: Was wiegt schwerer? Der Schaden, den die Anzeige des UNLOCODEs anrichten würde oder der Nutzen. Den Schaden haben wir oben durch die Argumente 1 und 2 beschrieben. Der Nutzen besteht einfach darin, unseren LeserInnen möglichst neutrale Informationen zu einem Ort zu geben. Neutral heißt für mich in diesem konkreten Fall, dass nicht wir für andere entscheiden, ob sie nun den Gemeindeschlüssel, das Kraftfahrzeugkennzeichen, den LOCODE oder die NUTS-Kennung wichtiger finden oder dringender brauchen, sondern dies zu entscheiden den Lesenden selbst überlassen, indem wir einfach alle vier anbieten. --jpp ?! 16:53, 4. Jul. 2007 (CEST)

Es ist ziemlich ermüdend, die selbe Argumentation immer und immer wieder wiederholen zu müssen, weil sie scheinbar nicht verstanden wird. Ich mache es deshalb kurz: Lege bitte dar, inwieweit der LOCODE es ermöglicht, weitere Informationen über einen Ort aufzufinden, die mit dem Gemeindeschlüssel nicht erreichbar sind. --TM 18:52, 4. Jul. 2007 (CEST)

Warum führst du immer die gleichen ermüdenden Diskussionen, anstatt den Code einfach einzublenden? Wer außer dir würde sich dran stören? Ein Beispiel: „Welchen LOCODE hat Bückeburg?“ Beantworte diese Frage bitte, indem du in der Wikipedia unter Bückeburg nachschaust, ohne den Quelltext zu betrachten. Eine andere Frage zum Vergleich: „Welchen amtlichen Gemeindeschlüssel hat Schwaikheim?“ Welchen Unterschied gibt es deiner Meinung nach zwischen diesen beiden Fragen? --jpp ?! 20:05, 4. Jul. 2007 (CEST)

Eine Enzyklopädie ist das völlig falsche Werkzeug zur Beantwortung dieser Fragen. --TM 20:31, 4. Jul. 2007 (CEST)

Oh, das übliche Totschlagargument. Da du meine Fragen also offenbar nicht beantworten möchtest, interpretiere ich das mal als höflich formuliertes „EOD“ deinerseits. Damit du das nicht in den falschen Hals kriegst: Ich schätze deine Arbeit an dieser Vorlage sehr hoch ein, finde es aber schade, dass ihr Potenzial nicht noch etwas mehr genutzt wird. --jpp ?! 20:55, 4. Jul. 2007 (CEST)

Du hast meine Frage aber auch nicht beantwortet. Der Unterschied zwischen den Fragen „Welchen LOCODE hat Bückeburg?“ und „Welchen Gemeindeschlüssel hat Schwaikheim?“ wäre, dass ich für Ersteres auf den Webseiten der UN und für Letzteres auf den Webseiten des Statistischen Bundessamtes nachsehen würde. Beides ist völlig problemlos auffindbar ([1], [2]). --TM 21:26, 4. Jul. 2007 (CEST)

1. Für uns problemlos auffindbar, nicht unbedingt für alle unsere LeserInnen. 2. Warum es unseren LeserInnen unnötig schwer machen, wenn wir die Information doch sowieso haben? --jpp ?! 21:36, 4. Jul. 2007 (CEST)

Kfz-Kennzeichen:	BZ
Gemeindeschlüssel:	14 2 72 010
Stadtgliederung:	15 Stadtteile

Zitat von dir: „Unterschätzt unsere LeserInnen nicht.“

Ich würde das wirklich sehr gern mit der selben CSS-Anweisung lösen wie bei den Personendaten. Leider bezieht sich die CSS-Klasse dort auf Tabellen. Selbst mit Kniffen tief aus der CSS-Trickkiste würde das zu Fehldarstellungen führen. Und so wie rechts willst du es ja auch nicht haben, oder doch? --TM 22:05, 4. Jul. 2007 (CEST)

Ach ja, hier noch ein wenig aktuelle Statistik:

• Momentan wird die Vorlage in 12.786 Artikeln eingesetzt.
• Von den 3554 LOCODEs sind momentan 211 eingetragen, das sind 6 %.
• Der Parameter NUTS ist momentan in 511 Artikeln ausgefüllt, das sind ziemlich genau 4 %. (Die NUTS-3-Codes beschreiben Gebiete, die etwa den Landkreisen entsprechen, der Parameter kann also genau wie die Zeile |Landkreis = bei allen Artikeln ausgefüllt werden.)

Also (nur mal rein theoretisch) wenn die Diskussion zeigt, dass diese beiden Parameter zu viel Verwirrung auslösen, könnten wir sie auch problemlos ganz aus der Vorlage verbannen. --TM 23:18, 4. Jul. 2007 (CEST)

Nee, bitte nicht entfernen, dazu sind sie viel zu wertvoll für Tools aller Art. Ich bin ja schon ruhig und höre auf zu diskutieren. ;-) Irgendwelche Kopfstände mit CSS möchte ebenfalls nicht, bin ein Anhänger des KISS-Prinzips. Von mir aus lassen wir sie halt ausgeblendet. Ich gebe auf und konzentriere mich wieder auf andere Themen. --jpp ?! 10:28, 5. Jul. 2007 (CEST)

Als Initiator der Diskussion möchte ich mich mal wieder einklinken. Ich hab hier niemanden beleidigen wollen und das meiner Ansicht nach auch nicht getan. Ansonsten möchte ich mich hiermit dafür entschuldigen und bitte aber auch mal darum zu bedenken, was es umgekert für jemanden wie mich bedeudet, wenn er eine ordentliche Arguemntation abliefert und dann mit einem Zweizeiler argumentativ inhaltsfrei totgeschlagen wird, er sei ja der einzige der das bräuchte. Es kam im ersten Abschnitt der Diskussion von TM keine andere als diese Argumentation. Das habe ich durchaus auch als Beleidigung auffassen können. - Aber zurück zum Thema: Die Argumentation, der Gemeindeschlüssel tauge zur eindeutigen Identifikation und mache damit NUTS und LOCODE überflüssig geht an meinem Anliegen total vorbei. Es geht nicht nur darum, eine Gemeinde eindeutig zu identifizieren, denn das gelingt aus ihrer Beschreibung in dem Artikel und über die geografischen Koordinaten auch schon sehr präzise, nur auf anderen Levels. Es geht darum, den Nutzern, ein der Gemeinde zugeordnetes Kürzel nicht vorzuenthalten. Eine Enzyklopädie dient der Bildung, als Nachschlagewerk und da ist es mir unbegreiflich, diese fünf LOCODE-Buchstaben zu verbergen, die vor allem für internatinale Anwender ein hilfreiches Instrument sein können. Und warum sind noch nicht so viele LOCODEs eingetragen? Na vielleicht weil es Leuten wie mir zu blöd ist, etwas zur Wikipedia beizutragen, das dann eh nicht angezeigt wird. Und die Metadaten bringen auch nix. Zum Beispiel führt eine Wikipedia-Suche nicht zum Artikel, wenn man den LOCODE eingibt. Gruß, Benjamin --141.30.203.4 14:39, 5. Jul. 2007 (CEST)

1. Lege bitte dar, inwieweit der LOCODE es ermöglicht, weitere Informationen über einen Ort aufzufinden, die mit dem Gemeindeschlüssel nicht erreichbar sind.
2. Wikipedia-interne Suche nach einem LOCODE. Da kontinuierlich an der Suchfunktion gearbeitet wird, kann es sein, dass frühere Suchanfragen scheinbar nicht mehr funktionieren oder andere Ergebnisse liefern. (Alternativ: Die selbe Suche mit dem Templatetiger. Bisher ist das allerdings nur eine Machbarkeitsstudie und daher kaum praxistauglich.)
3. Die Kodierung als Metadaten hat den Vorteil, dass der Benutzer die Wahl hat, ob er sie sehen möchte. Dazu ist lediglich ein dank der Personendaten standardisierter, gut dokumentierter einmaliger Eingriff in der eigenen monobook.css notwendig. Die offene Frage ist, wie die Metadaten dann angezeigt werden sollen? Als zweite Tabelle unterhalb der Infobox oder eingebettet, wie oben beispielhaft dargestellt? --TM 17:33, 5. Jul. 2007 (CEST)

TM fragt nach weiteren Informationen, die der LOCODE enthält, der Gemeindeschlüssel jedoch nicht. Das ist ja aber genau das Verständnisproblem in dieser Diskussion. Der LOCODE ist eine Information zu einem Ort, ein Merkmal des Ortes, auf einem in Formatierung und Zuweisung international standardisierten Niveau. Er hat ausser der Internationalität gegenüber dem Gemeindeschlüssel zum Beispiel den Vorteil, dass er menschenlesbar ist, dass in einem gegebenen Kontext in vielen Fällen leicht zur Identifikation eines Ortes genutzt werden kann. So ist aus 14 2 72 010 nicht herauslesbar bzw. kaum in großer Menge durch Menschen verarbeitbar, dass von Bautzen die Rede ist, aus DE BAU aber schon. Mindestens ist DE BAU um etliche Potenzen einpärgsamer als 14 2 72 010. Für internationale Adressierung ist der Gemeindeschlüssel daher im Vergleich zum LOCODE ebenso unbrauchbar wie für menschenverarbeitete Informaionen. Insofern hinkt der ständig bemühte Vergleich mit dem Gemeindeschlüssel. Eher ist der LOCODE dem (jedoch nicht gemeinde-eindeutigen) Kfz-Kennzeichen verwandt. Außerdem möchte ich mal wissen, warum Du so eine Panik davor hast, dass die Wikipedia-Artikel durch die Angabe von LOCODE (und evtl. NUTS) plötzlich leserunfreundlich aufgebläht werden würden. Wir diskutieren hier über fünf bzw. neun variable Buchstaben. Benjamin --141.30.203.4 17:57, 5. Jul. 2007 (CEST)

Von der Länge her würden LOCODE und NUTS auch in eine Infobox-Tabbellenzeile passen, um mal das Aufblähen-Argument ein wenig zu adressieren. --141.30.203.4 18:00, 5. Jul. 2007 (CEST)

Deine Analyse unseres Verständnisproblems ist absolut zutreffend, nur unsere Sichtweisen sind verschieden. Sowohl LOCODE als auch Gemeindeschlüssel sind genau das, nämlich Schlüssel. Schlüssel dienen dazu, Informationen aufzufinden. Nicht mehr und nicht weniger. Auch die Gemeindeschlüssel sind nur Schlüssel und für sich genommen vollkommen inhalts- und wertlos. Zu wissen, dass die Stadt Bautzen vom Statistischen Bundesamt „14 2 72 010“ genannt wird, nützt dem Leser nicht das Geringste, wenn er keine Möglichkeit hat, diesen Schlüssel für etwas Sinnvolles zu verwenden. In den Ortsartikeln stehen die Gemeindeschlüssel nur aus einem einzigen Grund: Weil sie es ermöglichen, weitere Informationen über einen Ort aufzufinden. Womit wir wieder bei meiner ursprünglichen Frage wären, auf die ich bisher keine Antwort erhalten habe. --TM 18:49, 5. Jul. 2007 (CEST)

Der LOCODE wird beispielsweise in EDIFACT verwendet und spielt somit in elektronischen Geschäftstransaktionen eine Rolle. Ich selbst habe damit zwar bisher keinen Kontakt gehabt, kann mir aber vorstellen, dass jemand nachschauen möchte, welchen LOCODE Offenbach am Main hat. Vielleicht ist es ein armer Softwareentwickler beim Anlegen von Testdaten? Oder ein Hafenlogistiker, dem sein Programm abgestürzt ist und der deshalb die Wikipedia befragt um sein Frachtpapier manuell ausfüllen zu können? ;-) Ich denke mir das halt als Analogie zu anderen Codes, mit denen ich täglich zu tun habe, und bei denen ich durchaus die Wikipedia als Nachschlagewerk benutze: Z. B. suche ich den ISO-Code einer Währung oder möchte wissen welches 2-Buchstaben-Kürzel die Garuda hat, um zu wissen, wonach ich auf der Anzeigetafel des Flughafens suchen muss. --jpp ?! 11:32, 6. Jul. 2007 (CEST)

Noch einmal: Wenn „jemand nachschauen möchte, welchen LOCODE Offenbach am Main hat“, dann ist er in einer Enzyklopädie (Darstellung von Wissen in einer für die Allgemeinheit hinreichenden Ausführlichkeit) falsch! --TM 17:03, 8. Jul. 2007 (CEST)

Diese Behauptung fand ich schon beim ersten Mal wenig überzeugend. Und das Ausrufezeichen macht sie auch nicht überzeugender. ;-) Damit wir uns nicht völlig im Kreis drehen, möchte ich deine Schlussfolgerung diesmal etwas genauer analysieren. Aus welchem Teil der zitierten Definition des Begriffs „Enzyklopädie“ leitest du ab, dass der LOCODOE nicht in eine Enzyklopädie gehört?

1. Ist der LOCODE deiner Meinung nach kein Wissen?
2. Oder ist die Allgemeinheit nicht am LOCODE interessiert?
3. Oder ist die bloße Erwähnung des LOCODES nicht ausführlich genug?

--jpp ?! 17:43, 8. Jul. 2007 (CEST)

Selbst wenn eine solche Codetabelle enzyklopädisch relevant wäre, würde sie in den Artikel UN/LOCODE gehören. --TM 19:31, 8. Jul. 2007 (CEST)

Oh Mann, TM möchte es einfach nicht verstehen. Ich lese einen Artikel über eine Stadt und dabei auch deren Locode. So weiss ich, wie ich die Stadt in international standardisierter Weise nennen und damit zugleich eindeutig bezeichnen kann. Ein Schlüssel geht doch in beide Richtungen. Wendet man die "dann gehört sie in...."-Agumentation an, dann müssen schnellstmöglich die Postleitzahlen, Vorwahlen, Kfz-Kennzeichen, Gemeindeschlüssel, Bürgermeisternamen usw. aus der Infobox entfernt werden. Denn die kann man ja auch in Enzyklopädie-Codetabellen zum Nachschlagen vorhalten. Ich bin der Meinung, TM ist überstimmt und die Vorlage Infobox sollte geändert werden, so dass sie die LOCODEs anzeigt. Wenn dann in absehbarer Zeit unzählige "was soll das denn?"-Beschwerden eingehen (ohne gefakte), können wir ja noch mal darüber diskutieren. Benjamin --141.30.207.240 02:32, 21. Jul. 2007 (CEST)

Ich habe auf meine Frage vom 1. und 4. Juli bisher keine Antwort erhalten: „Lege bitte dar, inwieweit der LOCODE es ermöglicht, weitere Informationen über einen Ort aufzufinden, die mit dem Gemeindeschlüssel nicht erreichbar sind.“ --TM 15:00, 22. Jul. 2007 (CEST)

Eigentlich wollte ich mich ja heraushalten, aber diese Behauptung kann ich nicht unkommentiert stehen lassen. Natürlich hast du Antworten auf deine Fragen bekommen, sie haben dich aber offensichtlich nicht überzeugt. Lies noch mal oben nach. (Bückeburg usw.) Diese Informationen sind mit dem Gemeindeschlüssel nicht erreichbar. --jpp ?! 15:02, 23. Jul. 2007 (CEST)

Meine Güte. Dass man den LOCODE sehen kann, wenn man ihn sehen kann, habe ich ja nun verstanden. Aber wozu soll das gut sein? --TM 18:54, 23. Jul. 2007 (CEST)

Schlichte Antwort: Weil es Menschen gibt, die das wissen wollen. :-) --jpp ?! 19:43, 23. Jul. 2007 (CEST)

Da hier niemand auch nur ein einziges Beispiel für die praktische Verwendung der LOCODEs nennen kann, muss ich davon ausgehen, dass die Codes keinerlei Relevanz haben und die Diskussion hier nur um ihrer selbst willen fortgesetzt wird. Vergleiche dazu WP:RK und WP:WWNI. --TM 20:22, 23. Jul. 2007 (CEST)

Weder WP:RK noch WP:WWNI listen auch nur einen Grund, warum die Codes nicht angezeigt werden sollten. WP:RK widmet sich nur ganzen Artikeln. Und es ist schon irgendwie frech, wenn Du behauptest, niemand hätte hier eine praktische Verwendung nennen können. Hab ich zur Genüge getan. Aber wenn Du diese Gebetsmühlendiskussion fortführen willst.... Ich kann mich auch wiederholen: Jemand informiert sich über eine Stadt, die er zum Beispiel besuchen möchte, zu der er etwas schicken möchte, die er in einer Arbeit (zusammen mit anderen Städten) beschreiben möchte, zum Beispiel leicht Datenbank-verarbeitbar. Der Locode ist seine international normierte Abkürzung für diese Stadt. So wie es der ISO3166-1 ALPHA2 Code für das Land ist. Vorteile (Gebetsmühle): International gleich = gleiche Anzahl Buchstaben = besonders Datenintegrationssicher da fixe Stringbreite, international Eindeutig, Beschränkung auf die 26 lateinischen Buchstaben (zu jedem Computersystem kompatibel), an einer Zentralstelle revalidierbar. Gebetsmühle: Nur weil Du die Dinger nicht verwendest sind sie nicht evil und die Wikipedia-Benutzer verwirrend, sondern eine überfällige Bereicherung der Infobox. Wenn Du hier „„„argumentierst“““, niemand hätte Dir eine Verwendung gezeigt, dann sei Dir gesagt, dass Du auf die Gegenargumente ja kein Bisschen mehr eingehst. Wenn die Locodes überflüssig sind, dann sind es Kfz-Kennzeichen, Gemeindeschlüssel, Postleitzahlenbereich und Vorwahlen auch. Da wird die Infobox aber schlank! Sollte man sie nur noch in Box umbenennen. Denn Info ist dann ja keine mehr drin. Du bist hier der Einzige, der mauert. Daher mein Votum: „Du bist überstimmt.“ Oder ist die Wikipedia etwa nicht demokratisch? Wenn die LOCODEs dann einen Sturm der Entrüstung auslösen können wir ja mit den dann sich hierher verirrenden Städte-Editoren weiterdiskutieren. Soweit mein Vorschlag. Benjamin --141.30.207.240 23:10, 25. Jul. 2007 (CEST)

Bitte verzeih, aber auf den theatralischen Umkehrschluss, dass man dann auch alles andere löschen müsste, gehe ich nicht ein. Den Kern deiner Argumentation, dass der Code „die standardisierte Adressierung von Orten“ erlauben würde, habe ich schon vor einem Monat verstanden. Meine Frage beantwortet das nicht: Wo, in welcher Datenbank, Webdienst etc., kann der Leser diesen Vorteil konkret nutzen? --TM 10:58, 26. Jul. 2007 (CEST)

Ja, dass Du auf Gegenargumente nicht inhaltlich eingehst (theatralisch, ja ja...), das habe ich schon mitbekommen. Offenbar bist Du auch noch stolz darauf?!? Zeige mir doch mal den Nutzen des Gemeindeschlüssels. Zeige mir den Nutzen des Kfz-Kennzeichens. Den der Vorwahl(en). Den des Postleitzahlenbereichs. Und zwar stets so, warum sie in die Infobox gehören und nicht viel besser nur in einer Zuordnungsliste untergebracht sind, anstatt bei jedem Stadt-Artikel einzeln. Wenn Du die gemeinsame Antwort dafür gefunden hast, dann übertrage sie auf den LOCODE. - Zu Deinen Fragen: In welcher Datenbank der Nutzer sie verwenden kann? Na in jeder, in der er möchte; was für eine Frage. Mich mal als Beispiel genommen: Ich verwende LOCODEs in meiner Adressdatenbank, um Orte immer eindeutig und speichersparend zu beschreiben. Ebenso in meiner Reiseplanung und Wochenplanung so wie den Reisekosten-Abrechnungen. Auch in Statistiken und Grafiken, Präsentationen und wissenschaftlichen Arbeiten habe ich sie schon verwendet (eröffnet gegenüber selbst erdachten Kürzeln die spätere Weiterverwendbarkeit in anderen Anwendungen). Standarisierte Anwendungen: Die Logistik-EDV, siehe EDIFACT und darauf aufbauend z. B. der Gütertransport per Schiff bedienen sich der Adressierung von Häfen per LOCODE (gesetzlich vorgeschrieben). Einen Webdienst habe ich auch gefunden: [3] setzt den LOCODE in seinen URI ein. Benjamin --141.30.207.240 23:52, 12. Aug. 2007 (CEST)

Einen Kompromissvorschlag habe ich unter [4] ergänzt. Benjamin --141.30.183.142 18:47, 20. Aug. 2007 (CEST)

Webpräsenz oder Website

Sorry, dass ich mich trotz des "eledigt" dazu melde. "Website" steht im Duden, "Webpräsenz" nicht. "Website" ist der geläufige Begriff. Warum sollte die Wikipedia hier Begriffsfindung betreiben? -- 84.57.240.49 10:05, 26. Jun. 2007 (CEST)

Mit 1 Million Google-Suchergebnissen ist „Webpräsenz“ ganz sicher keine Begriffsfindung sondern eine absolut geläufige Übersetzung für das Fremdwort website. Nicht jedes zusammengesetzte Substantiv muss unbedingt im Duden stehen, um „richtig“ zu sein. „Webpräsenz“ beschreibt auch viel präziser, um was es geht, da es sich nicht um irgend eine website handelt sondern um die ganz konkrete Präsenz der Gemeinde im Web. Hinzu kommt, dass das Fremdwort website mit Webseite einen äußerst problematischen falschen Freund hat – dort sogar ausdrücklich erwähnt. --TM 10:58, 26. Jun. 2007 (CEST)

(danke fuer die verschiebung an die richtige stelle) ok, google gewinnt hier mal gegen den duden. "website" ist also bloss der gelaeufigere begriff. die falsche-freund-argumentation lasse ich hingegen nicht gelten, denn die leute, die den unterschied zwischen "site" und "seite" nicht kennen, vermuten eh, dass es sich beide mal um eine "website" handle, und das tut es ja in diesem falle. dass "praesenz" besser geeignet sei, als "site" sehe ich nicht so. "webpraesenz" heisst soviel wie "anwesenheit"/"vorhandensein" (die bedeutung als tempus lassen wir mal beiseite) und ist damit nicht spezieller als "site". anders gesagt (verzeih, dass ich dich nun absichtlich verdreht zitiere): "„Website“ beschreibt auch viel präziser, um was es geht, da es sich nicht um irgend eine Webpräsenz handelt sondern um die ganz konkrete Site der Gemeinde im Web." -- 84.56.254.148 10:21, 28. Jun. 2007 (CEST)

„die bedeutung als tempus lassen wir mal beiseite“: das schreibt sich anders, nämlich Präsens. --Rosenzweig δ 15:39, 30. Jun. 2007 (CEST)

Anders formuliert: „Webpräsenz“ ist schlicht die geläufige deutsche Übersetzung des englischen Fachbegriffs. Dass man diesen bei Google häufiger findet, sagt kaum etwas über die tatsächliche Geläufigkeit im allgemeinen Sprachgebrauch aus sondern zeigt eher, dass die im Web aktive Bevölkerungsschicht solche Fachbegriffe liebt oder zumindest blind übernimmt. --TM 18:59, 28. Jun. 2007 (CEST)

das geht nicht nur der web-aktiven bevoelkerungsschicht so, sondern auch der rest ist eher mit dem begriff "website" vertraut als "webpraesenz". im "tatsaechlichen" sprachgebrauch wird "website" meiner erfahrung nach noch mehr bevorzugt als es via google erkennbar waere. wie gesagt, hat es "website" sogar in den duden geschaft, im ggs. zu "webpraesenz".

"website" ist nun mal der fachbegriff; er geht einfach leichter ueber die lippen und es ist ja auch nicht verwerflich einen terminus in die umgangssprache aufzunehmen (sogar im gegenteil: es hat vorteile bzgl. der verstaendlichkeit, aber das soll hier nicht thema sein). aehnlich gelagert ist es beim begriff "link", dessen deutsche uebersetzung "verweis" bzgl. des internets kaum verwendung findet. -- 84.56.239.132 09:02, 29. Jun. 2007 (CEST)

• „der rest ist eher mit dem begriff "website" vertraut“. Quelle?
• „hat es "website" sogar in den duden geschaft“. Ich fürchte, du missverstehst die Funktion des Dudens.
• „"website" [...] geht einfach leichter ueber die lippen“. Das ist deine Meinung, ich sehe das ganz anders. Hast du mal versucht, das auszusprechen, wenn du kein Englisch kannst? Wir schreiben hier eine deutschsprachige Enzyklopädie, kein Fachbuch. „Webpräsenz“ ist eine präzise Übersetzung für den englischen Fachbegriff. Durch die Verwendung der deutschen Entsprechung geht keinerlei Information verloren. Darauf hatten wir uns bereits geeinigt, also warum diskutieren wir trotzdem noch? --TM 09:39, 29. Jun. 2007 (CEST)

eine quelle ist - wie gesagt - der duden. und "der Duden wird regelmäßig bearbeitet und an die Entwicklung der deutschen Sprache angepasst.[...] Die Dudenredaktion beobachtet die Sprachentwicklung und nimmt Wörter, die mit einer gewissen Häufigkeit in den Medien auftauchen, in das Wörterbuch auf. Der Duden ist dadurch sehr aktuell und hat den modernen Wortschatz erfasst." (Duden). "website" ist sowohl fachbegriff als auch ugs. begriff. "webpraesenz" ist nicht wirklich eine komplett deutsche entsprechung, denn das wort "web" ist ja schliesslich schon aus dem englischen uebernommen. (man wuerde uebrigens, "ohne englisch zu koennen" das "e" lang aussprechen, weil man es mit "weben" in verbindung braechte.) "deutscher" waere sowas wie "netzpraesenz", aber das ist _noch_ ungebraeuchlicher.

ja, durch die verwendung von "webpraesenz" gehen keine informationen verloren. das waere bei "netzverweis" vs. "weblink" aber auch der fall und trotzdem nehmen wir in der wikipedia den "weblink".

warum verwenden wir also nicht auch "website" statt "webpraesenz"? das bleibt weiterhin meine frage und damit grund der diskussion. -- 84.56.225.122 23:07, 29. Jun. 2007 (CEST)

Liebe IP. Deine Argumente gehen völlig an der Diskussion vorbei. Insbesondere sagt der Duden nichts darüber aus, dass bestimmte Wörter verwendet werden müssten. Das ist nach wie vor nichts weiter als deine persönliche Meinung. --TM 11:21, 1. Jul. 2007 (CEST)

ich dachte eigentlich, dass ich direkt auf deine argumente eingegangen bin, aber vermutlich hast du mich bloss falsch verstanden. ich sage nicht, dass der duden vorschreibt, welche woerter benutzt werden muessen, sondern habe ihn bloss als quelle herangezogen, da er sprachwirklichkeit widerspiegelt. meine meinung ist, soweit hast du mich ja verstanden, dass "website" der bessere begriff ist. meine frage, weshalb der begriff "webpraesenz" bei den ortschaftsartikeln verwendet wird, hast du vor allem damit versucht zu beantworten, dass es die deutsche uebersetzung sei. nun, aber "website" _ist_ bereits ein eingedeutschtes wort (und zudem wesentlich gebraeuchlicher, nicht nur meiner erfahrung nach, sondern eben auch nach meinung der duden-redaktion). insofern sehe ich meine frage als noch offen an. -- 84.57.255.168 13:34, 1. Jul. 2007 (CEST)

Wir drehen uns im Kreis. Ich betrachte diese ermüdende Diskussion als beendet. --TM 00:53, 2. Jul. 2007 (CEST)

Infobox erzeugt falsche Einträge in Linklisten

Die Infobox erzeugt im Hintergrund falsche Einträge auf Linklisten. In der Box steht hinter Landkreis: nur ein Name, der dann beim Verlinken automatisch zu Landkreis Name wird. Bei den Gemeinden des Landkreis Harz zum Beispiel steht in der Box nur Harz, verlinkt dann aber zu Landkreis Harz. In der Spezial:Linkliste/Harz sind nun aber die betroffenden Gemeinden ebenfalls auftgetaucht, was das Aufräumen der BKS sehr behindert. Ein weiteres Beispiel ist Spezial:Linkliste/Mansfeld-Südharz. Einen Artikel Mansfeld-Südharz gibt es überhaupt nicht, wohl aber den Landkreis Mansfeld-Südharz.

Dieses Problem sollte dringend behoben werden. Gruß Gulp 11:11, 1. Jul. 2007 (CEST)

PS: Jetzt ist mir auch klar, wieso die Gemeinden des Landkreises Harburg alle auf den Hamburger Stadtteil/Bezirk Harburg verlinken ... Gulp 11:31, 1. Jul. 2007 (CEST)

Dieses Problem wurde weiter oben auf dieser Seite schon einmal angesprochen. Kurz gesagt handelt es sich um einen Fehler in der Mediawiki-Software, den wir hier in der Vorlage nicht beheben können, auch nicht durch Umstellen des Quelltextes. Bereits die Überprüfung mittels #ifexist: erzeugt intern einen Link zum überprüften Lemma, der dann fälschlicherweise in dessen Linkliste auftaucht. Dieser Fehler ließe sich nur umgehen, wenn die betreffenden Quelltextabschnitte vollständig entfernen würden. Das würde die Flexibilität der Vorlage jedoch ganz entscheidend beschneiden und zu unzähligen fehlerhaften Ausgaben in den Ortsartikeln führen. Vorerst bleibt uns leider nichts anderes übrig, als damit zu leben (so wird auch hier argumentiert). --TM 12:06, 1. Jul. 2007 (CEST)

Ok, wußte ich nicht, dass es schon mal diskutiert wurde. Ist denn Änderung in sicht? Dass es relativ wening Fehlermeldungen gibt liegt sicherlich daran, dass nicht soviele User BKS warten. Gruß, Gulp 12:31, 1. Jul. 2007 (CEST)

Mit der Hilfe von Benutzer:08-15 konnte ich das früher schon gemeldete Problem bei den Regierungsbezirken entschärfen, indem ich den Quelltextabschnitt vereinfacht habe. Bei den Landkreisen müssen wir uns leider in Geduld üben, bis der Bug in der Mediawiki-Software behoben ist. --TM 22:54, 4. Jul. 2007 (CEST)

Alte Kfz-Kennzeichen

Im Zuge der Kreisreform in Sachsen-Anhalt werden ja auch die Kfz-Kennzeichen geändert. Wäre es nicht sinnvoll auch die alten mit anzugeben? Derzeit fahren ja noch keine Autos mit dem neuen "ABI" rum. --Alma 10:19, 3. Jul. 2007 (CEST)

Nein, ich glaube nicht. Und wenn, dann gehört diese Information doch in die Landkreisartikel, meinst du nicht? --TM 10:44, 3. Jul. 2007 (CEST)

Dort auf alle Fälle. Bei den Ortsinfoboxen ist es halt schwerer. Die alten PLZ werden ja auch meist mit angeben, warum nicht auch die Kfz-Kennzeichen. Derzeit fährt ja niemand mit "ABI" rum, aber dafür genug mit "BIT". --Alma 10:48, 3. Jul. 2007 (CEST)

Halte ich generell für problematisch. Im Zuge der sächsischen Kreisgebietsreform Mitte der 90er war der Übergang vom Kreis Weißwasser zum Niederschlesischen Oberlausitzkreis verbunden mit einem Kennzeichenwechsel WSW->GR->NY->NOL. In den besagten Gemeindeartikeln finde ich aber auch kein Hinweis auf diese vier Kennzeichen. Sinnvoll wäre ggf. eine von vornherein zeitlich befristete Angabe „ABI (alt: BIT)“ für maximal ein Jahr. --32X 11:20, 3. Jul. 2007 (CEST)

An so etwas hatte ich gedacht. --Alma 11:31, 3. Jul. 2007 (CEST)

Eine solche zeitliche Frist wäre nur mit ungerechtfertigt hohem technischem Aufwand möglich. Wer soll diese Angabe nach Ablauf des Jahres entfernen und wie? Abgesehen davon glaube ich, dass die Information, welche Gemeinde wann und warum welchem Landkreis zugeschrieben wurde, nicht unkommentiert in eine Infobox gestopft werden darf. Das gehört in die betroffenen Landkreisartikel. --TM 12:01, 3. Jul. 2007 (CEST)

Graue Linie unterhalb des Gemeindeschlüssels

Kann die Anzeige so geändert werden, dass die unschöne graue Linie verschwindet, die meinem Verständnis nach die leere Box für LOCODE und NUTS darstellt, falls diese Angaben nicht vorhanden sind? Sichtbar ist die Linie bei mir im Firefox, im Opera dagegen nicht. -- Zef 16:19, 1. Aug. 2007 (CEST)

Das passiert, weil in deiner monobook.css die Anweisung display: block; steht. Korrekt für Firefox und Opera wäre display: table;. --TM 17:16, 1. Aug. 2007 (CEST)

Oh, Danke. Den Schnipsel hatte ich vor zwei Jahren dort eingetragen, weil damals irgendwo beschrieben wurde, dass so die Personendaten-Box angezeigt wird. Ich habs geändert und jetzt ist die Linie weg. -- Zef 10:50, 2. Aug. 2007 (CEST)

Unsere Infobox soll barriereärmer werden

Das Projekt Wikipedia:BIENE beschäftigt sich seit einigen Wochen intensiv mit dem Thema Barrierefreiheit und versucht im Augenblick, Interessenten zu finden und Vorgehensweisen zu organisieren. Angeregt durch die dortigen Diskussionen habe ich mir unsere Infobox angesehen und dabei mehr Barrieren identifiziert als mir lieb ist. Ich habe daher eine eigene Seite Vorlage Diskussion:Infobox Ort in Deutschland/Barrierefreiheit angelegt und würde mich über jede Hilfe freuen. --TM 20:03, 2. Aug. 2007 (CEST)

Thiemo, Du hast bei deiner letzten Änderung die CSS-Klasse error verwendet, die, soweit ich das sehe, nicht in Common.css, sondern bei mir in Monobook definiert ist. Wäre es nicht sinnvoller, diese Klasse nach Common zu verschieben, als das per Skin zu definieren? --S.K. 11:29, 7. Aug. 2007 (CEST)

Ich verstehe nicht ganz, worauf du hinaus willst. Die CSS-Klasse error gibt es seit mindestens 3 Jahren. Dass die Klasse zum Monobook-Skin gehört, bedeutet ja nur, dass die Farbe der Fehlermeldungen vom Skin abhängig ist. Ich halte das für sinnvoll und würde es nicht ändern. --TM 15:15, 7. Aug. 2007 (CEST)

Das die Farbe im Skin geändert/angepasst werden kann, klar. Aber so muss jedes Skin die Klasse haben, es gibt kein "Standardverhalten"/keine "Standardfarbe", wenn man die Klasse im Skin nicht hat. D.h. damit geht man davon aus, dass jedes Skin "fehlerfrei" ist. Wenn die Wikimedia-Software intern die Klasse selber verwendet (keine Ahnung, ob sie das tut), dann ist es okay, dann muss ein Skinentwickler das eh einbauen. --S.K. 17:34, 7. Aug. 2007 (CEST)

Das Standardverhalten ist ganz simpel: Es wird ein Fehlertext angezeigt. Die CSS-Klasse benutze ich, weil sie da ist und praktisch nichts kostet (die vorher verwendete Hintergrundfarbe war unpassend, weil sie für völlig andere Zwecke gedacht ist, nicht für Fehlermeldungen). Deine Anmerkung dazu ist richtig, müsste aber dort diskutiert werden, wo die Leute sitzen, die darauf Einfluss haben. --TM 18:17, 7. Aug. 2007 (CEST)

Da Common.css pro Installation anpassbar ist, werde ich die Diskussion erst einmal nach MediaWiki Diskussion:Common.css verlagern. Das man das dann grundsätzlich in die Default-Installation einbauen sollte, ist dann m.E. erst ein zweiter Schritt. --S.K. 19:58, 7. Aug. 2007 (CEST)

Wartungslisten mit der Vorlagenauswertung

Könnte man da vielleicht mal eine Auswertung in Bezug auf fehlende Eintragungen von Adresse, Bürgermeister, Vorwahl, PLZ u.a. machen? Bei den Gemeindeschlüsseln ging das ja auch. Gruß--Eigntlich (w) 09:46, 7. Aug. 2007 (CEST)

Wie wärs mit noch oft fehlendem in bei weiblichen Bürgermeistern? :-) (wegduck) Rauenstein 22:10, 29. Aug. 2007 (CEST)

Vielleicht gibt es ja tatsächlich ein Vornamensregister, auf das man irgendwie zugreifen könnte. Ein Ergebnis gäbe es sicherlich auch schon, wenn man nur nach Anna, Claudia, Marie, Lisa, Ulrike und weiteren geläufigen Vornamen im Parameter Bürgermeister abfragt (mehr unter [5])... @TM: Wäre das technisch möglich?--Eigntlich 22:39, 29. Aug. 2007 (CEST)

Ja, sicher (siehe oben). Übrigens, bevor jemand auf die Idee kommt, das zu ändern: Es ist vollkommen egal, ob man „Bürgermeisterin“ oder „[[Bürgermeister]]in“ schreibt. Wenn schon die längere Variante da steht, lasst sie stehen. --TM 23:03, 29. Aug. 2007 (CEST)

Bei Hameln, Engelstadt und Fußgönheim hat es schon was gebracht. staunend Rauenstein 03:53, 30. Aug. 2007 (CEST)

Die Bürgermeisterinnen haben ihr "in". --S.K. 14:23, 30. Aug. 2007 (CEST)

Ok, aber beachtet bitte, das wir momentan nur ein Duzend weibliche Vornamen kontrolliert haben. Das müsste man evtl. mit weiteren Vornamenslisten wiederholen. --TM 15:19, 30. Aug. 2007 (CEST)

KatBot Tour Ort in...

Der Benutzer:KatBot zieht gerade durchs Land und trägt in alle Gemeindeartikel die neue Kategorie Ort in... ein. Meine bescheidene Frage: Warum wird bitteschön für solche Aktionen nicht einfach die Infobox geändert, anstatt mit Tausenden von unsinngen Bearbeitungen die Beobachtungslisten zu zumüllen. Gerade für solche Aktionen wurde die Infobox eingeführt! Ein Klick und die Sache wäre erledigt. Oh Herr, schmeiß Hirn vom Himmel! --87.181.215.150 16:35, 11. Aug. 2007 (CEST)

Look at User talk:Eigntlich#Orts-Kategorien.--Eigntlich (w) 18:02, 11. Aug. 2007 (CEST)

Klappbare Infobox

Könnte man die Infoboxen nicht so gestalten, daß sie analog den Navigationsleisten oder wie beim Inhaltsverzeichnis eingeklappt oder verborgen werden können? Die Infobox nimmt auf vielen unglaublich viel Platz weg. 84.141.63.110 11:26, 15. Aug. 2007 (CEST)

Als Variante zum Alles-Wegklappvorschlag möchte ich vorschlagen, PLZ, PLZ-alt, Vorwahl, Kfz, Gemeindeschlüssel, NUTS, LOCODE hin- und wegklappen zu können. Damit wäre dann auch meinem Anliegen Rechnung getragen, die LOCODEs nicht zu verbergen (siehe [6]). Wem die dann zuviel sind, der klappt sie halt weg. Denkbar auch: Von vornherein alles obige weg, aber dazuklappbar im Sinne eines "mehr..." Links. Benjamin --141.30.183.142 18:45, 20. Aug. 2007 (CEST)

Ich habe eine kleine Skinmodifikation showInfoboxToggle zum Ein- und Ausklappen von Infoboxen geschrieben und bitte die interessierten Benutzer, sie zu testen und zu kritisieren. Funktioniert das Skript mit allen Infoboxen, mit denen es eurer Meinung nach funktionieren soll? (Soll es z. B. auch mit der Infobox Film funktionieren?) Soll es überhaupt anders funktionieren oder anders dargestellt werden? Gibt es Fehler? Gibt es vielleicht schon ein ähnliches Skript, das ich nur übersehen habe? --TM 18:28, 22. Aug. 2007 (CEST)

Teilweises Einklappen der Infobox

Hallo TM, zuerst mal vielen Dank und Anerkennung für Deine Programmiermühe! Ich nennen Deinen Entwurf jetzt mal »Nr.1«, um weiternummerieren zu können.

Auf dieser Diskussionsseite hatte ich ja bereits eine teilweise Klappbarkeit vorgeschlagen, um zugleich dem Relevanz-Disput gerecht zu werden. Leider bin ich nicht so JavaScript-fit, dass ich jetzt auf die Schnelle Gegenentwürfe basteln könnte, so dass Du Dir (und die Mitleser sich) unter dem folgenden http-realisierten Vorschlag sicher vorstellen können, was ich meine. Es sollte zur wirklichen Implementierung dann natürlich Script-basiert umgesetzt werden.

Der Einstieg in den Artikel »Bautzen« wäre dann folgender:

Entwurf Nr.2 - Mit Trennung in »Basisdaten« und »Schlüsseldaten«.

Die im-Landkreis-Grafik bleibt dabei im Gegensatz zu Deinem Vorschlag Nr. 1 erhalten. - Sie nimmt aber besonders viel Platz weg und sollte daher wohl wirklich mit weg um das Grundanliegen zu adressieren. Allerdings bin ich etwas sensibel für Hierarchiekonflikte (z.B. in Überschriften) und so stoße ich mich ein wenig daran, dass das Wegklappen der Basisdaten in Deinem Vorschlag Nr. 1 auch gleich die Lokalisierung im Landkreis mit wegklappt. Behoben habe ich das in dem folgenden weiteren Vorschlag, indem ich die Überschrift der Landkreislokalisierung Ihres Überschriftstatus enthoben und auf Layout-/Bedeutungs-Ebene der linken Spalte gesetzt habe (also nicht fett, nicht grau hinterlegt, aber ein Doppelpunkt danach). Außerdem habe ich in diesem Zusammenhang die Trennung der Daten umformuliert zu »Allgemeine Basisdaten« (statt »Basisdaten«) und »Weitere Basisdaten« (statt »Schlüsseldaten« + Landkreis-Einordnung).

Der Einstieg in den Artikel »Bautzen« wäre demnach - und das ist im Augenblick mein Favorit - der Folgende:

Entwurf Nr.3 - Mit Trennung in »Allgemeine Basisdaten« und »Weitere Basisdaten«.

Ferner halte ich die Begrifflichkeiten »Anzeigen« und »Verbergen« - in Analogie zum Inhaltsverzeichnis - für besser als die Klapp-Begriffe (sachlich zutreffender, »klappen« ist eher mechanisch, nicht elektronisch, einheitliche Begriffe für selbe Sachen i.S.v. KISS und Ausländerfreundlichkeit) . In meinen beiden Entwürfen habe ich daher diese verwendet.

Beste Grüße, Benjamin --141.30.207.240 01:19, 30. Aug. 2007 (CEST)

Dein Vorschlag verdient sicher Gehör (deshalb habe ich ihn hierher verschoben). Der Gedanke, unsere Infobox von vornherein für alle Leser einklappbar zu gestalten (unabhängig von der Frage, was konkret weggeklappt wird), ist tatsächlich verführerisch, hat aber auch entscheidende Nachteile. Vor allem, wenn ein Element beim Aufruf einer Seite standardmäßig unsichtbar ist, besteht die große Gefahr, dass es völlig übersehen wird. Das habe ich in der Praxis schon sehr häufig erfahren müssen, selbst wenn die Möglichkeit zum Ausklappen der versteckten Elemente meiner Meinung nach offensichtlich war. Die Benutzer haben es nicht gefunden. Das heißt, dass entweder

1. der Link zum Verbergen zu einer Spielerei degradiert wird, weil standardmäßig alles angezeigt wird und kaum ein Leser die Möglichkeit zum Verbergen nutzen wird, oder umgekehrt
2. die standardmäßig verborgenen Daten als bedeutungslos degradiert werden, da sie kaum ein Leser mehr wahrnehmen wird.

Meine Skinmodifikation vermeidet diese Probleme, da anonyme und unerfahrene Benutzer nicht damit verwirrt werden. Außerdem kommt noch das technische Problem hinzu, dass Vorlagen kein JavaScript enthalten dürfen und solche Links zum Einklappen nur mit unschönen Tricks möglich sind. So missbrauchen zum Beispiel manche Vorlagen die Einklapp-Funktion der Navigationsleisten, was ettliche Probleme verursacht (komplizierter Quelltext, hässliche grafische Darstellung, unkontrollierbares Standardverhalten, manchmal aufgeklappt, manchmal zugeklappt). KISS heißt für mich hier, die für den normalen Leser relevanten Daten immer anzuzeigen und auf die für ihn irrelevanten ganz zu verzichten. Jedenfalls, so lange keine benutzerfreundliche und technisch einwandfreie Methode existiert, Infoboxen einzuklappen. Die sortierbaren Tabellen sind ein wunderbares Beispiel, wie so etwas aussehen kann. Weder Leser noch Autoren werden mit der Sortierung konfrontiert, da sie keine Änderung des normalen Lese- und Schreibverhaltens erzwingt (Graceful degradation). Eine standardmäßig eingeklappte Infobox fordert dagegen vom Leser, sich mit der ungewohnten Funktion zu beschäftigen. --TM 21:45, 30. Aug. 2007 (CEST)

Leider bist Du auf meinen Entwurf Nr. 3 gar nicht eingegangen. Das Wort »Spielerei« akpeztiere ich allenfalls für Entwurf Nr. 2. Ich hatte aber ja geschrieben, dass Nr. 3 mein Favorit ist und Nr. 2 nur der Überschriftenlogik wegen entstanden ist (da Ausblendung von Kapitel III nicht Kapitel IV mit ausblenden sollte, wie es in Deinem Entwurf Nr. 1 geschieht). - Aber nun zur Sache: Ob es stanardmäßig angezeigt oder verborgen ist wäre mir egal. Meinetwegen ist es standardmäßig da (mein präferierter Entwurf Nr. 3) und kann über einen Eintrag im Monobook oder durch Klicken auf Verbergen weggemacht werden. Otthilde Normalsurfer braucht dann auch kein JavaScript um alles zu sehen, was ja auch KISS-entsprechender und barriereärmer ist. Jedenfalls sehe ich in der Verbergbarkeit von »Weitere Basisdaten« die Lösung zu unserem Relevanz-Disput um die Anzeige von NUTS und LOCODE unter dem von 84.141.63.110 eingebrachten Aspekt der »unglaublich viel Platz weg« nehmenden Infobox. Ohne den bekannten Disput hier weiterführen zu wollen, noch eine Anmerkung: Beim Bearbeiten des Bautzen-Beispiels sind mir durchaus Relevanz-Gedanken zu dieser Lage-im-Landkreis-Grafik gekommen, weshalb ich sie in die Verbergen-Lösung von Entwurf Nr. 3 mit integriert habe. Diese Grafik wäre übrigens zugleich ein potentielles Anwendungsfeld der LOCODEs. So bekämen die umgebenden Gemeinden ein die Grafik nicht überladendes und der Schriftgröße nach noch lesbares (international genormtes) Kürzel - vielleicht auch noch mit Ausschreibung des Gemeindenamens bei mouseover oder gar Wikilink - und man könnte sich auf diesen Karte eher orientieren (um nicht zu sagen, überhaupt etwas mit ihr anfangen). --141.30.183.142 17:53, 31. Aug. 2007 (CEST)

Infobox für ehemalige Ämter verwenden?

Liege ich richtig mit der Annahme, dass die Infobox nur für aktuell existierende Städte/Gemeinden/Ämter eingesetzt werden soll, und beispielsweise nicht für ehemalige Ämter, die im Zuge der Gemeindereform in NRW 1968–1975 aufgelöst wurden? Die Kategorisierung würde meinem Test zufolge keinen Sinn machen, da ein Artikel automatisch in die falsche und nicht existierende Kategorie:Amt in Nordrhein-Westfalen einsortiert würde. Also wahrscheinlich besser eine Tabelle verwenden wie z. B. bei Amt Schloß Neuhaus? Gruß, -- Zef 17:10, 25. Aug. 2007 (CEST)

Am besten gar keine Tabelle und alles im Fließtext beschreiben. Die Tabelle erweckt den falschen Eindruck, dass es sich um einen aktuell noch gültigen Teil der Verwaltungsstruktur handeln würde. --TM 22:39, 25. Aug. 2007 (CEST)

Zu überlegen wäre übrigens auch was wir mit den ganzen Gemeinden in Sachsen-Anhalt machen, die bis 2011 fast alle zu Einheitsgemeinden zusammengelegt werden. Vielleicht doch eine Extra-Infobox "ehemalige Gemeinde"? Die Informationen über Fläche, Postleitzahl usw. sollen schließlich nicht verloren gehen, aber es muss ja nicht gleich alles pauschal auf die Ortsteil-Infoboxen umgestellt werden, wo diese Gemeinden im Normalfall auch als Ortsbezirke mit eigenen Ortschaftsräten erhalten bleiben. Genauso wäre ein schlichtes Rauswerfen der Infobox bei den über 100 Verwaltungsgemeinschaften, die in Sachsen-Anhalt ebenfalls aufgelöst werden, m.E. nicht zielführend.--Eigntlich (w) 22:44, 25. Aug. 2007 (CEST)

Mein bescheidener Kommentar: Wieso die Box nicht so gestalten, dass eine Verwendung der Box auch für Ortschaften und ehemalige Ämter nutzbar ist. Unter dem derzeitigen Lemma ist die einschränkende Verwendung ausschließlich für Gemeinden halt missverständlich. --SteveK ?! 23:04, 25. Aug. 2007 (CEST)

Moin, halte ich nicht so viel von. Ich halte es so, dass ich den Inhalt der Infobox frei formuliere und die Zahlen runde ("… knapp 7000 Einwohner und eine Fläche von rund 65 km² …"). Anschrift der Verwaltung, Webpräsenz, Amtsvorsteher usw. sind eh' uninteressant. Siehe Amt Osterrönfeld, Amt Fehmarn oder Amt Segeberg-Land.

Finde ich ehrlich gesagt die falsche Lösung. Genaue Angaben sind immer noch die besten, und es reicht ja aus, die letzten verfügbaren Daten vor der Auflösung des Amtes zu verwenden. Dass du nun Verwaltung, Amtsvorsteher etc. uninteressant findest, bezieht sich aber nicht nur auf etwaige Infoboxen für ehemalige Gemeinden, und bei denen wurde das halt anders entschieden. OK, ehemalige Website kann natürlich weg, aber die anderen Daten (EW-Zahl und Fläche, Bevölkerungsdichte, Kreiszugehörigkeit vor Auflösung) sind auch für ehemalige Verwaltungseinheiten wertvoll. Zumindest wenn auf einen Schlag 150 Verwaltungsgemeinschaften (wie in Sachsen-Anhalt) aufgelöst werden, gingen sonst wichtige Informationen in großem Umfang verloren.--Eigntlich (w) 13:44, 26. Aug. 2007 (CEST)

Ok, ich habe einen ganz konkreten Vorschlag: Wie wäre es, beim Parameter „Art“ weitere Werte für solche Fälle zu erlauben? Art = ehemalige Gemeinde, Art = ehemaliges Amt, Art = ehemalige Samtgemeinde usw. In diesem Fall würde die Vorlage die automatische Kategorisierung weglassen und auch sonst könnte man sich überlegen, die Information „ehemalig“ irgendwie in die Infobox einfließen zu lassen. Müsste man das auch für andere Arten ehemaliger Verbände ermöglichen und wenn ja, für welche? Gibt es auch „ehemalige Städte“? --TM 20:34, 26. Aug. 2007 (CEST)

Naja, so pauschal würde ich das nicht tun, eher regional und nach Art der Verwaltungseinheit beschränkt. Schließlich gibt es dann auch noch den Konflikt mit der Vorlage:Infobox Ortsteil einer Gemeinde und zusätzlich könnte man diese Infobox per Definition in alle Artikel über Ortschaften einbauen, die einmal eine eigene Gemeinde waren, und das sind bekanntlich tausende. Für ehemalige Verwaltungsgemeinschaften fände ich den weitestgehenden Erhalt der Infobox persönlich schon sinnvoll. Inwieweit z.B. die Infoboxen für die bei der Gemeindegebietsreform in Sachsen-Anhalt (die ab Mitte d.J. beginnt) aufgelösten Gemeinden umgewandelt werden sollten, wäre noch zu klären. Das hängt auch davon ab, ob die Gemeinde als administrative Untergliederung mit festen Grenzen bestehen bleibt oder nicht. Grundsätzlich gilt sicherlich, dass man den Ist-Zustand abbilden sollte, also den Zustand beispielsweise als Ortsbezirk innerhalb einer neuen Einheitsgemeinde und nicht als ehemalige Gemeinde. Am unkompliziertesten ist es vorläufig und zumindest für die aufgelösten Ämter in Schleswig-Holstein, die Infobox einfach in die frühere, nicht vorlagengebundene Tabellensyntay umzuwandeln.--Eigntlich 20:47, 26. Aug. 2007 (CEST)

Kleine Meinungsumfrage zur Problematik „Ehemalige“

Vorschlag 1: Die Infobox soll für ehemalige Ämter, Samtgemeinden etc. zugelassen werden, aber nicht für ehemalige Gemeinden

Vorteil: Mit Bots und der Vorlagenauswertung kann das sehr leicht gewartet werden. Die Anzeige lässt sich auch nachträglich einheitlich modifizieren. Nachteil: Die Infobox erweckt den falschen ersten Eindruck, das Amt würde noch existieren. Die Vorlage verführt dazu, sie auch bei ehemaligen Gemeinden einzusetzen.

Vorschlag 2: Die Infobox soll bei ehemaligen Ämtern, Samtgemeinden etc. als Tabelle (per subst:) eingesetzt werden

Vorteil: Die Artikel sind von der Vorlage völlig unabhängig. Nachteil: Die Tabelle erweckt den falschen ersten Eindruck, das Amt würde noch existieren. Es ist unmöglich, einheitlich Änderungen vorzunehmen. Es wäre technisch ein Rückschritt.

Vorschlag 3: Ehemalige Ämter, Samtgemeinden etc. sollen gar keine Infobox erhalten, auch nicht als Tabelle

Vorteil: Man sieht auf den ersten Blick, dass es sich um ein ehemaliges Amt handelt. Die rechte Seite kann besser für Bilder genutzt werden. Nachteil: Man muss alle Daten in den Fließtext einbauen.

1. TM 10:29, 28. Aug. 2007 (CEST) Ämter haben oft keine Wappen, so dass die Infobox ohnehin nicht schön aussehen würde. Die vergleichsweise wenigen Daten kann man problemlos in den Text einbauen. Die Deutschlandkarte mit dem roten Punkt sollte man ganz weg lassen. Die herkömliche {{Koordinate Text|…}} genügt.
2. auf keinen Fall - das konterkariert den Wiedererkennungswert der Städte- und Gemeindeartikel. Selbst bei aktuellen Samtgemeinden, Ämtern, VG usw. hatte ich immer Bedenken, die Infobox einzuführen (hunderte dieser Teile haben ja bis heute keine) Rauenstein 10:53, 28. Aug. 2007 (CEST)
3. Die Stimmabgabe verwundert jetzt vielleicht etwas. Ich dachte bei einer Erhaltung bzw. Umwandlung der Infobox vorrangig an die 94 Verwaltungsgemeinschaften in Sachsen-Anhalt, bei denen dann nach Auflösung sämtliche Infoboxen auf einen Schlag entfernt worden wären. Hierbei handelt es sich auch um eine vollständige Auslöschung einer bestimmten Art von Gebietskörperschaft und nicht nur eine Zusammenlegung. Wenn die VGen in SA aber weitestgehend in Einheitsgemeinden umgewandelt werden, hat sich das nun erübrigt. Am wichtigsten ist auf jeden Fall, dass allgemein bei der Auflösung von Gebietskörperschaften alle Infos mit wenigen Ausnahmen auch in den Fließtext eingebaut werden.--Eigntlich 14:33, 28. Aug. 2007 (CEST)
4. Zustimmung. --ClausG 17:24, 28. Aug. 2007 (CEST)
5. Derzeit praktiziert und so i.O. --Alma 20:45, 28. Aug. 2007 (CEST)

Bundeslandspezifische Gebietsschlüssel bei Gemeindeverbänden

Vor einigen Tagen gab es mal irgendwo eine Diskussion, ob man nicht auch die Gebietsschlüssel auf Landesebene in die Infoboxen zu den Verbandsgemeinden, Samtgemeinden, Ämtern usw. einbauen sollte, da dies für die botgestützte Aktualisierung von Daten hilfreich wäre. Man könnte ja einen zusätzlichen Parameter "Gebietsschlüssel" o.ä. einführen und den dann ähnlich wie NUTS standardmäßig ausblenden. Ich sehe da kein Problem bei.--Eigntlich 20:47, 26. Aug. 2007 (CEST)

Es wäre sicher sinnvoll, etwas in dieser Art standardisiert in die Vorlagendokumentation aufzunehmen, aber zuerst sollten wir unbedingt zusammenstellen, welche Bundesländer das betrifft, wie die Nummerierungen jeweils genannt werden, wie die Nummern aufgebaut sind etc. Dann müssten wir uns auf Parameternamen (idealerweise nur einen einzigen für die Verbände, zum Beispiel „Verbandsschlüssel“) einigen und auch darüber, ob das angezeigt werden soll oder nicht.

1. In Brandenburg heißt das verwirrenderweise „Gemeindeschlüssel“ und hat 10 Stellen (Beispiel).
2. In Rheinland-Pfalz heißt das „Gebietsschlüssel“ und hat 10 Stellen (alte Diskussion).
3. In Schleswig-Holstein heißt das „Ämterschlüssel“ und hat 4 Stellen (alte Diskussion, Quelle). --TM 09:12, 27. Aug. 2007 (CEST)

Ein nettes Detail am Rande: Seit gestern gibt es auf den Seiten des Landes Brandenburg überall Links zu den Wikipedia-Artikeln der Städte und Gemeinden (hier zum Beispiel zur Landeshauptstadt Potsdam). --TM 15:19, 30. Aug. 2007 (CEST)

Landesämter als Referenzen

man koennte vielleicht automatisch die jeweils zustaendigen Landesaemter als Referenzen fuer die Einwohnerzahlen angeben. Das wuerde vielleicht auch dabei helfen, dass Leute Zahlen aus anderen Quellen hier eingeben.--LugPaj 14:15, 29. Aug. 2007 (CEST)

Wie meinst du das? Wir waren uns eigentlich einig, gerade keine anderen Quellen neben den Statistischen Landesämtern zuzulassen. Eine automatische Referenzierung fände ich gut, allerdings kann ich mir im Moment nicht so recht vorstellen, wie das aussehen soll. Sollte die Referenz zu einem Weblink führen und wenn ja, zu welchem? Willst du, dass die Vorlage automatisch zum Beispiel den Quelltext

<ref name="Einwohnerzahl">[http://www.statistik.sachsen.de/21/02_02/02_02_tabellenliste.asp
Statistisches Landesamt des Freistaates Sachsen]. 31. Dez. 2006.</ref>

ergänzt, der dann am Ende des Artikels in den <references /> (sofern vorhanden) auftaucht? Das fände ich gut, aber dazu müsstet ihr mir bitte helfen, zuerst eine Liste mit den 16 dazu benötigten Referenzen anzulegen. Für Sachsen würde ich das wie gesagt wie oben zu sehen machen.

Nachteil: Wenn im Artikel sonst keine Referenzen sind, steht in unserer Infobox eine kleine [1], aber die führt nirgends hin. Siehe Bug 5492 vom April 2006 (Referenzen werden nicht automatisch angezeigt, wenn das Element <references /> fehlt) und Bug 8693 vom Januar 2007 (Referenzen, die aus Vorlagen kommen, werden nicht angezeigt). Das heißt für uns: Gute Idee, aber zur Zeit technisch nicht möglich.

Alternative: Wir verwenden vorläufig (so lange diese Bugs nicht behoben sind) nicht die ref-Syntax sondern setzen selbst einen kleinen Link ein, zum Beispiel als 12.590^[7] (31. Dez. 2006) oder indem einfach das Datum als Weblink verwendet wird. --TM 16:32, 29. Aug. 2007 (CEST)