Dear Lina,

@Izno. You are true to reduce the usage of "important". But because it is already used it has to be used again for overwriting. Maybe the programmers of the night mode can change background to background-color only. I also do not know why such rules are necessary for this namespace only.

@Krinkle, de.wikivoyage.org: The "Karte" button is created by a Javascript and consists only of an image and a link <a href="#" ...>. The link itself is not used because an event is added to this tag. How will affect this both unified and m-dot? In future will remove the <a> tag because it is not really necessary (only for mouse behavior).

@Kinkle, es.wikivoyage.org: The code of https://es.wikivoyage.org/wiki/MediaWiki:Mobile.js (see also https://de.wikivoyage.org/wiki/MediaWiki:Mobile.js) is not necessary any longer because all scripts are now gadgets. It can completely be removed. Unfortunately I am now in holydays with a reduced set of tools (no 2FA), and therefore I cannot do it by myself, only in mid-November.

There was never a discussion on German (French etc.) Wikivoyages to use the non-default behavior. Why we should have now a discussion to use the default behavior? When this feature was introduced initial paragraphs were shown at the beginning of the text for mobile devices. Later on, nobody informed the (German) community that the default behavior was switched off.

@lina, thanks for your explanation. I thought that sub-referencing was already fully implemented.

@cscott Thanks for your explanation.

Thanks

In other words: The name and the description of the default for all languages should be the primary fallback (maybe before en) if the entries in the user language are missing.

It seems that the former section:

I assume that in InitialiseSettings.php the vector.sticky_header test enrollment was removed, and that's why sticky headers are now visible on all wikis. A month ago, Wikidata was excluded. Maybe @ovasileva can tell us about this.

Only a comment: Maybe it is useful to show the sticky header in any case (logged-in and logged-out users) in all wikis hiding only these icons which are not useful for logged-out users.

@Nikki: It is only at the new Vector 2022 skin, not on the old one and not on the main page. This feature is available on other wikis like German Wikivoyage, so it is not a local gadget.

This task is maybe a duplicate of T375981.

I will ask the user who told about this bug and how to reproduce it.

Maybe mainly with Firefox browsers.

It seems that the problem occurs mainly with the first sections.

See also T376152.

I learned that the coordinates are taken always from Wikidata (as noted by a maintenance category) because the frame:getParent().args used in the module are empty as stated by ABreault-WMF. As proposed by cscott I changed https://de.wikivoyage.org/wiki/Template:GeoData to use #tag:indicator instead of <indicator>. It seems now working.

I mainly thought about the indicator logo showing that Parsoid is used.

The logo is not working in dark/night mode (black angle brackets). Is there a dark-mode alternative icon?

The use of templates is a Mediawiki core functionality. It should properly work in any case both in main, user and template namespaces. In the task described here it is a very easy case because <noinclude> can be ignored. This should be an easy task for programmers.

cscott is working on this project Parsoid, and I hope he could help. At least, he should be a subscriber.

The severity is to set "High" because editing articles may fail.

I do not think so. dewikivoyage uses the same Parsoid (0.20.0-a14) and Kartographer versions (4b02f48, 22 July 2024) like enwikivoyage. The only difference is that at dewikivoyage we had to use ?useparsoid=1 at the url to use Parsoid because Parsoid is not yet rolled out. But the Kartographer is not working properly with Parsoid. And I do not know why. As I can see, that the <maplink> is spanned with a <span> tag at dewikivoyage.

The addition of the text color to a.mw-kartographer-autostyled tag would solve the problem of some 100,000 false positives as described in task T369282.

I opened another task T369454 to correct the Kartographer inline styles.

@Izno: In case of the Kartographer markers, it would make sense to add the correct colors (black or white) to provide appropriate contrast with the background. In many other cases inherit would be sufficient.

The explanations by matmarex are correct. The missing color style in Kartographer was the cause for the addition of styles in https://de.wikivoyage.org/wiki/Vorlage:VCard/styles.css and as inline rules.

One thing I should mention: There is no (automatic) export because of the high complexity of the Wikidata datasets and properties. I will discuss with Lydia from the Wikidata team how a manual interaction between the ListingEditor and Wikidata could be realized.

Since about 7 years, at the German Wikivoyage a listing template (vCard) was developed which supports Wikidata import, too. The templates (vCard, Marker) are used already at the Spanish Wikivoyage, and we are preparing now the use them at the Japanese Wikivoyage. All parameters mentioned by T.seppelt are supported. The values of about 50 parameters can be fetched from Wikidata as can be seen from the ParWD table in https://de.wikivoyage.org/wiki/Modul:VCard/Params . We propose to use at least two parameters like {{vCard/listing | name = aLocation | wikidata = Q12345678 }}. The name is only for readability and not necessary. The project is huge: There are about 30 Lua modules with 11.000 lines and 400 kBytes. It seems impossible to extend the existing tools at English Wikivoyage.

I mean to undeploy it. It is a little bit confusing to read that these skins are not bundled any longer but are available at the Wikimedia wikis as can be seen from Special:Version.

It is a double of T355044

As a workaround, use clear rule for .mw-footer-container container

Maybe for some tests: At German Wikivoyage, the Articles "Halle (Saale)" and "Wien" use the biggest amount of Kartographer GeoJSON data, in Halle (Saale) about 180,000 bytes. I hope that the page rendering is a little bit faster with the blob at the end at least for these articles.

At voy-de, MediaWiki:Gadget-Poi2gpx.js is using wgKartographerLiveData, too. But it is similar to MediaWiki:Gadget-MapTools.js.

@thiemowmde, I read your note. Only MediaWiki:Gadget-MapTools.js uses wgKartographerLiveData, and the gadget is called after complete load of the article by using $( mapTools.init ); at line 811. I hope that this is sufficient.

I don't really see that position in those 5 months old discussions...

I think the disabling of the Wikivoyage nearby feature is proved a failure. The usage of this feature should be controlled by the community itself which can be done easily in MediaWiki:Kartographer.js and by adding a variable to the map object which can be analyzed before calling wvmap.nearby(). The were discussion on several pages (https://de.wikivoyage.org/wiki/Wikivoyage:Lounge/Archiv_2022-12-31#Karte_mit_den_Wikivoyage_-_Artikeln? , https://de.wikivoyage.org/wiki/Wikivoyage:L%C3%B6schantr%C3%A4ge/Wikivoyage:Artikel%C3%BCbersicht ) asking to keep the Wikivoyage nearby feature at least for a map showing all articles. In my view, the disabling of Wikivoyage nearby would meet with a refusal in other Wikivoyage branches, too.

A comment in order to avoid a misunderstanding:

By the way, on Sunday I detected the bug T328866. It seems that the non-existing function map.addDataLayer is called in Map.js.

@awight: You are correct that the display of external data never worked correctly. It was changed several times on someone's (Wikipedian's) instance and became worse and worse. I think at the beginning there were hints like Wikidata ids linked to Wikidata. And as you correctly noted, there is another problem: normally these objects should not be displayed because they belong to groups. There do not present separate groups.

Geo objects (lines, shapes) defined in <maplink>s are never written to the articles source code/HTML code. That's why they could never used as a link.

It is correct that the Kartographer software was not yet well documented. It is unfurtunately the same like other software projects including mw core. Primarily, the Kartographer software was developed for the use in Wikivoyage wikis in a collaboration with Wikivoyage's authors, and that's why the prior behavior was intended even if not documented (or only in the shallow depths of the web). In case of point markers, usually the text is not empty (text="") but undefined (see for instance function mu.makeMarkerSymbol in https://de.wikivoyage.org/wiki/Modul:Marker_utilities). In case of lines and shapes defined by <maplink>, empty texts are combined with class = "no-icon" (see for instance function _mapframe in https://de.wikivoyage.org/wiki/Modul:Mapframe). This makes sense for geo objects like lines and shapes because they usually have no point coordinate which could serve as a map center.

The authors of the English Wikivoyage are really angry. This is the second serious programming error within the last two weeks.

The groups like "Gruppe: 0" (group: 0) are still shown today. But there is now an additional bug: T328739.

As shown in the documentation at https://doc.wikimedia.org/Kartographer/master/js/#!/api/Kartographer.Box.MapClass-property-lang , addGeoJSONLayer is a public function.

Now, a new failure occured: External data are noted as "Group: 1" (Gruppe: 1) but are not included in their groups. As you can learn from the wgKartographerLiveData variable, these features belong to groups, too.

@awight: The Script https://de.wikivoyage.org/wiki/MediaWiki:Gadget-MapTools.js uses the data from wgKartographerLiveData Javascript variable. In most cases, the features are included in this variable. The only exceptions are external data from OpenStreetMap and Wikimedia Commons: they must be fetched from WM's map server because they are not available elsewhere. Unfortunately, ext.kartographer.box is not able to do this job by itself.

The problem occurs on old Vector skin, too. But there are different behaviors on different wikis:

Thanks for all.

GeoCrumbs are cascading so it makes sense to make a null edit on pages with escaped span tags. Using the parser function isin the precursor of an article is specified, and so on. There is only one exception: if the page title consists of both a basepage name and a subpage name, then the precursor is taken from the basepage name if isin is not specified.

Reason: The rule was made by myself, it was in my personal common.css. When I made this it was used to work with the language button. I think the programmers moved the vector-menu-content class from language button to the menus below the header instead of using another one.

At the German Wikivoyage the problem does not occur because there is an older Mediawiki version running. But if I am adding the rule mentioned above the same error occurs.

I did not use Safe Mode in Firefox.