It is well known, that OSM ways and areas could be defective. But they are shown on OpenStreetMap. Maybe more fault-tolerant functions are used at OSM as compared to these of Wikimedia. If a relation is an area maybe the shape can automatically be closed.

Missing Lua documentation is a big problem, see T225497, too.

A similar problem was described in T225592.

A similar failure was described in T215641.

It seems that the same problem occurs with geoline service.

Error messages from console:

A side effect is that the WMF's JavaScript code which organizes the creation of dynamic maps fails because it didn't check the result retrieved. At the German Wikivoyage we have two different results. One the one hand a static or missing map with WMF's script and a mainly working dynamic map after pressing the magnify button which creates a map by our tools. The map is shown with all working OSM objects and do not show all broken OSM ones.

I propose the following solution: to add weekday classes like sundays to all table cells. Then css styles can be easily added to every day of the week not only for sundays.

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.