Benutzer Diskussion:RolandUnger/Archiv/2021/1.Quartal

Dieser Artikel ist Teil unseres Archivs. Den aktuellen Artikel findest Du unter Benutzer Diskussion:RolandUnger.

---

Quickbar editor

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)

Fehlersuche

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)

Modul:Marker utilities/Types

Hallo Roland, Du hast heute bei den Typen etwas geändert bzw. entzerrt. Ich würde dazu einen kleinen Vorschlag machen:

• ["dam"] = { group = "see", label = "Talsperre" } : gibt es schon -> Stausee (reservoir), oder ist das etwas anderes? Ich glaube nicht.
• ["embankment_dam"] = { group = "see", label = "Staudamm" } : ist okay
• ["weir"] = { group = "see", label = "Wehr" } : besser "Stauwehr"? Dann wird das -weil sinnverwandt- in der alphabetischen Liste Hilfe:Marker/Typen auch besser sortiert.
  Gruß --Eduard47 (Diskussion) 18:34, 10. Mär. 2021 (CET)

• Zu 1 und 2: alle drei Objekte werden in einzelnen Sprachen unterschieden und sind touristisch interessant. Innerhalb der nächsten Zeit sollen zudem alle Typen (so vorhanden) eine Wikidata-Id bekommen. Das hat mehrere Zwecke: zukünftiger Export von vCards nach Wikidata, Übersetzung in anderen Wikivoyage-Zweigen und Rechenzeiteinsparung (Entlastung von Modul:Marker utilities/wdTypes).
• Zu 3: Ich war mir gestern nicht ganz sicher, Wehr oder Stauwehr. Ich habe alles in Stauwehr geändert. Wehr findet man auch so. --RolandUnger (Diskussion) 07:15, 11. Mär. 2021 (CET)

Danke Roland, dass Du Dich der Sache angenommen hast. Bzgl. Stausee:Talsperre magst Du ja Recht haben, wenn man die verschiedenen WD-IDs betrachtet. Der Text bei WP über Talsperre wirbelt allerdings beide Begriffe kräftig durcheinander. WP hat natürlich auch noch den Artikel Stausee, der aber keine Differenzierung bringt und schon gar nicht eine Unterscheidung zur Talsperre liefert. Ich habe keinerlei Idee, wie man die beiden Begriffe bei den Typen zusammenfassen könnte, die getrennte Betrachtung ist m. E. aber auch keine Lösung. Gruß --Eduard47 (Diskussion) 14:55, 11. Mär. 2021 (CET)

Hallo Roland, in der recht umfangreichen Liste sind ja auch einige Typen enthalten, für die es unterschiedliche deutschsprachige Bezeichnungen gibt (Beispiel: "boat_trip" = "Bootsfahrt, Schiffstour"). Das erleichtert natürlich bei der Eingabe in den vCard-Editor u. U. erheblich. Dennoch gibt es weitere Typen, für die ebenfalls eine 2. deutschsprachige Bezeichnung sinnvoll wäre. So gibt es regional, landestypisch unterschiedliche Bezeichnungen für ein und das gleiche. Die österreichischen bzw. schweizer Kollegen würden es bestimmt begrüßen. Wie kann man diese zusätzliche Bezeichnung, ohne großen Aufwand treiben zu müssen, in die Liste einbauen um auch dadurch die Akzeptanz zu verbessern? Gruß --Eduard47 (Diskussion) 18:43, 20. Mär. 2021 (CET)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

@Eduard47: Ich weiß, dass es bei den Talsperren durcheinander geht. Irgendwie ist man sich zum einen einig, dass es ein Bauwerk ist. Zum anderen werden beide Dinge nicht selten separat bezeichnet (Bleilochtalsperre, Bleiloch(stau)see) und beide Typen sind auch in Wikivoyage in Gebrauch. Ich bin mir aber nicht sicher, ob wir den Staudamm brauchen.

In der Typenliste haben wir schon an mehreren Stellen Mehrfachbezeichnungen. Dies lässt sich verhältnismäßig leicht ausbauen. Es müsste mal jemand darauf schauen, was möglicherweise fehlt. Die Begriffe stehen unter label in der Typenliste. Das label wird nur für den Listingeditor gebraucht. --RolandUnger (Diskussion) 17:58, 22. Mär. 2021 (CET)

Danke Roland, mir ging es hier nicht um Talsperre oder Stausee. Damit kann ich leben. Den Staudamm sollten wir aber beibehalten. Es kommt vermutlich häufiger vor, dass durch WD bei Talsperre bzw. Stausee der Marker nicht mit dem Marker des Staudamms übereinstimmt. Als Reiseziel ist aber u. U. beides interessant.

Ich würde gerne einige Bezeichnungen erweitern, darf ich diese selber in die Typenliste eintragen, oder soll ich sie auf der Diskussionsseite unter "Gewünschte Typen" (evtl. zusätzlichen Unterabschnitt?) eintragen? Vielleicht haben ja auch andere noch derartige Wünsche. Gruß --Eduard47 (Diskussion) 18:27, 22. Mär. 2021 (CET)

Ergänzung: Habe mal in Modul:Marker utilities/Types einige zusätzliche Bezeichnungen eingegeben. Schau Dir das doch mal an, wenn's nicht passt: Schmeiß es wieder raus! Gruß --Eduard47 (Diskussion) 21:25, 22. Mär. 2021 (CET)

@Eduard47: Es passt ja. Und ich bin auch über diese Ergänzungen dankbar. Die einzige Sache, die ich noch anmerken möchte: Nach jeder Bearbeitung dieser Listen werden ungefähr 15.000 Artikel neu geparst. Damit sind die Server dann etwas beschäftigt. Ich versuche immer, pro Tag nur zweimal diesen Prozess anzustoßen. Wenn mehrere Module geändert werden, dann schließe ich alle etwa zur gleichen Zeit. --RolandUnger (Diskussion) 17:52, 23. Mär. 2021 (CET)

Kl. Bug im Listing editor?

Ich habe gerade auf voy:es in einem Museum die Wikidata ID eingetragen - per Listing-Editor. Plötzlich gabe es den Typen doppelt, einmal den Paramater auf englisch, einmal auf spanisch geschrieben. [1] -- DerFussi 08:41, 24. Mär. 2021 (CET)

Sollte nicht mehr sein, ich schaue mir das aber an. --RolandUnger (Diskussion) 08:43, 24. Mär. 2021 (CET)

@DerFussi: Ich denke, der Fehler lag in der Zeile 2837 der spanischen Version

&& listingTemplateAsMap[key2] && listingTemplateAsMap[key] !== '' ) {

Das key muss ein key2 sein. Man kann die letzte Bedingung aber auch ganz weglassen. Ich habe eine neue Version von MediaWiki:ListingEditor-es.js‎ bereitgestellt. --RolandUnger (Diskussion) 12:30, 30. Mär. 2021 (CEST)

Ja, der Fehler ist behoben. --RolandUnger (Diskussion) 14:03, 30. Mär. 2021 (CEST)

Listing Editor

Da ich gerade wieder mal aus Versehen eine VCard gelöscht habe, weil die Löschen-Checkbox dort steht, wo im normalen Quelltext-Editor die Kleinigkeiten-Checkbox steht (keine Ahnung, ob das anderen auch schon passiert ist) fiel mir folgendes auf: Auch beim Löschen der VCard wird man gefragt, ob man das Aktualitätsdatum auf das heutige Datum gesetzt haben will. -- DerFussi 08:25, 5. Apr. 2021 (CEST)

Ich habe mal das Löschen verschoben und die Aktualisierung herausgenommen (und die Lösch-Id im Quelltext auch so benannt.) --RolandUnger (Diskussion) 09:42, 5. Apr. 2021 (CEST)

Danke. Heute habe ich noch bemerkt, dass auf voy/es der Edit-Link für die Listings verschwunden ist. Habe auch mal die Module aktualisiert, aber das Problem war bereits vorher da. -- DerFussi 17:29, 5. Apr. 2021 (CEST)

Ich vermute, dass Nutzer Galahad hat beim Übersetzen einen Fehler gemacht und einen Zeilenwechsel in den Lizenztext eingebaut hat. Ich werde mir das in den nächsten Tagen ansehen. --RolandUnger (Diskussion) 20:01, 5. Apr. 2021 (CEST)

Dan habe ich es gerade gefunden und gefixt. Habe nicht mitbekommen, dass er das Ding editiert hat. -- DerFussi 20:28, 5. Apr. 2021 (CEST)