Aug 26 2023
Jul 21 2023
Jul 17 2023
Jul 15 2023
Apr 25 2023
Maybe for some tests: At German Wikivoyage, the Articles "Halle (Saale)" and "Wien" use the biggest amount of Kartographer GeoJSON data, in Halle (Saale) about 180,000 bytes. I hope that the page rendering is a little bit faster with the blob at the end at least for these articles.
Apr 17 2023
At voy-de, MediaWiki:Gadget-Poi2gpx.js is using wgKartographerLiveData, too. But it is similar to MediaWiki:Gadget-MapTools.js.
@thiemowmde, I read your note. Only MediaWiki:Gadget-MapTools.js uses wgKartographerLiveData, and the gadget is called after complete load of the article by using $( mapTools.init ); at line 811. I hope that this is sufficient.
Mar 28 2023
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.
Mar 22 2023
A comment in order to avoid a misunderstanding:
Mar 21 2023
Feb 15 2023
Feb 7 2023
By the way, on Sunday I detected the bug T328866. It seems that the non-existing function map.addDataLayer is called in Map.js.
Feb 6 2023
@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.
Feb 5 2023
Feb 3 2023
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.
Jan 26 2023
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.
Jan 20 2023
Jan 17 2023
Nov 16 2022
The problem occurs on old Vector skin, too. But there are different behaviors on different wikis:
Nov 15 2022
Oct 31 2022
Aug 25 2022
Thanks for all.
Aug 24 2022
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.
Jul 29 2022
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.
Jul 28 2022
Jul 14 2022
Jun 6 2022
May 17 2022
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.
May 16 2022
May 7 2022
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.
Apr 10 2022
Dec 29 2021
Dec 13 2021
Nov 16 2021
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.
Nov 2 2021
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.
Oct 6 2021
Sep 8 2021
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.
Sep 7 2021
Sep 2 2021
Aug 25 2021
Contrary to Wikipedias, there is no obligation to use references in Wikivoyages. That's why there are big differences in usage among articles.
Aug 20 2021
Thanks for activating the previews.
Aug 19 2021
Aug 13 2021
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.
Aug 10 2021
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).
Aug 1 2021
Jul 22 2021
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.
Jul 21 2021
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:
Jun 10 2021
May 6 2021
Apr 17 2021
Mar 26 2021
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.
Mar 25 2021
I think I found the failure: it is a damaged / erroneous mw.text library, especially mw.text.split and mw.text.trim!
Mar 24 2021
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.
Mar 23 2021
The increase of computing time of the functions mentioned is about a factor of 30!
Feb 23 2021
At the German Wikivoyage, Reading preferences (Enable page previews (quick previews of a topic while reading a page)) are not available.
Dec 28 2020
See T267296, too
Nov 6 2020
Nov 5 2020
The map server returns a 404 error.