Hinweis
Für ältere abgeschlossene Diskussionen siehe Archiv-Übersicht.

Die neuesten Beiträge stehen am Ende!

Umzug Server: PrüfenBearbeiten

  • Template:Mapserver, Webserver
  • Template:Geo
  • Template:PoiMap2
  • Template:GPX indicator

-- RolandUnger (Diskussion) 14:45, 14. Jan. 2018 (CET)

Bot-TätigkeitenBearbeiten

  • {{GeoData}} Löschen leere Parameter prec, elev, elevMin, elevMax
  • {{vCard}} Löschen show=poi; intl-area-code, wenn leer. Punkt, Komma am Vorlagenende; einfügen show=inline, wennim Satz/Absatz.
  • Gruppen durch default-Typen ersetzen

Mobile VersionBearbeiten

  • Lua: relative URLs wie /w/index.php... möglich? Bedarf: Link auf Kartenwerkzeuge. --RolandUnger (Diskussion) 18:05, 21. Aug. 2018 (CEST)
.mw-kartographer-static .leaflet-control-container .leaflet-top .leaflet-control {
    display: block;
    /* display: none */
}

ErledigenBearbeiten

Hoteldaten auf WikidataBearbeiten

Halle (Saale), St. Gallen, El Gouna, Chārga (Stadt), Bāwīṭī, ʿAgūz (Baḥrīya) und Kairo/Taḥrīr-Platz.

Quickbar editorBearbeiten

I got an idea, but for the initial stage I'd like to have your support, hoping that it would be enough interesting for you. Since most of the Quickbar data are fetched from Wikidata, I'd like to have a dedicated editor able to update wikidata when needed (from Wikivoyage without the need to change project), and this should be easy because most of the information are not "complex". Furthermore I'd like that this editor will be based on a library that is compatible with mobile device.

Creating such framework for this Quickbar editor, in a following stage it should be easier to migrate the listing editor.

What do you think? --Andyrom75 (Diskussion) 07:56, 26. Dez. 2020 (CET)

Could you reply? --Andyrom75 (Diskussion) 16:12, 31. Dez. 2020 (CET)
Hi. Happy New Year. So sorry for intervening here. I happen to read this and just want to leave a comment. The information may not be "complex", the way to use the Wikidata API may not be complex es well, but the process itself is tricky. Changing a value is complex. Just take the population as example. You must not update the population number. You have to add a new value, setting it to high priority, setting down the priority of the old value and WD expects a qualifier (date of the value) and a source. The editor has to check the existing values on WD and a decision is to be done, whether a value is to be updated or an additional value is to be added.
The second point is. I am sure there are ongoing projects on WD for an easy to use interface to edit WD, even directly from other projects. And I am sure the infoboxes are always the first targets for new developments. Its better to get involved there. An own development (like our listing editor) has always a huge disadvantage. You have to take care of it and maintain it and bugfix it by your own (thats the reason why I do not do any programming any longer). If the developer (in worst case only one - thats the normal case on WV) is not available (holiday, lack of free time, hopefully not sick or simply left the project) the project has a huge problem. Nobody can take care of it. If ist developed by WMF or at least a team of Wikimedians supported by the community or an association, you have the manpower and phabricator for further development and bugfixes. -- DerFussi 11:25, 1. Jan. 2021 (CET)
@Andyrom75: Unfortunately, I have no time to support the idea of Andyrom75. There are already many projects to me to support including some support of the English Wikivoyage. But there are other causes, too. We do not need (or only seldom need) such a tool at German Wikivoyage because the Quickbar developed by Fussi retrieves all data which are available at Wikidata and gives a link to Wikidata if necessary. So in many cases only the template call without values is necessary. Otherwise handling of Wikidata data (especially the export) is really complex even in case of non-string properties and properties with qualifiers, already existing property values and so on (Fussi gave some examples, too). On the other hand, infoboxes are a common task for all projects, and developments of tools to support this are announced. Furthermore a better integration of Wikidata into the Wikimedia wikis is demanded. We should not spend time for things which are done by anybody else.
In future I will make only some extensions to the listing editor to support the import of data and I will think about a transfer from jQuery UI to OOJS. I will not support the export of data to Wikidata. And I will write some new articles and information because this is noticed by the readers. --RolandUnger (Diskussion) 07:46, 7. Jan. 2021 (CET)

FehlersucheBearbeiten

Hallo Roland. Ich bin über deinen Edit gestolpert. Welcher Fehler lag vorher in der Navigationsleiste vor? Die jetzige Variante ist leider typografisch unschön, da sie innerhalb mehrteiliger Länderbezeichnungen einen Zeilenumbruch vornimmt (Sichtbar nur bei kleinen Bildschirmen). Die Version mit dem no-wrap-Bereich und den Punkt-Vorlagen verhindert das, was ich persönlich als bedeutend besser empfinde. -- DerFussi 18:31, 28. Dez. 2020 (CET)

Es gab einen <span>-Tag-Fehler, und ich habe ihn nicht gefunden. Das {{nowrap begin}}/{{nowrap end}}/{{•w}}-Konstrukt ist alles andere als leicht zu handhaben und überaus fehlerträchtig. Eine Vorlage, die den zu umschließenden Text erfasst, wäre sinnvoller (vielleicht {{wrap|Text}}). Es macht übrigens keinen Spaß, den Fehlern anderer hinterherzulaufen. Aber die genannten Vorlagen sind selbst für erfahrene Autoren zu viel. --RolandUnger (Diskussion) 08:32, 29. Dez. 2020 (CET)
Das denke ich nicht. Was ist daran so kompliziert? Anfangen, Links trennen und Bereich schließen. In allen anderen Navileisten scheint es keine Probleme zu geben. Deine gewünschte Vorlage gibt es übrigens {{Nowrap}}. Wo wurde der Fehler angezeigt? Bei den Lint-Fehlern? Werden die eventuell gecacht? Der HMTL-Validator weist für die alte Version keinen Fehler aus: hier.... Ich gucke auch noch mal, ob mir was auffällt. Andererseits halte ich es nicht für schlimm, wenn bei selten benutzten Seiten, wie Navigationsleisten die Syntax etwas komplizierter ist. Die meisten Artikelautoren haben damit keinen Kontakt. Man erstellt sie ein mal und fasst sie dann im Regelfall nie wieder an. -- DerFussi 10:48, 29. Dez. 2020 (CET)
Ja, dann bringe es doch einfach in Ordnung. Die Fehler werden vom Linter angezeigt, und der ist recht zuverlässig. Der HTML-Code wird vor der Auslieferung fehlerbereinigt, da findet man niemals Fehler. Nach einem Dummy-Edit einer betroffenen Seiten zeigt der Linter sofort an, dass die Seite fehlerfrei ist. --RolandUnger (Diskussion) 10:58, 29. Dez. 2020 (CET)
PS: <br> ist ein block-Tag, dass man nicht umspannen kann. --RolandUnger (Diskussion) 11:00, 29. Dez. 2020 (CET)
Das letztere ist mir bekannt. Das ist ein üblicher Fehler, der gern gemacht wird. -- DerFussi 11:03, 29. Dez. 2020 (CET)
"Es macht übrigens keinen Spaß, den Fehlern anderer hinterherzulaufen..." Ja das wiederholst du immer wieder. Aber den Druck machst du dir selbst. In einem Wiki werden immer Fehler gemacht. Und das Wikis geradezu prädestiniert sind, Fehler zu machen, wissen wir. Gerade ich agitiere ja immer wieder, dass es einfacher werden muss und unsere Dokumentation schlecht und zu technisch ist. Das ist die Situation gerade. Aber ich denke, im Vorlagennamensraum darf es technscher sein, weil nur wenige damit Kontakt haben. Andererseits denke ich, wenn irgendwo ein HTML-Fehler ist, und der ein Jahr dort drin bleibt. Ist das schlimm? Ich mache auch oft Schusselfehler, von denen wahrscheinlich auch einige noch drin sind. Ist das schlimm? Das Wiki geht davon nicht unter. Erst recht nicht, wenn es erstmal keine sichtbaren Auswirkungen hat. Wenn es die hat, merken es die Autoren sofort und können sich zur Not melden. Wenn nicht? Wie gesagt, ist es kein Beinbruch. Wenn das Ding ein Jahr drin bleibt - auch nicht schlimm. Auch im zweiten Jahr nicht. Es ist ein Community-Projekt. Es soll also Spaß machen. Schlimm wird es, wenn es keinen Spaß mehr macht, weil man denkt, alles kontrollieren zu müssen. Deshalb rufe ich die Wartungskategorien eher nur noch jährlich mal auf, wenn ich die Muße dazu habe. Aus meiner Sicht reicht es. Und wenn andere Benutzer ihre Fehler nicht immer wiederholen, ist das alles aus meiner Sicht kein Grund zu Klage. Und den einen oder anderen Fehler finden vielleicht auch die anderen - wenn sie die Zeit dazu bekommen. Ich kann deine Einstellung durchaus nachhvollziehen, ich bin in solchen Dingen eigentlich auch ein kleiner Sheldon Cooper. Aber es gibt auch ein Leben neben Wikivoyage. -- DerFussi 11:52, 29. Dez. 2020 (CET)

──────────────────────────────────────────────────────────────────────────────────────────────────── Ich habe im entsprechenden Hilfeartikel noch einen Hinweis angebracht. Dort sind auch die Benutzung der Vorlagen und der typografische Zweck erklärt. Die Benutzung von {{Nowrap|Text}} hätte sicher kaum Mehrwert, da dies auch nur ein Span-Tag erzeugt. Das BR-Tag-Problem bleibt dabei trotzdem bestehen. Das ist aber ein generelles Problem, womit man einfach leben muss. Wir Nerds wissen dass, alle anderen nicht. Fehler passieren halt. Im einfachen Wikitext-Editor ohne Syntax-Highlight bietet die Variante {{nowrap begin}}/{{nowrap end}} den Vorteil, dass man Anfang und Ende des Bereiches einfacher lokalisieren kann, und nicht die passenden schließenden geschweiften Klammern suchen muss (OK, im VE habe ich mir das noch nie angesehen). Wenn du eine bessere Variante hast, die Umbrüche in bestimmten Bereichen sauber zu steuern, gerne. Dann sollte aber auch die Anleitung dementsprechend geändert werden. Und wie gesagt, dass die drei Vorlagen erfahrene Autoren überfordern, halte ich für eine recht gewagte Behauptung. -- DerFussi 21:31, 29. Dez. 2020 (CET)

Ich muss mich doch noch mal melden. Mir war auch so, dass man das Element <br /> nicht in einem <span>...</span> unterbringen sollte. Zumindest hast du es an mehreren Stellen schon mal erwähnt. Das Problem existiert ja auch in der VCard deiner Aussage nach. Das Problem ist, das sich kein Autor dafür interessieren wird (und auch nicht muss), welches HTML in welcher Vorlage steckt. Da wir viele umspannende Vorlagen haben, benötigen die eigentlich einen Hinweis auf allen entsprechenden Vorlagen-Dokumentationen - zumindest ist das dann hilfreich für die, die sie überhaupt lesen. Da ich gerne eine offizielle HTML-Doku in den Hinweisen platzieren würde habe ich eine gesucht - und keine gefunden. Du hast oben geschrieben dass das Tag <br /> ein Block-Tag ist. Aber deine Aussage stimmt offensichtlich nicht.
  • Auf dieser Seite ist es als Inline-Element gelistet.
  • Ich habe mal eine Testseite online gestellt und validiert - offensichtlich ist es kein Problem.
  • Diese Doku sagt, dass ein <br /> in "phrasing content" vorkommen darf, was ein <span>...</span> ja ist (siehe dort drüber).
Das lässt mich zu dem Schluss kommen, dass zum einen das Problem mit der Navileiste möglicherweise anderer Natur war und/oder im HTML-Standard noch weitere Spezifikationen existieren, die ich nur nicht gefunden habe. Bei letzterem wäre es schön, wenn du einen Tipp hast wo es steht und offiziell dokumentiert ist. Nun ist ja Wikitext XML. Möglicherweise gibt es ja wikispezifische Einschränkungen. Dann wäre ich auch über einen Tipp dankbar, was geht und was nicht. Eventuell setze ich die Navileiste noch mal zurück und schaue mir an, was für ein Lint-Fehler dort genau stand. -- DerFussi 15:33, 30. Dez. 2020 (CET)
Sehr ominös: Nicht nur ein BR-Tag erzeugt den Lint-Fehler - auch ein "normaler" Zeichenumbruch im Wikitext, der ja eigentlich im HTML ignoriert wird. Ich habe den Fehler erst mit diesem Edit wegbekommen. Kurios: wenn ich einen Zeilenumbruch im Text wieder einfüge, wie im jetzigen Zustand,kommt der Fehler nicht wieder. Da will ich langsam nicht mehr glauben, dass die Lint-Fehler-Anzeige nicht gecacht ist. Wie auch immer. Warum der Fehler überhaupt kommt, wenn <br /> ein inline-Tag ist fragt sich dann trotzdem noch. -- DerFussi 17:07, 30. Dez. 2020 (CET)

────────────────────────────────────────────────────────────────────────────────────────────────────

@DerFussi: Normalerweise dauert es nicht so lange, bis ich antworte. Ich habe mich einfach gefragt, wo unser Denkfehler liegt. Und es ist ganz einfach: Was wir schreiben, ist kein HTML, auch wenn es – nicht unabsichtlich – danach aussieht. Es ist schlicht und einfach Wiki-Syntax, die von einem Parser interpretiert wird und für das Wiki in HTML umgesetzt wird. Mich würde es nicht wundern, wenn immer noch das Ziel verfolgt wird, aus der Wiki-Syntax alles Mögliche zu erzeugen. Und für die Wiki-Syntax ist das <br> ein Block-Tag, was eigentlich durchaus denkbar oder sinnvoll sein könnte. Ich denke, dass die Programmierer des Linters das auch bedacht haben. Prinzipiell könnte das <br>-Tag auch einen neuen Absatz einleiten, der einfach keinen oberen Rand besitzt.

Dass der normale Zeilenumbruch auch diese Probleme schafft, ist eigentlich nicht verwunderlich, aber man erkennt ihn nicht immer oder man denkt nicht daran. Es gab Zeiten, zu denen bereits ein einfacher Zeilenumbruch einen neuen Absatz erzeugt hat – offensichtlich kann sich das Parser-Verhalten durchaus ändern.

Die Übersicht des Linters mit seinen Zahlenangaben hinkt hinterher (teilweise auch, weil die Artikel noch nicht geparsed worden sind). Die eigentlichen Listen mit den Fehlerstellen sind aber aktuell. Wenn eine Bearbeitung das Problem bereinigt, wird der dann fehlende Fehler nach Löschen des Browser-Caches auch richtig angezeigt.

Das Problem mit dem Wrappen ist eigentlich das, dass nicht jeder Autor realisiert, dass sie nur im Verbund funktionieren. Das macht die Verwendung natürlich fehlerträchtig. Vielleicht kann man das Problem etwas entschärfen, wenn man anstelle der Verwendung von <br> lieber den Block in <div>- oder <p>-Tags einfügt. Dann kann man auch Zeilenumbrüche zur übersichtlicheren Formatierung einsetzen. --RolandUnger (Diskussion) 11:54, 9. Jan. 2021 (CET)

Das geht ja wirklich in die Richtung meiner Bemerkung WikiText ist nicht HTML. Ich habe des Satz in dem Hilfeartikel schon etwas umgeschrieben. Über Alternativen habe ich auch schon nachgedacht. Andererseits habe ich die aktuelle Verwendung in dem Hilfeartikel eigentlich genau und beispielhaft beschrieben. Ich habe auch über andere Tags nachgedacht. Entweder die Nowrap-Vorlage parametrierbar zu machen (dass sie <div>...</div> oder <p>...</p> statt <span>...</span>) verwendet. Oder eine eigene Vorlage mit verrückten CSS-Klassen mit :before und :after inklusive content für die Leerzeichen Punkte dazwischen. Am Ende habe ich alles verworfen. Es ist extra Aufwand, zusätzliche Vorlagen und Parameter müssen alle dokumentiert werden - und das alles nur für Navigationsleisten. Die meisten werden nie angefasst, wenn sie ein mal erstellt sind. Das ist den ganzen Aufwand nicht wert. Die meisten Navileisten und Regionen-Quickbar-Vorlagen sind eh' von mir und deshalb habe ich immer ein Auge auf sie, auch auf die, die die anderen Benutzer anlegen. Deine Reaktionszeit von 23 Stunden im Falle von der von Afrika kann ich natürlich nicht einhalten, anschauen tu' ich mir alle im Regelfall. Aber wie gesagt, ich sehe das nicht so kritisch. Also kurzum. Aus meiner Sicht, würde ich wegen der Navileisten nichts unternehmen (Vorlagen, Klassen, Parameter). Wenn irgendwo ein Problem auftaucht fixe ich es, und gut.
Die Frage ist, ob wir in Vorlagen, die Span-Tags benutzen, einen standardisierten Warnhinweis einbauen, <br /> innerhalb des Textes zu vermeiden und lieber echte Absätze zu erzeugen. Das betrifft sicher alle Textformatierungs-Vorlagen. -- DerFussi 12:23, 9. Jan. 2021 (CET)

VerkehrszeichenBearbeiten

Hallo Roland,

ich wollte in den Artikel Bike and Ride das bekannte Verkehrszeichen B+R einfügen (blaues Schild mit weißen Feld und schwarzer Schrift "B+R"), wie man es in der Regel an Bike and Ride Anlagen und auf Wegweisern häufig sieht, dieses aber innerhalb der Wikimedia Netzwerke nirgendwo finden können. Es sei zwar kein offizielles Verkehrsschild gemäßg der Bildtafel der Verkehrszeichen in Deutschland, aber es wird dennoch von Kommunen und Verkehrsunternehmen verwendet, könntest du dieses in den genannten Artikel integrieren und auch schauen, welche Informationen in dem recht neuen Artikel noch ergänzt werden könnten?

Viele Grüße, Michael 84.174.187.28 14:19, 4. Feb. 2021 (CET)