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.

This Mediawiki Extension is licensed under GNU General Public Licence 2.0 or later. Author was Roland Unger.

If the bug is caused by cache limitations: Maybe a simple destructor entity:remove() would help. People told me that all entities are cached until the end of article parsing. But most of the entities are used in only one template and must not be cached any longer.

I tried to remove the museum section from https://de.wikivoyage.org/wiki/Halle_(Saale) and to stop using qualifiers and references from entities but the bug remained.

See also T189409.

It seems that it is a sudden spike. The computing time only for addStatementUsage jumped from about 600 ms to 5000 ms (all Lua stuff from about 4.5 sec to about 9 sec). Within the last two weeks I added and optimized the analysis of opening hours to our vCard template. As in the past I used the same technique to prevent retrieving data from Wikidata. We are using several tables like this: https://de.wikivoyage.org/wiki/Modul:Hours/i18n with prepared data. On this way there is usually only one getEntity call per template. The number of entities used increased within the last two weeks only by about 1. Of course I added some statements to the Wikidata datasets (mainly of museums) to test the display of opening hours. Within the last two weeks there was no significant change. The core functions were added already on Sep. 26, 2020.

Maybe it is the same like T236485.

It seems that the/some cookie requests were initiated by Ajax API calls like wbgetentities.

Within the last days I made some programming (for instance on https://de.wikivoyage.org/wiki/MediaWiki:ListingEditor.js) and I am testing my changes including the check of console output. I saw the messages mentioned today for the first time. Normally only messages like "Use of "mw.RegExp.escape" is deprecated. Use mw.util.escapeRegExp() instead.", "JQMIGRATE: jQuery.fn.delegate() is deprecated", or "This page is using the deprecated ResourceLoader module "jquery.ui" occur. But today a lot of cookie messages occur including unnamed cookies like "Cookie “” has been rejected as third-party."

Different notice

I observed this on German Wikivoyage.

At the console I found the following message:

I tried to import https://de.wikipedia.org/wiki/R%C3%B6merstra%C3%9Fe_Neckar-Alb-Aare (w:de:Römerstraße Neckar-Alb-Aare) from German Wikipedia to German Wikivoyage. I got only the error message "Import fehlgeschlagen (= import failed): Main slot of revision not found in database. See T212428." but nothing else. This failure happened all the time with this page, but we did not tested it with other pages.

Error occurs with Special:Import, too, for import both from wiki and file.

The import fails on German Wikivoyage, too, from both wiki and file.

Please check public static function makeTrail( Title $title, ParserOutput $parserOutput, User $user ) in GeoCrumbsHooks.php.

This bug is occurs only from today. It seems to be a side effect of a change in another module because geocrumbs extension was last changed three weeks ago. Maybe $linkText = $parserCache->getTitleText(); fails.

Example: https://de.wikivoyage.org/wiki/Luxor