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, Gemeindefreies Gebiet, Amt, Gemeindeverwaltungsverband, Samtgemeinde, Verbandsgemeinde, Verwaltungsgemeinschaft, Verwaltungsverband. Bei Gemeinden bitte weglassen.

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:Gemeinde 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

• Falsche „Führt kein Wappen“. Bitte kurz „kein“ eintragen.
• Falsche Verbandszuordnungen. Bei Verwaltungsgemeinschaften die Vorlagenzeilen Amt = usw. unbedingt weglassen.
• Falsches Datumsformat beim Stand der Einwohnerzahl.
• Verbände mit ausgefüllten Postleitzahlen und ausgefüllten Vorwahlen. Die Zeilen bitte weglassen, da die Aufzählung sämtlicher Postleitzahlen und Vorwahlen in einem Verbandsgebiet niemandem nützt.
• Fehlende Adressen. Für die drei Parameter gilt folgende Rangfolge. Das heißt, wenn mehrere Parameter ausgefüllt sind, wird nur der mit der höchsten Priorität angezeigt.
  1. Adresse
  2. Straße
  3. Adresse-Verband

Wartungslisten mit Hilfe des Projekts Vorlagenauswertung

Leere Vorlagenparameter (ganz fehlende Vorlagenzeilen werden nicht gefunden)

• Leere Koordinaten.  Ok 24. Sep. 2007
• Leere Höhen.  Ok (alle außer Verbandsgemeinden, Ämter und Samtgemeinden) 18. Sep. 2007
• Leere Flächen.  Ok 4. Sep. 2007
• Leere Einwohnerzahlen.  Ok 7. Aug. 2007
• Leere Postleitzahlen.  Ok (alle außer Verbandsgemeinden, Ämter und Samtgemeinden) 7. Aug. 2007
• Leere Vorwahlen.  Ok (alle außer Verbandsgemeinden, Ämter und Samtgemeinden) 5. Sep. 2007
• Leere Gemeindeschlüssel. Muss bei manchen Verwaltungsverbänden leer bleiben.  Ok 9. Jul. 2007
• Leere Bürgermeister.  Ok (bis auf einige Gemeinden des Amt Uecker-Randow-Tal) 29. Aug. 2007

Fehlende Vorlagenparameter

• Fehlender Breitengrad  Ok 24. Sep. 2007
• Fehlender Längengrad  Ok 24. Sep. 2007
• Fehlende Einwohner  Ok 24. Sep. 2007
• Fehlende Fäche  Ok 24. Sep. 2007
• Fehlender Bürgermeister
• Fehlende Partei

Sonstiges

• Ungültige Art. Bei Gemeinden ganz weglassen.  Ok 31. Aug. 2007
• 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
• Unnötige Anzeige von „Landkreis: Landkreis Musterstadt“ und „Kreis: Kreis Musterstadt“.  Ok 24. Sep. 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
• Unerwünschtes HTML im Kfz-Kennzeichen.  Ok 4. Sep. 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
• Adressen von „Gemeindebüros“. Bitte die Adresse des tatsächlichen Sitzes der Verwaltung eintragen.
• Bürgermeister, die mit Vornamen „Herr“ heißen. Möglichst auch in allen anderen Wikipedias korrigieren.  Ok (nur 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)

Oben war der Punkt "Fehlende Adressen" als erledigt gekennzeichnet. Habe gerade bei Estorf die Adresse eingefügt (sicher kein Einzelfall). Des Weiteren findet man noch sehr oft als Angabe: Bürgerbüro - Ortsname - was natürlich nicht den Realitäten entspricht. Hier sollte dann unter "Adresse-Verband" die Samtgemeinde- Amts- oder Verwaltungsgemeinschaftsadresse stehen. Rauenstein 03:01, 4. Sep. 2007 (CEST)

Ich hatte alle durch den obigen Link gefundenen Artikel ergänzt, es scheint aber so, dass der Ausdruck nicht alle Artikel findet. Wenn ich die Zeit finde, schaue ich mir den Ausdruck einmal an, sofern Thiemo nicht schneller ist. --S.K. 11:12, 4. Sep. 2007 (CEST)

So wird es wohl sein, ohne Adressen auch Raddestorf, Balge, Hassel (Weser). In Stöckse dazu fehlende Vorwahl. Rauenstein 16:27, 4. Sep. 2007 (CEST)

Die Vorlagenauswertung findet leider nur Parameter, die leer sind, aber keine, bei denen die Zeile komplett fehlt. Ich werde mal nachfragen, ob sich da etwas machen lässt. --TM 18:21, 4. Sep. 2007 (CEST)

Es scheint sogar noch Gemeinden zu geben, wo in der Infobox die Koordinaten fehlen (jüngst bei Isernhagen entdeckt). Vielleicht lohnt sich da ja auch mal ne Abfrage. Gruß--Eigntlich 22:09, 23. Sep. 2007 (CEST)

War manuell entfernt worden. Rauenstein 13:48, 24. Sep. 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). Benjamin --141.30.183.142 17:53, 31. Aug. 2007 (CEST)

Auswirkungen auf und Zukunft der Lage-im-Kreis-Karten

Ein Argument gegen die Einklappbarkeit der Infobox wäre, dass sich alle nachfolgenden Bilder z.T. so verschieben, dass große weiße Lücken entstehen, wie man es z.B. beim Einklappen des Inhaltsverzeichnisses sieht (Plauen, Leipzig usw.).

Eine Beschriftung der Karten ergibt nur einen Sinn, wenn es sich um frei skalierbare Formate handelt - und die sind mittelfristig bei der Masse noch nicht in Sicht. Ich habe bei 2000 erstellten Kartenskizzen zur besseren Orientierung nur die Gewässer mit eingebaut. Da es inzwischen die verschiedensten Lagekartentypen gibt, mal die Frage nach der Höhe der Karten im eingebauten Boxfenster: Wenn man beim png-Format der Skizzen auch innerhalb der festen Boxbreite bleibt (um solche Ansichten zu vermeiden), scheint die Höhe aber festzustehen. Es kommt dabei immer (bleiben wir bei der Infobox Röbel/Müritz) zu Verzerrungen. Ich gehe mal davon aus, dass es ein festes Verhältnis Höhe zu Breite gibt, bei Lübben (Spreewald) ist die Skizze in der Infobox länger gezogen als in der Kartenskizze selbst. Da die Landkreise nur in Ausnahmefällen eine "quadratische" Form haben, sollte sich die Höhe des Fensters vielleicht an die jeweilige Karte anpassen. Falls dies unmöglich/unerwünscht ist, bleibt immernoch die Möglichkeit wie bei Rathenow die Skizze außerhalb der Box zu zeigen. Rauenstein 20:43, 31. Aug. 2007 (CEST)

@Rauenstein: Ich verstehe nicht ganz, worauf du mit den beispielhaft genannten Artikeln hinweisen willst. Plauen hat ein Problem mit einem überbreiten Panoramafoto. Leipzig hat ein Problem mit zu vielen Bildern und einer viel zu langen Infobox (da stehen viel zu viel Daten drin, die in den Fließtext gehören). Beides provoziert Darstellungsfehler (weiße Lücken und nach unten verschobene Bilder). Aber keines dieser Probleme hat etwas mit dem Einklappen von Infoboxen zu tun. Beim Einklappen geht es einfach darum, dem Leser eine Wahl zu lassen, die er jetzt nicht hat.

Was am Artikel nl:Oranienburg falsch sein soll, verstehe ich nicht. Sowohl in der niederländischen als auch in unserer Infobox hier ist es momentan so, dass Kartenbilder nicht nur in der Breite sondern auch in der Höhe begrenzt werden. Das ist notwendig, weil es teilweise Lagepläne gibt, die doppelt so hoch wie breit sind. Diese würden ohne diese Begrenzung extrem groß erscheinen und die Infobox unverhältnismäßig nach unten verlängern.

Grundsätzlich möchte ich festhalten, dass es falsch ist, Bilder in einer ganz bestimmten Größe zu erstellen. Niemand weiß, ob die Wappen immer 140 × 175 Pixel und die Lagepläne immer 299 × 299 Pixel groß dargestellt werden. Das kann sich von heute auf morgen ändern, wenn es für sinnvoll erachtet wird. Diskussionen zu diesem Thema wurden bereits geführt (siehe oben). Meine empfohlene Vorgehensweise ist, Wappen und Lagepläne möglichst hochauflösend zu erstellen (zum Beispiel 600 Pixel breit). Damit die Karten auch in verkleinerter Form noch gut aussehen, sollten alle Grenzlinien etwas dicker gezeichnet sein (zum Beispiel so).

Leider existiert momentan keine Möglichkeit, Bilder so einzubinden, dass sie wenn nötig verkleinert aber nicht vergrößert werden. Da das bei den Wappen relativ oft zu wirklich hässlichen Pixelhaufen führte, haben wir als Notlösung den an sich überflüssigen Parameter „Wappengröße“ eingeführt. Bei den Lageplänen kommt ein solcher Parameter meiner Meinung nach jedoch nicht in Frage, da er vieles verkomplizieren würde, aber nur in ganz wenigen Ausnahmefällen gebraucht würde. Die Lösung ist einfach die, beim Erstellen der Lagepläne darauf zu achten, dass sie entweder mindestens 299 Pixel breit oder mindestens 299 Pixel hoch sind (ideal wäre wie gesagt das Doppelte, also ungefähr 600 Pixel). --TM 19:51, 4. Sep. 2007 (CEST)

Da kann man wohl nichts machen. Leider bestanden ca. 1700 Lagekarten schon vor der Einführung der Infobox mit dem neu geschaffenen Fenster (das sind über 10 % des Artikelbestandes). Bleibt also nur das Herausnehmen, um Verzerrungen zu vermeiden. gruss Rauenstein 21:06, 4. Sep. 2007 (CEST)

Ich überlege schon eine Weile, die Lageplänen, die jetzt als Tabellenzeile unten an die Infobox angesetzt werden, statt dessen als ganz normales Bild unter der Infobox anzeigen zu lassen, so wie zum Beispiel im Artikel Rathenow (allerdings nicht so groß sondern als normales thumb). Das geht ganz einfach durch eine sehr simple Umstellung der Vorlage. Es müsste an keinem Artikel etwas geändert werden. Der größte Vorteile wäre, dass die Infoboxen dann deutlich kürzer wären. Sie wären viel besser handhabbar und man müsste sie vielleicht gar nicht mehr einklappen. Weiterer Vorteil wäre, dass normale thumb-Bilder am besten zu handhaben sind. Sie passen sich an die Einstellung des Benutzers an. Als thumb würde der Lageplan auch besser zu den anderen thumbs auf der Seite passen und sich nicht mehr so in den Vordergrund drängen, wie es jetzt leider der Fall ist. Was meint ihr zu dieser Idee? --TM 21:13, 5. Sep. 2007 (CEST)

Vor Einführung der Infobox waren die Kartenskizzen unter der Gemeindebox, manchmal am Artikelende oder auch links in der Mitte, aber nicht etwa kleiner, wie Du nun vorschlägst, sondern in Originalgröße. Die Infobox hat diese Teile ja durch Höhen- und Breitenzwang erst so verschwimmen lassen (egal, ob bei Mayen, Montabaur, Plön, Stendal, Neckarwestheim - sie sehen immer gestaucht aus. Die kleineren wie in Röbel/Müritz haben dagegen Zerrstellen. Beim Erstellen weiß ja niemand, wie breit die Infoboxen in einem halben Jahr sein werden :-). "Normales thumb" mag bei Fotos gelten, bei Grafiken häufig indiskutabel (wie etwa bei diesem). Meinetwegen können die Karten sonstwo im Artikel stehen, nur nicht als kleines verwaschenes Bildchen in einer noch schmaleren Infobox (man soll die Lage ja in einer Lagekarte gleich erkennen können) oder als "Normalthumb" am Ende derselben. In diesen Fällen würde ich sie komplett aus der Box verbannen. Rauenstein 09:07, 6. Sep. 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 Weblinks anzulegen. Für Sachsen würde ich wie gesagt den obigen verwenden.

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 Weblink ein. Folgende Möglichkeiten würde ich vorschlagen:

1. 12.590^[1] (31. Dez. 2006)
2. 12.590 (31. Dez. 2006)^[1]
3. 12.590 (31. Dez. 2006)

--TM 22:45, 9. Sep. 2007 (CEST)

Ich würde den ersten oder zweiten Vorschlag verwenden. (Optisch sieht Vorschlag 1 besser aus, im Kontext passt Vorschlag 2 jedoch besser.) Die hochgestellten Zahlen dürften als Fußnote bekannt sein. Das Datum fand ich anfangs interessent, wenn ich es jetzt aber als Plainlink formatiert sehe, halte ich es (ohne mit dem Mauszeiger drüber zu fahren) für einen Wikilink auf einen Datumsartikel.

Wie würde das eigentlich in einem Artikel aussehen? (Stichwort Laufnummer) --32X 23:41, 9. Sep. 2007 (CEST)

Hallo Leute! In diesem Fall dient die Quellenangabe nicht nur zur Nachprüfbarkeit durch andere Autoren, sondern auch, um dem Leser zu vermitteln, welche Zahl es eigentlich sein soll. Einwohnerzahlen sind eben nicht gleich Einwohnerzahlen; schließlich unterscheidet sich die Zahl aus dem Melderegister ja stets von den Angaben des Statistischen Landesamtes.

Ich sehe gerade erst den Vorteil (LugPaj hat ihn ja erwähnt), dass eine für Leser sichtbare Quellenangabe für die Einwohnerzahlen tatsächlich dagegen helfen könnte, dass ständig Leute nach anderen Quellen Einwohnerzahlen ändern...

Mir persönlich kommt es momentan am sinnvollsten vor, in der Vorlage den Text „Einwohner:“ durch „Einwohner laut Statistischem Landesamt“ zu ersetzen. Natürlich könnte man auch eine Fußnote mit dem Inhalt nehmen, dass die Einwohnerzahl die laut Statistischem Landesamt ist. Dafür fände ich von den drei vorgeschlagenen die 1. Variante am schönsten und die 2. am zweitschönsten. MfG Stefan Knauf 00:44, 10. Sep. 2007 (CEST)

@32X: Da die Vorlage immer ganz vorn im Artikelquelltext steht, würde dieser kleine Weblink immer als [1] angezeigt werden. --TM 12:45, 10. Sep. 2007 (CEST)

Bundesland	Deep Link zu den Einwohnerzahlen beim Statistischen Landesamt
Baden-Württemberg	http://www.statistik.baden-wuerttemberg.de/SRDB/home.asp?H=BevoelkGebiet&U=02
Bayern	http://
Berlin	http://
Brandenburg	http://
Bremen	http://
Hamburg	http://
Hessen	http://
Mecklenburg-Vorpommern	http://
Niedersachsen	http://
Nordrhein-Westfalen	http://www.lds.nrw.de/statistik/datenangebot/regionen/amtlichebevoelkerungszahlen/index.html (genauer geht es wohl nur, wenn man nach Regierungsbezirken unterteilt)
Rheinland-Pfalz	http://
Saarland	http://
Sachsen	http://www.statistik.sachsen.de/21/02_02/02_02_tabellenliste.asp
Sachsen-Anhalt	http://
Schleswig-Holstein	http://
Thüringen	http://www.statistik.thueringen.de/datenbank/Tabanzeige.asp?tabelle=gg000102&nr=99

Da die Einwohnerzahl-Referenzen in den Stadt- und Gemeindeartikeln bei Einführung der Infobox vom Bot überbügelt wurden, würde ich die Einführung eines ref-Links begrüßen. Alle ein bis zwei Wochen fügt jemand eine falsche Zahl in die von mir beobachteten Stadt- , Gemeinde- und Kreisartikel (ca. 80) ein, was dadurch hoffentlich unterbunden würde. Vorschlag 2 (im Abschnitt Alternative) gefällt mir am besten. -- Zef 21:10, 22. Sep. 2007 (CEST)

Da Siebrands Bot derzeit eh eine Menge vo-Links nachträgt, könnte man ihm auch gleich den Auftrag geben, die reference-Tags nachzutragen (oder mit seiner Aktualisierung abzuwarten). Es müssen nicht alle Ortsartikel x-fach wegen kleiner Änderungen durchgepflügt werden. --32X 21:42, 22. Sep. 2007 (CEST)

Ausgehend von der Annahme, dass es genau einen, immer gleichen Link pro Bundesland gibt, könnte man diese Links in die Infobox einbauen, ohne dass die Artikel editiert werden müssen. Nach dem Schema: Wenn Bundesland=Hessen, dann füge in die Infobox einen Link auf die Datenquelle für Hessen ein. -- Zef 22:00, 22. Sep. 2007 (CEST)

Siehe Stichpunkt Nachteil. --32X 23:10, 22. Sep. 2007 (CEST)

Und an welcher Stelle soll der Bot das <ref>-Tag eintragen? Aufgrund des oben beschriebenen Mediawiki-Bugs wäre ein Vorlagenparameter Einzelnachweis = <ref>…</ref> erforderlich. Aber auch damit bleibt noch das Problem, dass dieser Einzelnachweis ohne ein <references /> im Artikel nirgends sichtbar ist. Wie man es dreht und wendet: Ein normaler Weblink, den die Vorlage selbständig einsetzt (anhand des Parameters Bundesland und evtl. Regierungsbezirk), scheint mir die beste Lösung zu sein. Was sind übrigens „vo-Links“? --TM 12:41, 23. Sep. 2007 (CEST)

Mit „vo-Links“ sind wohl Volapük-Interwikilinks gemeint, die SieBot massenhaft einfügt. -- Zef 13:10, 23. Sep. 2007 (CEST)

… und die mittlerweile einen Antrag auf Schließung der Volapük-Wikipedia ausgelöst haben, siehe WP:FZW#Volapük. --Rosenzweig δ 13:13, 23. Sep. 2007 (CEST)

Der Bot soll keine ref- sondern reference-Tags einfügen, praktischerweise so, wie es die entsprechende Formatvorlage vorschlägt. --32X 17:50, 23. Sep. 2007 (CEST)

Ich verstehe immer noch nicht. Bug 8693 verhindert, dass Referenzen aus Vorlagen angezeigt werden. Da würde auch das massenhafte Einfügen des Tags <references /> nichts helfen. Ich denke auch, dass es ziemlich sinnlos wäre, wenn in allen 13.000 Ortsartikeln plötzlich ein Abschnitt „Fußnoten“ auftauchen würde, der nichts weiter enthält als den immer gleichen Weblink auf das Statistische Landesamt. --TM 19:47, 23. Sep. 2007 (CEST)

In Benutzer:32X/Gerd Schröder wird die manuell angelegte Fußnote in der Infobox angezeigt. Ist die von dir angestrebte Syntax so viel anders? --32X 19:50, 23. Sep. 2007 (CEST)

Ja, darum geht es mir doch. In deinem Beispiel steht das <ref>-Tag im Artikel. Ich will aber nicht, dass in 13.000 Ortsartikel 13.000 mal ein <ref>- und 13.000 mal ein <references />-Tag eingefügt werden muss. Ich will das vollautomatisch mit Hilfe der Vorlagenprogrammierung machen. Und das geht zur Zeit nicht mit der REF-Syntax sondern nur mit einem Weblink. --TM 20:32, 23. Sep. 2007 (CEST)

Einbindung von Imagemaps

Geisterbob hat für den Landkreis Börde eine Imagemap erstellt (Vorlage:Imagemap Calvörde in BK), in der man die einzelnen Gemeinden des Landkreises anklicken kann. Leider kriegt man das Ding nur mit einem hässlichen Nebeneffekt in die Infobox (Parameter Lageplan) gesetzt. Die Vorlage erwartet wohl ein Bild, keine Vorlage. Kann man das irgendwie abstellen?--Eigntlich 01:15, 10. Sep. 2007 (CEST)

Nein, so etwas ist zur Zeit einfach noch nicht sinnvoll. Die Imagemap-Erweiterung hat einen schwerwiegenden Bug, der es unmöglich macht, Vorlagenparameter innerhalb der Imagemap-Syntax zu verwenden. Das bedeutet, es ist unmöglich, eine Vorlagen für den Landkreis zu erstellen und das Bild mit der hervorgehobenen Gemeinde mittels eines Parameters auszutauschen. Zur Zeit wäre es zwingend erforderlich, für jeden der rund 12.000 Lagepläne genauso viele Vorlagen anzulegen. Das wäre Wahnsinn. Zuerst muss der Bug behoben sein, dann können wir sehr gern eine entsprechende Funktion in die Infobox einbauen. --TM 12:06, 10. Sep. 2007 (CEST)

Vorlage:Infobox Landkreis

Nach dem Erfolg der Vorlage:Infobox Ort in Deutschland habe ich jetzt eine identische Vorlage:Infobox Landkreis erstellt. Ich bitte alle Interessierten, die neue Vorlage zu testen und mir bei der Verbesserung zu helfen. Besonders Landkreise mit verrückten Namen, die nicht dem Schema „Landkreis Musterstadt“ entsprechen, bereiten mir noch Sorgen.

Bitte dort diskutieren. --TM 19:36, 13. Sep. 2007 (CEST)

Samtgemeinden/Verwaltungsgemeinschaften ohne Infobox

CatScan liefert noch einige Samtgemeinden und Verwaltungsgemeinschaften ohne Infobox. Gibt es Gründe dort die Infobox nicht einzusetzen (bis auf Ausnahmen wie ehemalige Samtgemeinden, etc.)? Bei den Ämtern und Verbandsgemeinden habe ich die Boxen soweit sinnvoll schon von Hand eingebaut, aber vielleicht könnte Reinhard für den Rest noch einmal den Bot anwerfen? --S.K. 16:28, 20. Sep. 2007 (CEST)

Nun ja. Eigentlich besteht kein Grund, den Kasten unbedingt in alle Artikel einzubauen. Für Infoboxen besteht ja nicht der selbe Zwang wie für Kategorien. Falsch wäre die Infobox natürlich nicht. Vielleicht sollten wir sie aber vorher in „Infobox Verwaltungseinheit in Deutschland“ umbenennen? --TM 17:01, 20. Sep. 2007 (CEST)

Okay, natürlich besteht kein Zwang, aber speziell mit deinen Änderungen zur Barrierefreiheit und den obigen Wartungsmöglichkeiten via des Projekts Vorlagenauswertung tendiere ich standardmäßig eher zur Verwendung der Vorlage als zur Nichtverwendung. Die meisten der Samtgemeinden/Verwaltungsgemeinschaften die ich mir exemplarisch angesehen habe, haben ja schon irgendeine Infobox. Von daher, dann lieber "The real thing" via Vorlage. ;-)
Bezüglich des Namens: Ja, würde ich im Prinzip unterstützen. Macht es klarer, wofür die Vorlage wirklich eingesetzt wird. Wobei wenn wir schon am Ändern sind, ich am überlegen bin, ob man die Vorlage nicht in zwei aufteilt: Infobox Gemeinde in Deutschland und Infobox Verwaltungsgemeinschaft in Deutschland. Gerade bei der Wartung bin ich immer wieder auf Fälle gestoßen, bei denen für die Verwaltungsgemeinschaften einfach kein sinnvoller Parameter gefunden werden kann. Als Beispiele:

• Gemeindeschlüssel oft anders aufgebaut
• Höhen nicht sinnvoll definiert
• PLZ und Vorwahlen werden oft zu ziemlich langen Listen, wenn man die Vereinigungsmenge über alle Gemeindewerte bildet
• Die Parameter Amt|Gemeindeverwaltungsverband|Samtgemeinde|Verbandsgemeinde|Verwaltungsgemeinschaft|Verwaltungsverband und Adresse-Verband sind für die Verwaltungsgemeinschaften überflüssig, werden aber mitunter trotzdem gesetzt.

Von daher wären die Vorteile spezialisierter Vorlagen gegenüber dem Aufwand, zwei Vorlagen warten zu müssen abzuwägen. --S.K. 18:19, 20. Sep. 2007 (CEST)

Dazwischengequetscht: Das sind wirklich nützliche Hinweise. Ich habe einen Teil davon sofort umgesetzt: Jetzt erscheint eine Fehlermeldung (einschließlich eines Eintrags in der jeweiligen Wartungsliste), wenn bei Verbandsartikeln ein unerwünschter Parameter ausgefüllt wird. Das betrifft auch die Parameter PLZ und Vorwahl, da die dort oft zu sehenden kommagetrennten Aufzählungen völlig sinnbefreit sind und niemandem nützen. --TM 17:54, 24. Sep. 2007 (CEST)

Die Ämter in Schleswig-Holstein und in Meck-Pomm, die Verwaltungsgemeinschaften in Sachsen-Anhalt und die Verbandsgemeinden in Rheinland-Pfalz sind mittlerweile fast vollständig mit Infoboxen ausgestattet. Für Thüringen, Bayern und Niedersachsen sieht das schon erheblich anders aus. Trotzdem sollte bald eine Umbenennung der Box erfolgen, da es immer wieder zur Zweckentfremdung der Box für einfache Orte kommt. Der Name Infobox Ort in Deutschland ist eigentlich so ziemlich das letzte, was für diese Infobox passen würde... Aber "Infobox Verwaltungseinheit" würde ja auch Landkreise und sogar Bundesländer und evtl. noch den Gesamtstaat Bundesrepublik Deutschland mit einschließen. "Infobox Kommune" würde ebenfalls auch die Landkreise mit einschließen, für die gerade erst eine eigene Box gestaltet wurde. Mein Vorschlag: Vorlage:Infobox Gemeinde in Deutschland. Der Oberbegriff für Verwaltungsgemeinschaften, Verbandsgemeinden, Samtgemeinden, Veraltungsverbände und Ämter ist übrigens nicht einfach Verwaltungsgemeinschaft, sondern meines Wissens Gemeindeverband. Infobox Gemeinde in Deutschland ist auf jeden Fall besser als "Ort in Deutschland". Eine eigene Infobox für die Gemeindeverbände ist aber unnötig. Zwischen den Gemeindeverbänden in den einzelnen Bundesländern gibt es wenig Gemeinsamkeiten und die Anzeige der Höhe könnte auch über die jetzige Box standardmäßig ausgeschaltet werden, genauso wie die anderen genannten Parameter.--Eigntlich 18:28, 20. Sep. 2007 (CEST)

Aktuell werden die Gemeindeverbände, trotz der Unterschiede je nach Bundesland, alle einheitlich behandelt, da sehe ich keinen Vor- oder Nachteil, ob wir eine oder zwei Vorlagen verwenden.Aber noch zwei Punkte, die mir aufgefallen sind:

• Die "manuellen" Infoboxen der Gemeindeverbände haben oftmals eine Zeile "Verwaltungssitz", die im Rahmen der Vorlage indirekt durch die "Adresse" abgebildet werden muss.
• Ein weiterer Aspekt ist, dass man bei den Gemeindeverbände den Parameter "Name" auf den Basisnamen des Verbandes setzen muss, d.h. "Rickling" für Amt Rickling, da sonst die Wappenbeschriftung falsch ist.

Insgesamt hat viele Sonderfälle, die man bei einer Trennung nicht beachten müsste. Ich bin mir selber nicht sicher, ob das der richtige Weg ist, aber halt einige Punkte, die es m.E. zumindest eine Überlegung wert machen. --S.K. 20:03, 20. Sep. 2007 (CEST)

Kleine Meinungsumfrage zur Umbenennung der Vorlage

Wichtiger Hinweis: Eine Umbenennung ist unkritisch, da der alte Vorlagenname in jedem Fall als Weiterleitung erhalten bleibt. Die Anpassung der 13.000 Vorlageneinbindungen kann schrittweise geschehen, z. B. zusammen mit der Aktualisierung der Einwohnerzahlen. Es wird auf keinen Fall 13.000 kleine Änderungen geben.

Vorschlag 1: „Infobox Ort in Deutschland“ beibehalten

Vorteil: Kurz und einprägsam. Nachteil: Wird oft falsch für Ortsteile verwendet.

Vorschlag 2: Umbenennen in „Infobox Gemeinde in Deutschland“

Vorteil: Deutlich restriktiver. Nachteil: Ämter, Samtgemeinden etc. sind keine Gemeinden im Wortsinn.

1. Ich bin trotzdem für „Gemeinde“, da dies der primäre Zweck der Vorlage ist. Die eventuelle Erstellung einer eigenen „Infobox Verwaltungsgemeinschaft in Deutschland“ würde ich nach der Umbenennung getrennt diskutieren. --TM 21:01, 23. Sep. 2007 (CEST)
2. Sehe ich auch so, und es trifft die „Zielgruppe“ der Vorlage auf jeden Fall besser als „Ort in Deutschland“, denn für reine Orte bestehen die meisten Daten der Infobox gar nicht. Vorschlag 3 wäre zu überlegen, wenn die Landkreise auch noch in diese Vorlage hier integriert wären, auch wenn sicherlich noch weitere Behörden als Verwaltungseinheit bezeichnet werden könnten.--Eigntlich 21:06, 23. Sep. 2007 (CEST)
3. Gemeinde ist klar besser. Und ich würde im Zweifelsfall dann später für eine neue „Infobox Gemeindeverband in Deutschland“ plädieren. Vorschlag 3 trifft es wie Eigntlich sagt nur dann, wenn die Infobox für alle Verwaltungseinheiten genutzt werden kann. Wenn ich in einem Programm eine Klasse „Gemeinde“ sehen würde, die für Gemeinden und Gemeindeverbände genutzt wird, würde ich sie ziemlich sicher refactoren und Verwaltungseinheit als abstrakte Basisklasse einführen. ;-) --S.K. 10:25, 24. Sep. 2007 (CEST)
4. Meine Rede seit 58 :-) Rauenstein 13:48, 24. Sep. 2007 (CEST)

Vorschlag 3: Umbenennen in „Infobox Verwaltungseinheit in Deutschland“

Vorteil: Schließt auch Ämter, Samtgemeinden etc. ausdrücklich mit ein. Nachteil: Landkreise sind ebenfalls Verwaltungseinheiten.

Samtgemeinde PLZ

Kann jemand aufklären, was mit den PLZs bei Samtgemeinden los ist? Wieso steht da jetzt so ein großes schäbiges rotes Zeug statt der PLZ? Und wenn man die PLZ weglässt, ist die Adresse der Verwaltung nicht mehr vollständig. Hat das einen tieferen Sinn? Gruß, --CWitte ℵ₁ 17:52, 28. Sep. 2007 (CEST)

Der Grund ist, dass für Samtgemeinden wie für andere Gemeindeverbände im allgemeinen keine sinnvolle PLZ existiert. Im allgemeinen muss man die Vereinigungsmenge über die PLZs aller Gemeinden bilden, eine potentiell lange Liste die niemandem nutzt. Bezüglich der Adresse sollte man dann das Feld "Adresse" verwenden und da die komplette Adresse mit Straße, PLZ und Ort eintragen. --S.K. 18:21, 28. Sep. 2007 (CEST) PS: Ausgangspunkt für die Änderung war die obige Diskussion.

Habe ich mir gedacht. Allerdings ist der Zustand nun sicherlich nicht gut. Bei der Samtgemeinde, die ich beobachte, gibt es nur eine PLZ und nur eine Vorwahl. Daher wäre die Angabe sinnvoll, wurde nun aber gelöscht und es steht in der Adresse nur noch der Variablename PLZ aus der Vorlage. Sind da irgendwelche Leute gerade am Arbeiten, um das wieder in eine gute Form zu gießen? Dann muss ich mir ja keine Sorgen machen... Danke für die Antwort auf jeden Fall,--CWitte ℵ₁ 18:29, 28. Sep. 2007 (CEST)