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.

By doing nothing, hovercards are working now well again.

The extension was deployed but the bug was not yet resolved.

Module pages have no wikitext content model:

You should not lint module pages with wikitext contentmodel. At Wikivoyage/de bogus-image-options were given for lua source code.

At the German Wikivoyage we use it mostly in the User namespace because there is no substitute. This should be discussed with the Wikidata team to add such a functionality adding additional items to the "Other project". I ask for such a topic at https://www.mediawiki.org/wiki/Topic:S4zoh1qx8zs2t1qq but we could not find a solution.

Thanks for the hint of task T141304.

I think it is useful to upload the Maki icons to Wikimedia Commons in several colors, at least in both black and white, to use them in text referring to the map.

• I think we will solve the problem to show {{mapframe}} both with markers and traces in the articles. I will play a little bit at my playground because it is a beta feature and will inform you at the pub if it is working well. I am not sure if there will be an automatic way to include traces to the articles. Therefore we should use intuitive file names and categories at Commons to find these Trace data easily. Of course we will loose this automatic way but on the other hand we can add several traces on several maps in an article, and we can use the same map data in different articles.

The problem described can be solved at Wikivoyage/en itself. The GPX traces must be converted to GeoJSON files and stored at Wikimedia Commons. I made it for instance for the Cerchiara di Calabria map. Kartographer already supports lines and polygons. Examples realized can be found at WV/de lounge. The (Edit GPX) link can easily renamed to Edit GeoJSON and redirected to Commons.

We are using this #geoLink hook to link efficiently to the Mapsources special page to prevent multiple template calls of coordinate conversion functions.

The wfgeoLink function hook in MapSources.hooks.php was removed without telling this to the community. Why you did this? This hook was used in our articles about 30.000 times at the German Wikivoyage to display the coordinates and link to the Mapsources special page! Now all is destroyed! See for instance the indicators on the articles!

The wrong wgKartographerLiveData GeoJSON code is still existent.

Today, all wgKartographerLiveData are wrong as shown below and, therefore, no map is shown.

Now, Template:Ficha_de_entidad_subnacional was also fixed.

All OpenStreetMap templates adapted.

I updated the template https://it.wikivoyage.org/wiki/Template:OpenStreetMap at the Italian Wikivoyage. Unfortunately, I am not an admin at the other Wikivoyage branches to change the coding.

Same as T141335

Unfortunately, I confused tooltip with popup window. But there is a bug in the tooltip window, too. Ampersands are shown as &amp;. For instance, the company Gaddis & Co. becomes Gaddis &amp; Co.

The reader should be able to add a map marker of his own position as given from his device mostly a mobile phone. Thus he could better orientate himself. Of course this must be done by an opt-in process. Therefore a button is necessary to perform this.

I analyzed the map popups, and I hope to give you some advice. At the Wikivoyage maps there are two popups with different properties (local and nearby markers). Both popups have no close button.

I will analyze this problem. I think CSS rules would help.

There are several articles an German Wikivoyage numbering far beyond 99. Some authors authors getting ugly looking on the malfunctions. The tools used until now were able to deal with numbers until 999 and with mixed letterings, too. I do not see any technical difficulty. Maybe we had to change the marker symbols. Until now we are using mainly rectangular markers which could increase in size.

This should include a map mask, too.

Yes, I think about "marker-symbol":"h", "marker-symbol":"h5", "marker-symbol":"2a" or "marker-symbol":"25". It is not yet working. An error message occurs. The usage of user-specified values is not specified in the extension description/help, too.

In November 2014 I asked to run updateArticleCount.php or a similar tool regularly. This is necessary on all Wikivoyage sites. This is because of the small number of articles and the unsolved Bug T42009. I think a weekly update would be sufficient.