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.

In principle, it makes sense. But it makes no sense if that change was announced a long time ago (as it was done by SGrabarczuk on April 24, 2022) but was not yet realized.

@Jdlrobson: German Wikivoyage uses classical table of contents, not table of contents in the banner. That's why there are no open questions in this case. But I am wondering that this feature of the sidebar toc is working on all Wikivoyages but not at the German Wikivoyage.

Maybe it makes sense to filter these markers while rendering. But the communities have no change to do it by themselves. At least, there should be a hook to add this filter to MediaWiki:Kartographer.js.

By the way, the pushpin markers are not only needless and cover the geoshape of interest. The authors have no mean to modify the pushpin (colors, sizes etc).

I found the bug described for geoline objects, too. See for instance: https://de.wikivoyage.org/wiki/Vorlage:Mapshapes . The map shows several subway lines of Vienna whereas the stations ar marked with a pushpin marker.

Maybe is more useful to authors to have only one class like pageimage or a markup for only one image instead of the multiple use of nopageimage.

For most non-Wikipedia wikis the automatic search is not restricted to the leading section (and sometimes not suitable, too). This restriction was introduced because of a not suitable search algorithm. The result of the automatic search is often not clear for many authors that's why is useful that the authors can autonomously select the page image of interest.

The Javascript console shows the following report:

Contrary to Wikipedias, there is no obligation to use references in Wikivoyages. That's why there are big differences in usage among articles.

Thanks for activating the previews.

I am ready, and the community, too. At German Wikivoyage, there is only a small community, and only a few users who are using the old tools. The community already decided to use the new tools. I will remove the gadgets, used up to now for the same aim, this weekend to prevent any conflicts.

It is no problem to me to remove "Navigations-Popups" and "Reference Tooltips" from gadgets and to inform the community on these changes.

@Jdlrobson, @Lena_WMDE: I thought it would a simple task to enable "Reading preferences" at the user's preferences. As I told: we need both the "enable page previews" (as already done at the English Wikivoyage) and the "enable reference previews" options. The main case is to remove the gadgets as they are used now at the German Wikivoyage (to reduce maintenance work).

Another example:

Now, I am using the following CSS rule as a workaround:

To make it more clear: The language button is not working properly, ie the languages list cannot be opened by pressing the language button. The failure occurs only sometimes not at all the time. That's why it is not easy to reproduce it. But it occurs both at German Wikipedia and at German Wikivoyage which use completely different gadgets. That's why I think that local gadgets are not the cause for this failure.

There are several problems to me:

I did not set https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-rendering at any wiki.

Working with safemode is difficult because the error does not occur at every time.

Firstly, I add a screenshot:

The functions mentioned are not really broken but non-performant. For instance, I was using about 100.000 split operations in 250 templates. Firstly, I did it with mw.text.split(), and it took about 3,000 ms. Then I replaced these convenient but slow functions with Lua functions like match() and gmatch(), and the same took only a few ms. 3,000 ms computing time is really much and finally it caused an allocation-time error.

I think I found the failure: it is a damaged / erroneous mw.text library, especially mw.text.split and mw.text.trim!

From https://de.wikivoyage.org/wiki/Spezial:Version I learned that the last Mediawiki version is of

Now I am making several changes on https://de.wikivoyage.org/wiki/Modul:VCard and its submodules. To prevent (many) error messages I am checking https://de.wikivoyage.org/wiki/Kategorie:Seiten_mit_Skriptfehlern (pages with scripting failures) twice per day and after code changes. That's why I think that the jump in time consumption occurred 12 (or not more then 24) hours ago. The time consumption of https://de.wikivoyage.org/wiki/Halle_(Saale) is checked weekly because it is one of the most time consuming articles. We would earlier detect the changes by Debian upgrades made in January, 2021. We observed similar results to December 2021 a few days ago.

The increase of computing time of the functions mentioned is about a factor of 30!

At the German Wikivoyage, Reading preferences (Enable page previews (quick previews of a topic while reading a page)) are not available.

See T267296, too

It is not the first time that the map server is not working properly (T231964, T226412). But these malfunctions should not block drawing map structures which are not fetched from the mapserver/OSM database. The non-database structures are drawn only after a successful fetching of geolines and geoshape objects. If the fetching failed then the drawing of non-database structures will be blocked because of errors of JavaScript promises. This should not happen in any case. That's why I propose the following two changes:

The map server returns a 404 error.

Some tests on https://de.wikivoyage.org/wiki/Kairo/Ta%E1%B8%A5r%C4%ABr-Platz

The same error occurs on English Wikivoyage, too.

I was surprised, too. And I did not made any changes (yesterday morning I only added some maintenance categories). The computing times for addStatementUsage oscillate (between 400 and 900 ms) but they are clearly reduced. I think yesterday the 1.36.0-wmf.14 Mediawiki branch was deployed at Wikivoyage. Maybe that means to find the cause we had to look for it outside of Wikibase. Unless I'm very much mistaken addStatementUsage only makes a registration of entities and properties used. This should not be expensive. But I have no idea what happens at the registration and what went wrong.

The computing times for Scribunto_LuaSandboxCallback::getEntity and Scribunto_LuaSandboxCallback::addStatementUsage did not change much, but only that of Scribunto_LuaSandboxCallback::addStatementUsage changed drastically. The number of properties fetched increased within the last four weeks only by one which cannot explain the increase of computing time of this simple function. Maybe there is a problem with the accumulator/cache or database.

I am not sure if T263999 is the real cause for this bug. But I cannot exclude this cause, or maybe both bugs have a joint cause elsewhere. addStatementUsage only registers the use of an entity and a property and has maybe nothing to do with functions in which a language was specified.

The Wikivoyage template vCard can use up to 50 statements per template (see table ParWD at Module:VCard/Params, too). About 5 addStatementUsage calls per template on average are not really much even for an entity which is already loaded (loading takes only about 2.5 ms). Within the last weeks we added only one statement (P3025: open days). Therefore, the number of addStatementUsage calls increased only by a few percent.