User scripts on de.wikivoyage.org only seldom use external modules. The dependencies are realized with mw.loader.using()/require() calls. Maybe there are missing dependencies in Kartographer. Some time ago we found such a failure (T197655).

Sometimes a runtime error (TypeError) occurs but not in any case. This error prevents proper function of mw.hook().

In case of a runtime errrors mw.hook() is sometimes not working. This can be overcome by using jQuery.ready function.

Of course, the global function call is to be adapted to use jQuery like ( function ( $ ) { ... } ( jQuery ) );

Yes, this should also include email aliases. The wikivoyage-ev.org addresses are working upto now. The @wikivoyage.org should be preserved.

wikivoyage-old.org was used only at the transfer process of the Wikivoyage domains from the servers of the Wikivoyage association to that of the Wikimedia Foundation to have a copy for comparison. According to a agreement with the Foundation we closed wikivoyage-old.org at the beginning of 2013 to prevent double content on the internet.

In T199367#4439235, @Niharika wrote:

In T199367#4437714, @RolandUnger wrote:

RelatedSites is used at the German Wikivoyage because the user namespace is not supported by Wikidata. We need a set of interwiki-links like [[commons:...]] for sister projects similar to interlanguage links [[en:...]]

The extension was not meant for linking to user pages. The better way to handle user namespace links is by having Userboxes or by adding the links on the User page instead of the sidebar.

If no zoom parameter should read instead of If now zoom parameter.

At the travellers' pub at the English Wikivoyage edition another fault scenario was reported: If now zoom parameter is set (auto-zoom mode) a world map is displayed instead of a location map. It seems that the runtime error explained prevents the calculation of map center and zoom.

RelatedSites is used at the German Wikivoyage because the user namespace is not supported by Wikidata. We need a set of interwiki-links like [[commons:...]] for sister projects similar to interlanguage links [[en:...]]

If such a runtime error occur then the folowing loader functions fail:

At German Wikivoyage we are using an additional JavaScript library, https://de.wikivoyage.org/wiki/MediaWiki:MapTools.js, which is calling ext.kartographer.box in a manner as described in the documentation. I switched it off, and the runtime error/exception occurred furthermore.

Both on German and English Wikivoyage branches you can look for pages which are linked to the mapframe template to find examples for check.

Yes, BN alias to drop without any replacement.

Replaced by its namespace name ("Benutzer" = "user") that means bn is no longer used as a namespace alias.

Now we have a community consensus. We replaced all BN aliases für NS_USER, too.

Today I ask the community to get a consensus to remove the namespace alias bn:

We should remove the namespace alias. It was never used. "user" can be used as a shorter alias, too. But the bn language code should work.

I think it makes sense to add also a zoom-level control property; not only in edit mode. See for instance https://github.com/azavea/Leaflet.zoomdisplay , http://azavea.github.io/Leaflet.zoomdisplay/ and T140210. This control should be presented on all maps by default.

The first image shows a map generated by the <mapframe> tag. The red arrows show the nearby and layers controls. The blue arrow shows the full-screen control. After clicking on it the map is magnified to full-screen mode.

• At Wikivoyage (Modul:FastWikidata) we introduced some helpful and simple functions with support of @thiemowmde.
• Searching for parent entities along a P31-P279 chain. Proposal: typeSearch( childId, idArray, limit ). childId is the entity id (or entity) to start the search. idArray contains P31 or P279 ids to look for. limit gives the maximum count of parent levels to search. typeSearch gives nil or a q id from the array. We need this search to get more general instances or classes. For instance: Q320366: we want to know that it is a train station (Q55488) instead of an interchange station (Q1147171).
• A similar question is to ask for a state (see above) or first administrative division starting from any location.
• We need a function providing an array with the first, n or all properties together with its qualifier values or ids. The qualifier itself is known. getPropertyWithQualifyer( id, p, q ). The result could be an array with items consisting of the value and a qualifier values array.

Thanks again to @Anomie for the profiler details. The fixes made by @thiemowmde could help to reduce the computing time of the Wikibase related calls from former 5000 ms to 900 ms now. I agree with thiemowmde to investigate further improvements in frame of T182147.

Example profile data given by @Anomie:

Today the computing time was similar to the values a few weeks ago. For https://de.wikivoyage.org/wiki/Halle_%28Saale%29, we have now 3700-3900 ms as compared to about yesterday's 8000 ms for 237 vCard templates. Comparing with other articles I estimated a computing time of about 11 ms for a vCard without Wikidata access and about 20 ms for a vCard with Wikidata access. The difference seems to be mainly attributed to mw.wikibase.getEntity( id ) calls.

@thiemowmde Of course I can wait until Wednesday/Thursday to test it again. The report will follow.

Thanks very much for your answers.

Thanks for adding me as a subscriber. The extension is working for more then ten years, at least in left-to-right wikis.

I thought about the marker pushpins themselves. If they are for instance yellow then it is difficult the read the pushpin inscription.

The problem occurs only for maps created by <maplink>. These maps are not yet available after loading a page but are opend by a user action.

At the German Wikivoyage we are using now a workaound. A better example can be found at:

Small correction:

Example:

The problem occurs only in maps built-in in articles (<mapframe>). The .thumbinner class adds a white border to all images. That's why both Kartographer tiles and pushpin markers have now a white border, too. This is a stylesheet problem and can be solved in the following manner:

It seems to be a duplicate of T176052.

The problem is cased by timeless header bar z-index. It can be solved with CSS.

Of cause we can run all Scribunto scripts within a pcall. But this is not comfortable because you will not get the cause of a run-time error.

Maybe you cannot imagine why to check so many images. Maybe have a look to the embassies section in https://en.wikivoyage.org/wiki/Washington,_D.C. Each embassy is presented by a listing template which could contain an image which is to check because it is not presented in the article but shown on a map if coordinates are present. The missing presence of images in the article is also the cause that you will not see a failure message.

Autonumbering and groups belong together for temporary selection of groups. In particular, this is useful for maps used in articles which are usually smaller than the full-screen mode.

The setting of the variables is necessary not only to enable maplink and mapframe tags but to enable the so called Wikivoyage mode. This mode allows the usage of the autonumbering feature with maplink as it was developed mainly for Wikivoyage. It adds the marker features including the deployment of additional Kartographer styles and Javascripts. At https://www.mediawiki.org/wiki/Extension:Kartographer these additional goals are described:

Thanks for your answer. We will check for the cause in the scripts and why these errors occurred only today.

Today we detected inexplicable Lua/Wikidata errors. Maybe they have the same cause like this described in this task.

Thanks. This script is helpful.

Please have a view to

Yes, I am really interested.

We cannot fix these modules, css and js files because they are free of errors. We cannot fix false positives. And we cannot fix modules because they use another content model.

Maybe it would be useful to remove all known false positives (modules, css, js) from the database. Because the wiki authors cannot do anything to remove them. By the way, at the German Wikivoyage more than 90 % of all linter messages are false positives!

It seems that there is no fast solution of this problem. Within the last month I made more than one thousand null-edits manually, and I did not get any support from the community. We need help to clear the Category:Pages_with_script_errors because we need this category for maintenance work. Now, this category is useless. Now I am checking the Linter errors, and you know: there is no support by the community.

Wikivoyage/de extensively uses Wikidata, for instance for marker, vCard and quickbar modules/templates. But a Wikibase Lua entity error is seldomly shown. Most of the articles shown in the category have neither error messages nor a tracking category.