Page MenuHomePhabricator

Add maps support for marks with 3 digits
Open, Stalled, LowPublic


The autonumbering of maplink and/or <mapframe numberings stops with 99. This is not enough. As you can see at the numbering should go far beyond. I think the limit should be 999.

Please check autonumbering in case of letter-numbering.

This task was mentioned at Community-Wishlist-Survey-2017 (, which got the No.1 out of 214 proposals.

Event Timeline

Yurik closed this task as Declined.EditedJul 27 2016, 5:06 AM

This is a fairly difficult task to address: We are using "maki" icon set, which was specifically designed to be 1 or 2 digits, one letter, or one icon. Recently, the whole maki system was upgraded to target WebGL maps, which we haven't migrated to yet (it should allow us to build much more elaborate icons). Rebuilding the whole system of markers to support 3 digits might require too much resources, especially when there are not that many articles with that many icons, plus there is an easy workaround: the <mapframe> & <maplink> marks support multiple counters, so it is possible to simply show subset of markers (e.g. Restaurants, or those that belong to one area) as one color, with its own numbering, and another type of marks with a different counter and different style.

I will close this task for now simply because of how much resources it would require to fix it, but as always, any code contributions are welcome, and I will gladly review and merge them.

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.

I reopened this task because of social reasons.

@RolandUnger take a look at my explanation at -- search for 99 and keep reading afterwards. It is possible to work around this limitation (after all, not many articles hit it), and restructure the numbering so that instead of 1..999, you have several 1..99 of different color. We simply cannot easily solve this issue at the moment with the given resources for technical reasons (and I would love to be corrected on this one)

Yurik renamed this task from <maplink> and/or <mapframe>: autonumbering stops with 99 instead of at least 999 to Add maps support for marks with 3 digits.Jul 27 2016, 11:41 PM
Yurik triaged this task as Low priority.

This is a very hard to implement (due to external libraries support) feature. There is a number of ways to work around it, such as creating multiple groups of items with different colors. I will decline it for now.

Andyrom75 added a subscriber: Andyrom75.

Yurik sorry, but if a bug is difficult solve doesn't mean that the ticket should be closed.
The limit of 2 digits is a problem for several articles. The old icons worked well. If you want to implement a new icon set (Maki or whatever) is ok, but this choice shouldn't introduce limitations.
Let's keep the bug open since has been found a solution to this problem.

Maintainers of projects decide which functionality (and patches) they accept and which functionality they'd consider a bad idea and refuse.
T141335#2497952 states that code contributions are welcome to fix the problem. So I don't see any reason to decline this task (as maintainers are not against support for 3 digits). The task could have lowest priority while being open though.

Yurik removed Yurik as the assignee of this task.Oct 4 2016, 1:08 PM

@Yurik, since the the map is not working properly because of the 99-limit, in it:voy we are using the old map (see ) that show corretly all the numbers and cause no other probelm.
What we need, until this bug is fixed, is a way to show the correct number in the article (see where is the only point where is showed the wrong number. Since is not linked to the icon constraint, it shouldn't be an issue.

It should be enough to add a new parameter to #invoke:map (e.g. extendednumbers=yes) in order to overcome the 99-limit.
This temporary patch is very quick to implement ad would avoid any discrepancy in it:voy article.
Any other alternative patch is more than welcome.

Let me know if maintainers can work on this or not, otherwise I need to remove the use of this extension, until this bug is fixed.


@Andyrom75 are you proposing to make the number in wiki article differ from the number on the map itself?

@Yurik actually is the opposite.
The old map currently in use in it:voy shows number like 100, 101, 102, etc.
The number shown in the article (generated by the extension) are 99, 99, 99, etc.

I need that the number in the article will proceed naturally without any forced stop at 99.
This will align the number in the article with the one in the map.

See the article links that I've written in my previous message.

@Yurik, please let me know if you have understood the proposal or not.
In the second case, I'll be more than glad to explain it to you one more time.

Unitl the maintainers are not able to solve this bug, a dirty workaround is the following:

  1. Use the old map (i.e. the one based on simple numeric markers) and not the new one (i.e. maki icons based one)
  2. apply the following jquery patch: in MediaWiki:Common.js
		while( typeof $(this).attr('href').split('maplink/')[1] === "undefined" ){}

This patch will correct the numbers in the article aligning them with the ones shown in the map.


  • "while loop" is necessary to wait that the extension has finished to put the wrong numbers in the article.
  • "load function" avoid to start immediately the while loop

Clearly the same patch shall be applied on MediaWiki:Mobile.js in order to correct the same extension mistake opening a page on mobile view.

@Yurik, any update for the fix of this bug?

@Andyrom75 I wish I had an answer for you. It seems maki icons have gone a very different direction - they are now much better integrated into the client-side WebGL-based maps, and we might have to at some point to handle such high numbers either some other way, or figure out another solution all together. I am hopping to switch to the GL-rending at some point, but it might take some time to get there. Another solution would be for us to render custom icons, both for client and server side map generation, but then we will totally go in our own direction, which I have been trying to avoid at all costs to reduce software maintenance burden.

I understand the reason of your approach, and I agree that in a long term perspective is the right one.
Can the customized solution you mention be applied in the short term until the maki icons will manage correctly the three digits numbers?

Consider that in any case we must use a custom solution (server or client side) in order to avoid inconsistencies in our articles.

A custom solution would be best and more than 99 allowed; however, a possible work around is available, but it is rather specialized and not very intuitive for the average editor. I actually broke up the markers and used the type, group and counter parameters. My temporary test is found at which is a rehash of multiple vicinity markers numbering in the hundreds as found in All the POIs can be found on the geo map and mapframe
There are nuances and tricky situations that arose while I looked at this - anyhow just a thought I would add this to the conversation.

Matroc, thanks to try to find a solution to this bug/limitation that no one is willing to take in charge for its complete resolution.
In my opinion your approach would cause the creation of articles that in the future (when finally this extension would work) should be fixed and it would be difficult to find them.
The JS patch that I've mentioned above would be transparent for the editors.

Andyrom75 - I totally agree with you. We should have markers with at least 3 digits. Some of the article maps currently in Wikivoyage look terrible with so many 99 markers to say the least.
Not only would articles using my odd test approach be difficult to find when all is finally resolved later; it
would be difficult and counter intuitive for an average editor to figure out how to do this since he/she would need a deeper understanding of the templates, maps and the Kartographer extension in action.

Keeping things as simple, transparent and hidden is best.

MSantos changed the task status from Open to Stalled.Nov 1 2018, 3:14 PM
MSantos added a subscriber: MSantos.

Stalled until we can solve T145475: Update to latest maki

Minor point of information: the rendered PNG directory for 1-99 and A-Z, at all icon sizes, takes 3MB of disk space so probably a comparable amount of server memory. Caching all icons from 1-999 would therefore take something like 30MB, which is completely reasonable for a long-running server process.

Tagging because we're discussing this feature—no decision yet whether we'll implement it or not.

I'm sure there are optimizations to make, but a simple approach of dropping the font size from 11px to 8px to fit the three digits looks like this in the worst-case scenario (of "small" markers):

image.png (41×438 px, 6 KB)