Module talk:Location map

Module:Location map is indefinitely protected from editing, as it is a heavily used or highly visible module. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use {{edit template-protected}} to notify an administrator or template editor to make the requested edit.

This is the talk page for discussing improvements to the Location map module.

Add new text under old text. New to Wikipedia? Welcome! Learn to edit; get help. Start a new topic Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed

Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11Auto-archiving period: 12 months

To help centralize discussions and keep related topics together, several talk pages redirect here.

Text or other creative content from this version of Template:Location map/Creating a new map definition was copied or moved into Template:Location map data documentation/doc with this edit on 15 February 2024. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted as long as the latter page exists.

Hi. Look at this please: The entry

And these are the provided links in the entry: This, and this. Aminabzz (talk) 13:42, 27 February 2025 (UTC)Reply

Aminabzz, thank you for providing screenshots, which illustrate the issue.

Which articles are affected? When reporting such issues with template, please always include links to articles, where you've encountered the problem. —⁠andrybak (talk) 01:27, 4 February 2026 (UTC)Reply

@Andrybak Hi. Thank you. The article was 2024–25 UEFA Champions League. Of course, I think the issue is fixed now. Aminabzz (talk) 10:58, 4 February 2026 (UTC)Reply

I would like to propose an enhancement to Module:Location map that would allow for more precise label positioning. Currently, the module supports basic label positions (top, bottom, left, right), but does not include options for diagonal placements like northeast, northwest, southeast, or southwest.

• Expand the |position= argument to recognize and support:
  • northeast (ne)
  • northwest (nw)
  • southeast (se)
  • southwest (sw)

• Greater Precision: Labels can be positioned more naturally relative to markers, reducing overlap and improving clarity.
• Consistency: Many mapping tools and templates already support compass-based positioning, making this a logical extension.
• Improved Readability: This would allow editors to optimize label placement in cases where the default positions (top, bottom, left, right) do not work well.

• Modify the |position= handling in Module:Location map to recognize the additional options and adjust label offsets accordingly.
• Use a simple logic-based adjustment to move the label diagonally when a compass-based position is selected.

This enhancement would improve the flexibility and usability of location maps across Wikipedia. I welcome feedback and discussion on this proposal. Abhiramakella (talk) 23:42, 2 April 2025 (UTC)Reply

I would find this very helpful, particularly for locations that are very close to each other that the editor wishes to label. I would suggest alternatively that every label could have a certain "offset" parameter, in pixels, on top of the existing position parameter. This would specify the offset from a default position so editors could adjust the label to be anywhere they wish on the map. LivinAWestLife (talk) 18:41, 8 August 2025 (UTC)Reply

@LivinAWestLife: Adding some vertical offset to left- and right-positioned labels isn't too hard (Special:Diff/1305013356/1305042106). I don't think we need it for top- and bottom-positioned ones, and I'd advise against adding any left-right offset to those, as people tend to fine tune the absolute positions to what looks good on their screens, disregarding many other different devices and font sizes. The new parameter is top_offset, available in {{Location map/sandbox |top_offset=}}

Let me know what you think! Ponor (talk) 18:51, 9 August 2025 (UTC)Reply

Hi, this looks like it would be very useful, thank you! I hope implementing it wasn't very hard. I can understand why you wouldn't want to be able to fine tuning the absolute positions if it makes the display worse on certain screens. I will try it out now. LivinAWestLife (talk) 19:37, 9 August 2025 (UTC)Reply

This edit request to Module:Location map/styles.css has been answered. Set the |answered= parameter to no to reactivate your request.

Description of suggested change: the whole map section, including the caption, gets affected by the grayscaling effect on lines 66 and 79 in styles.css, which causes some weird coloring (see [1])

Diff:

əkrəm. 18:06, 13 May 2025 (UTC)Reply

 Done Izno (talk) 23:48, 23 May 2025 (UTC)Reply

 You are invited to join the discussion at Template talk:Wikidata location map § fallback default map vs. mapframe. -- Joy (talk) 15:26, 16 August 2025 (UTC)Reply

 You are invited to join the discussion at Template talk:MergedMap. -- Joy (talk) 12:36, 27 November 2025 (UTC)Reply

This map requires different coordinates for image and image1. I tried adding the top1/right1/... parameters (for the relief map) but they don't work. Maybe someone will be able to prepare a module with different coordinates for both images. Malarz pl (talk) 23:25, 29 December 2025 (UTC)Reply

Wouldn't it be easier to just crop File:Ternopil province physical map.svg to fit the boundary of File:Ternopil Oblast location map.svg? —⁠andrybak (talk) 01:33, 4 February 2026 (UTC)Reply

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

In the function markLabelDiv, append ":addClass'notheme mw-no-invert')" to the line that instantiates builder.

Right now, the font color of the marker label is inverted in dark mode, which makes it completely unreadable since the underlying image is not inverted. So either the image should be inverted or the font should not be inverted. I'm not sure whether the former is possible, so I think the simplest solution is to add the classes notheme and mw-no-invert to the label div, which cause it to remain black even in dark mode. Justin Kunimune (talk) 20:30, 30 December 2025 (UTC)Reply

Not done for now To avoid possible misinterpretation, please make the requested change in the sandbox, then check the test-cases. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:43, 31 December 2025 (UTC)Reply

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

Description of suggested change: Append ":addClass('notheme mw-no-invert')" to line 326, to ensure the label text color is not inverted in dark mode when using the WikimediaUI Dark Mode gadget, thus matching the behavior of the underlying image and ensuring good contrast.

I've implemented this in the sandbox, so you can see the improved behavior by viewing the test cases in a browser with dark mode the Dark Mode gadget enabled.

Diff:

Justin Kunimune (talk) 02:26, 3 January 2026 (UTC)Reply

Not done for now':' I don't see any meaningful difference on the test case pages with the standard dark mode. Please provide an actual test case that demonstrates the correction. Izno (talk) 23:41, 14 January 2026 (UTC)Reply

@Izno Ah, apparently the problem only appears in the WikimediaUI gadget version of dark mode, and not in the newer native version of dark mode. So you'll have to enable the gadget to reproduce it. Here's a screenshot of what I see for testcases#Croatia: imgur.com/a/OcsrmpA. Justin Kunimune (talk) 01:46, 15 January 2026 (UTC)Reply

So, we don't generally support that old gadget. I'd recommend disabling it. Izno (talk) 02:17, 15 January 2026 (UTC)Reply

Oh, I didn't know that. I'll do that. Is there a reason not to make this change, though? I imagine some users besides me probably still use the gadget, so it would benefit them, and adding these classes doesn't add much complexity to the module. Justin Kunimune (talk) 02:50, 15 January 2026 (UTC)Reply

I am fairly certain those classes have a meaning in the supported dark mode and I don't necessarily know if their meaning is the same. Izno (talk) 03:31, 15 January 2026 (UTC)Reply

Right now when you click on a location map, it takes you to the file page for the underlying map. I think this is really unintuitive and problematic for accessibility, as many users will want to enlarge the map. I think that instead, when you click on it, it should open an interactive Kartographer map. I've mocked up a new version of Location map that does this, as can be seen to the right.

Do people here think that would be a good change to make, or have alternative ideas for how it might work? For example, another user mocked up a version that enlarges the location map rather than opening a Kartographer map, but personally I like my version because I feel that it combines the best of Location map and Maplink: a clean hand-made map for small scales, and a more detailed interactive map for large scales.

Justin Kunimune (talk) 16:38, 11 January 2026 (UTC)Reply

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

Make it so that clicking on the image opens an interactive Kartographer map.

This is the change I described in #Making all location maps embed maplinks, which I've now implemented in the sandbox. I solicited feedback here and on WT:WikiProject Maps, and haven't heard anything for or against, so I'm presuming I have consensus until someone says otherwise.

You can check the behavior in the test cases. If you click on the sandbox version of the map you should see the Kartographer map, as opposed to the current version which takes you to the file page; otherwise as far as I can tell there is no difference in behavior. Editors won't need to change anything about how they use the template, but it does create three new optional arguments – maplink_marker, maplink_marker_size, and maplink_marker_color – which can be used to customize the appearance of the marker in the interactive map.

You can see the diff here:

en.wikipedia.org/w/index.php?title=Module%3ALocation_map%2Fsandbox&diff=1335901918&oldid=1330873844

As far as changes to the actual code, the main thing is that when the maplink argument is empty, I construct and preprocess a <maplink/> tag and wrap the image in it. I moved the part that parses the coordinate arguments into a separate function, getCoordinates, so that the same coordinates can be used in both the mark placement and Kartographer.

Justin Kunimune (talk) 21:48, 31 January 2026 (UTC)Reply

Regarding consensus: this change would affect ~700000 articles, i.e. ~10% of all articles on enwiki (see also WP:WPSIZE). Because of the potential impact, I recommend getting a wider consensus at Wikipedia:Village pump (proposals). I also recommend notifying Wikipedia:Village pump (technical) for possible technical ramifications.

The proposal is very concrete and actionable, which is good. I myself have been annoyed in the way File:Red pog.svg works, or rather how it does not. The user experience of clicking to see better and only opening the underlying map picture without any indicators is terrible indeed. —⁠andrybak (talk) 01:08, 4 February 2026 (UTC)Reply

Also, Template:MergedMap (found in a section above), which was in active development just a month ago, seems to be trying to solve a similar issue. A notification to editors working on it might be a good idea as well. To their user talk pages and/or at Template talk:MergedMap. —⁠andrybak (talk) 01:17, 4 February 2026 (UTC)Reply

Fair enough! I've left messages on Village pump (proposals) and the MergedMap talk page; I'll give it a while and see what people there think. I did bring this up previously on Village pump (technical); I got some advice there but no concerns relevant to the current proposal. Justin Kunimune (talk) 22:50, 4 February 2026 (UTC)Reply

Great, thank you! I've disabled the edit request for now. —⁠andrybak (talk) 23:13, 4 February 2026 (UTC)Reply

First of all, I love Kartographer, I've myself brought it to thousands of articles. Unfortunatelly, I don't think this is the way to go, at least not until Kartographer gets more layers, such as different terrain options. The red pog not appearing when you click on a location map shouldn't be too hard to fix, if people choose to do so. That's a bug. But clicking on a relief map, and getting something completely different is a WP:SURPRISE, so a NO from me. One day we'll be able to replace Location maps with Kartographer. Let's all support m:Community Wishlist/W323. Ponor (talk) 01:03, 5 February 2026 (UTC)Reply

@Ponor thank you for feedback. To avoid WP:DISCUSSFORK, please post it to Wikipedia:Village pump (proposals)#Make it so clicking on a location map opens an interactive Kartographer map. —⁠andrybak (talk) 01:06, 5 February 2026 (UTC)Reply

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

Make it so that clicking on the image opens an interactive Kartographer map.

I'm re-requesting the change described above, with some modifications. See the sandbox for the exact updated code that I'm requesting.

I posted this at Village pump (proposals), and I think we achieved consensus for implementing this (there was one voice of opposition, but the rest of the !votes and comments were all supportive). I did make two changes to my proposal based on that discussion:

• One user requested that there be a visual indication that clicking on the map will open a larger map, so I added a square button with a map icon , with the same styling as the full-screen button that mapframes have (I used a map icon instead of an enlarge icon since the large interactive map is different from the small one, so "fullscreen" is potentially misleading while "map" is still accurate). Like mapframes, you can click anywhere on the image to enlarge it, not just on the button. And the icon is now tagged as {{PD-shape}}, so it should be good to use without linking to its file page. It does cover up some of the map, which is kind of annoying, but I've rigged it to move to the left side when the marker is near the upper right, so it at least shouldn't ever interfere with the marker.
• I realized that removing the link to the map's file page is a problem for attribution, so I added a small link to the bottom right that says "Map credit" and links to the file page. Again, this is similar to what mapframes do.

While I didn't call this out last time, I should note that while all existing maps will work fine with this change without any action from any other editors, there are two new functionalities that infobox editors can use that I will note in the documentation if this change goes into effect:

• There are new tempate arguments to style the marker in the fullscreen Kartographer view: maplink_marker, maplink_marker_size, and maplink_marker_color. These work the same way as the marker, marker_size, and marker_color parameters in {{Maplink}}.
• There is a new optional argument for the data pages: publicdomain. If set to true, this suppresses the credit link in the lower right-hand corner. This can be used to reduce visual clutter for PD and CC0 maps that don't require attribution. It also works with alternative maps; you can mark image1 as PD with publicdomain1=true, you can mark image2 as PD with publicdomain2=true, and cetera.

See the test cases to see how the new button and credit link look. Note especially the maps of Brčko and Uelen where you can see the button move to the left to make space for the marker.

Justin Kunimune (talk) 22:45, 23 February 2026 (UTC)Reply

 Done * Pppery * _{it has begun...} 03:00, 5 March 2026 (UTC)Reply

I have reverted this since it broke things at 2026 Iran war ("Lua error in Module:Location_map at line 223: attempt to compare number with nil.") * Pppery * _{it has begun...} 03:23, 5 March 2026 (UTC)Reply

@Justinkunimune: Feel free to reactivate once you've fixed your code. * Pppery * _{it has begun...} 03:26, 5 March 2026 (UTC)Reply

@Pppery: Sorry, I forgot to check how my changes would affect {{Location map+}}, as it imports one of the functions from this module. I've fixed it in the sandbox; I had to move some code around which makes the diff annoyingly large, but now each function can be called independently, I see no problems on either Template:Location map/testcases or Template:Location map+/testcases, and there are no more errors in my sandbox where I reproduced the issue. Justin Kunimune (talk) 02:30, 6 March 2026 (UTC)Reply

Question: Why not replace maps that use this module with Template:OSM Location map? Assadzadeh (talk) 03:40, 5 March 2026 (UTC)Reply

I would generally support that, but it doesn't look like it's a direct drop-in replacement, so I think it would be a lot of work to replace all instances. Also, {{Location map}} has some nice features that Kartographer doesn't (like the ability to use any map image, and the ability to use any map projection), so there may be cases where changing to {{OSM Location map}} would be undesirable. The advantage of this change is that it adds functionality onto existing maps without otherwise changing them or requiring any action for infobox editors. Justin Kunimune (talk) 02:36, 6 March 2026 (UTC)Reply

(I do not generally re-implement requests after my own edit needs to be reverted for breaking things; someone else is welcome to handle this) * Pppery * _{it has begun...} 14:23, 11 March 2026 (UTC)Reply

 Done --MikeVitale 14:14, 20 March 2026 (UTC)Reply

Reverted again, as it was now causing "Lua error in Module:Location_map at line 191: No value was provided for longitude." on multiple pages. The first maps I was looking at was The Ashes#Match venues, so maybe you could start from there? Zzyzx11 (talk) 14:42, 20 March 2026 (UTC)Reply

Heck, sorry. I see the problem. In addition to {{Location map+}} which imports this module via #invoke:, Module:Location map/multi also imports this module via require() (specifically it calls top() to generate the base map, but without a latitude or longitude since there are multiple sets; I've now set it to safely skip over the embedded maplink code when this happens). I've searched for all modules that require this one, and there seem to be two: Module:Location map/multi and Module:Infobox military conflict.

I've fixed that problem, and I've set both those modules' sandboxes to point toward Module:Location map/sandbox instead of Module:Location map, meaning that Template:Location map+/testcases and Template:Infobox military conflict/testcases should now fully reflect this change; I see no problems on either. I also created my own copies of both under Module:Sandbox/Justinkunimune which import each other, and both work fine in my sandbox. Justin Kunimune (talk) 12:25, 22 March 2026 (UTC)Reply

There's now a separate edit request being mocked up in the sandbox. I don't want to conflict with that, so I'm moving my version with the embedded maplink to Module:Sandbox/Justinkunimune. I'll keep it up to date with the current state of the module so that it can be copied and pasted in here, until this request is either completed or denied. Justin Kunimune (talk) 01:00, 27 May 2026 (UTC)Reply

Not done for now: Does not seem there is consensus for this change to happen. Stale for over a month. If there is new information or new cause to discuss, you are free to reopen this request with that new information. Zackmann (^{Talk to me}/_{What I been doing}) 03:51, 30 June 2026 (UTC)Reply

For example, how can I use File:Central Europe location map 2.svg in {Location map many | Europe}? --Altenmann >talk 22:51, 14 February 2026 (UTC)Reply

More generally, can I specify top+bottom+left+right coordinates to display only a part of a standard locator map? --Altenmann >talk 22:51, 14 February 2026 (UTC)Reply

I don't think there are options for that in the template. You'll have to create a new data page with the new coordinates. See Template:Location map/Creating a new map definition. Justin Kunimune (talk) 22:58, 14 February 2026 (UTC)Reply

So |AlternativeMap= is the one parameter I see here that does not conform for MOS:INFOBOXNAME... Namely the param should be |alternative_map=. Now obviously with so many uses, not going to remove the existing... But any objection to allowing for the arguably correct form of the param to also work? Zackmann (^{Talk to me}/_{What I been doing}) 00:50, 22 February 2026 (UTC)Reply

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

It says "Lua error in Module:Location_map at line 223: attempt to compare number with nil." I don't know Lua, so that's all I can say really, sorry. Raskuly (talk) 03:22, 5 March 2026 (UTC)Reply

Fixed. * Pppery * _{it has begun...} 03:23, 5 March 2026 (UTC)Reply

The magnify icon currently has broken markup. For example, the Yellowstone map on the documentation page has:

<div class="magnify"><a href="/wiki/File:Usa_edcp_relief_location_map.png" title="File:Usa edcp relief location map.png">class=notpageimage| </a></div>

This is the corresponding code in the module:

retval = retval .. '<div class="thumbcaption"><div class="magnify">[[:File:' .. getContainerImage(args, map) .. '|class=notpageimage| ]]</div>' .. args.caption .. '</div>'

Opencooper (talk) 08:29, 9 March 2026 (UTC)Reply

Pinging Elli, who added the parameter in this edit. The issue seems to me that, unlike the other places in the code with that parameter, the [[:File: code is not image syntax, but link syntax, so the class= gets interpreted as piped wikilink text. The solution would be to add that class to the generated link directly somehow.

Though the class probably isn't even needed at all here since the magnify icon is unlikely to ever get picked as a page image over the map it follows. Opencooper (talk) 09:12, 9 March 2026 (UTC)Reply

@Opencooper you're totally right, I didn't notice those were links and not images... sorry! I've changed the line now. Elli (talk | contribs) 15:51, 9 March 2026 (UTC)Reply

Thanks! I've confirmed the markup looks good now. Opencooper (talk) 16:08, 9 March 2026 (UTC)Reply

The documentation for {{Location map}} says that |caption= "will cause the map to be displayed with a frame", and many examples there show framed maps. However, this currently does not seem to work in articles. Moreover, if you click "edit" on "Template documentation" and then "Show preview" (without making any changes), all the frames are gone, and some maps that were right-floating become not floating at all. Apparently, something was broken recently. Please check and correct. — Mikhail Ryazanov (talk) 23:51, 21 May 2026 (UTC)Reply

It works fine for me, including when I edit and preview the template documentation. It might be an issue with previewing on your browser, or maybe something to do with the particular skin you're using.

Here are some captions/frames I added just now in my Sandbox: User:Justinkunimune/sandbox#Plain Location map. Justin Kunimune (talk) 11:26, 22 May 2026 (UTC)Reply

Well, after trying to see what really happens, I found at least that the module uses the class tright, which is deprecated and since ~yesterday is dropper from the CSS by default (see phab:T426452 and this commit). More curious is that the class thumbinner is also not defined when I do the preview. Manually removing these two in the browser developer tools makes the rendered documentation appear broken the same way as I see in the preview. So for tright, it definitely must be replaced in the module code by floatright (and similarly for all other alignment classes), but I didn't dig deeper regarding thumbinner. — Mikhail Ryazanov (talk) 05:33, 23 May 2026 (UTC)Reply

@Izno: I see that you have edited this module before and are subscribed to the mentioned ticket. Could you please take a look at these problems? — Mikhail Ryazanov (talk) 04:44, 24 May 2026 (UTC)Reply

It was IDd at WP:VPT so you might want to add an annoyed comment there. There are enough modules and templates that I don't want to handle this by my lonesome, per se. Izno (talk) 20:33, 24 May 2026 (UTC)Reply

@Jonesey95: thanks for updating the alignment classes. Could you please also take a look at the thumbinner problem? phab:T426452 has a recent comment referring to mw:Parsoid/Parser Unification/Media structure/FAQ, which seems relevant. — Mikhail Ryazanov (talk) 10:27, 26 May 2026 (UTC)Reply

I don't know anything about thumbinner, and the ticket doesn't really explain it to me. Maybe someone else here will understand. – Jonesey95 (talk) 13:23, 26 May 2026 (UTC)Reply

Currently the display is extremely bright for night mode and any point made on the map becomes essentially invisible. The div forces a white background and black frame which overwrites any browsers night mode. Here's a fix:

<div style="background-color: var(--background-color-base, #ffffff); border: 1px solid var(--border-color-base, #000000); padding: 2px; margin: 0 auto; text-align: left; width: 260px; position: relative;">

I'm not fluent in wikitext so let me know if I'm missing something here.

Dunkleosteus77 (talk) 23:37, 25 May 2026 (UTC)Reply

Looking at adding Module:Check for unknown parameters to this Module and its templates. Running up against a few issues that I want some feedback on before proceeding. As this has multiple entry points ({{Location map}}, {{Location map~}}, {{Location map+}}, etc.) I am wondering the following:

1. Does it make more sense to implement this on each individual Template or should it be implemented in the module as I have started to test out in the Module:Location map/sandbox?
2. Should each template have its own tracking category? (i.e. Category:Pages using location map with unknown parameters, Category:Pages using location map~ with unknown parameters, Category:Pages using location map+ with unknown parameters, etc) or can all these co-exist in one category?

@Frietjes, Pppery, Izno, Jonesey95, and Hike395: and anyone else, please share your thoughts! Zackmann (^{Talk to me}/_{What I been doing}) 23:52, 26 May 2026 (UTC)Reply

Anyone have any thoughts? Zackmann (^{Talk to me}/_{What I been doing}) 20:31, 28 May 2026 (UTC)Reply

The location map in the link https://es.wikipedia.org/wiki/Segunda_Federaci%C3%B3n_2025-26#Grupo_I is 500 pixels wide. On a mobile browser the map is not scrollable and parts of it are hidden from view. How could the map be scrolled? ~2026-32427-52 (talk) 06:13, 31 May 2026 (UTC)Reply

I have started a discussion here about a proposal to refactor the way Template:Location map works in Infoboxes. PLEASE join the discussion. Need lots of feedback on this one. Zackmann (^{Talk to me}/_{What I been doing}) 17:40, 22 June 2026 (UTC)Reply

Moved from Wikipedia:Village pump (technical) § Proposal to refactor the way Template:Location map works in Infoboxes

 – Zackmann (^{Talk to me}/_{What I been doing}) 19:55, 23 June 2026 (UTC)

I have long been kicking around the idea of refactoring the way that Template:Location map works specifically in infoboxes and want to solicit some feedback on the idea.

The problem

Every implementation of pushpin maps in an Infobox is different. There are numerous different parameters used to define the base map including: |map=, |pushpin_map=, |location_map=, |locmapin= and |map_type=. This makes it very difficult to go from one Infobox to another as you never know what parameters to use. The same issue applies to other aspects of the pushpin map such as the label, caption, label position, relief, etc. If you compare this to Template:Infobox mapframe, every single Infobox that uses a mapframe uses the exact same parameter names. Want to change the marker? That will always be set via |maprame-marker=. The zoom? Always |mapframe-zoom=. Doesn't matter what Infobox you are on.

A solution

What I would like to do is create a new entry point to Module:Location map, probably {{#invoke:Location map|infobox_location_map}}, that would allow for calling the location map (aka the pushpin map) in an Infobox and keeping the parameter names the same across every Infobox. That way, whether you are using {{Infobox settlement}}, {{Infobox airport}} or {{Infobox military installation}} the parameter names would all be the same. Just like Template:Infobox mapframe, I would also create a template for documentation (see {{Infobox mapframe/doc/parameters}}) so that documentation would be consistent across Infoboxes as well.

Implementation

Make no mistake, this would be a HUGE undertaking. It would involve refactoring close to 100 templates and then doing bot runs to clean up the hundreds of thousands of transclusions of those templates. Setting aside how much work it will be for a moment (and I am happy to undertake these clean ups...) my question is: "Is it worth it"? Is achieving consistency across Infoboxes and making it easier to go from one Infobox to another worth the effort here? I would argue it absolutely is, but I want to hear other inputs.

Courtesy pings: Joy, JMF, Jonesey95, Hike395, Primefac, Gonnym, Jessicapierce, GreenLipstickLesbian, Johnuniq, Phuzion, Plastikspork who I feel may have opinions on this, but of course ALL inputs welcome!! --Zackmann (^{Talk to me}/_{What I been doing}) 17:39, 22 June 2026 (UTC)Reply

On the subject of whether it's worth it: Templates are a tool to ensure that we have consistency between articles. There's a reason we have a standardized infobox module that we use. There's a reason we use {{cite web}} when referencing web sources. I think it makes sense to have consistency between similar templates, especially when those templates are doing the exact same thing. An editor should not need to know 10 different ways to invoke a map just because they work across multiple areas of expertise on the project. As an example, if I'm working on the infobox of a racetrack and then a church later in the day, I shouldn't have to know that the racetrack infobox uses {{{track_map}}} and the church infobox uses {{{monastery map}}}.

Based on a few recent instances of negative reactions to some template changes, I can safely predict that there will be at least some opposition to some of these changes. I think that the burden will be on us as template editors to prove why the new standardized map systems will be better. We should prove to them why it's worth re-learning how to use the templates that they're accustomed to, and why they should support the cleanup effort that will ensue after said template change occurs.

If this is implemented, I think something that will ease the maintenance burden moving forward is very clear wording in previews that says "You have used {{{old parameter}}}, which is no longer supported, please use {{{other parameter}}} instead." The current wording of "deprecated parameters" is somewhat unclear to an amateur editing an infobox. In unknown parameter cleanup, we see this somewhat often. Someone sees a parameter named {{{foobar}}} and wants the label on it to read Foobars, not realizing that the {{{label}}} has {{Pluralize from text}} applied to it. They change {{{foobar}}} to {{{foobars}}} and the article gets chucked into an "unknown parameters" maintenance category.

As always, I'm here to offer my bot in support of any cleanup work that needs to be done after the fact. phuzion (talk) 18:10, 22 June 2026 (UTC)Reply

Well as one of the editors who has had suffered a right royal pain in the ass every time I have tried to make what seemed a trivial change to the mapping in an infobox, I totally endorse this proposal. 𝕁𝕄𝔽 (talk) 18:40, 22 June 2026 (UTC)Reply

@JMF: this one is for you Zackmann (^{Talk to me}/_{What I been doing}) 18:52, 22 June 2026 (UTC)Reply

Can't argue with the logic here, happy to do bot runs as needed. I'll keep an eye on this discussion. Primefac (talk) 21:03, 22 June 2026 (UTC)Reply

I think this makes sense, but I feel like I'm missing something about the implementation. Why does this require a new entry point to Module:Location map? Isn't this just a matter of editing the templates to use consistent parameter names?

Also, separate from that question, template parameters have aliases sometimes, right? To ease the transition, would it make sense to set it up so that editors using each infobox template can use either the old parameter names or the new standardized parameter names? Justin Kunimune (talk) 22:12, 22 June 2026 (UTC)Reply

@Justinkunimune: I have not yet dived into the code so a new entry point may ultimately not be needed. The tricky part is how to make this new idea work without breaking anything else. That is why I might opt for a new entry point so that I can use the existing code but also customize it to fit. Gotta make sure that uses of {{Location map}} that are not in an Infobox continue to work when this is all done. Not 100% certain as to the how just yet, but I have a number of ideas.

As to your second question about aliases, that is 100% accurate and exactly how this will work. If we move forward with this, once the coding is done and we start the roll it out, we will deprecate the old parameter names in favor of the new names that are decided upon. Then we will do a bot run to clean them all up and only then will the old existing aliases be removed. Translation: at NO POINT should any pages be affected for the reader. This is all backend code refactoring that would only be a noticeable different if you are editing. Zackmann (^{Talk to me}/_{What I been doing}) 22:18, 22 June 2026 (UTC)Reply

What about removing pixel map size while you are at it? MOS (manual of style) already says that images are supposed to be default size.

Images could be under 250px size. (250px is the default image width) An sub 250px image would be more likely as an non-free image.

I do not see an map being smaller than 250px wide. I ran an SQL query for an sub 250px image on commons with "map" in the name, and gave up once it had ran for 15 minutes. Mapframe would not be smaller than 250px as it uses maptiles. You would want to support countries like Norway and Vietnam that are thin and long, but that is what upright is for. See also Module_talk:InfoboxImage/Archive_2#Help_with_improving_default_image_sizes for an previous discussion. Snævar (talk) 23:35, 22 June 2026 (UTC)Reply

@Snævar: I'm wary of removing functionality as part of this changeover. In my experience, when you mix a refactor with actual substantial changes, the project collapses. Someone objects to the change and so the refactor never occurs. While I don't disagree with your point about size vs upright, I would note that almost every Infobox has a |image_size= still.

That all being said, this changeover will make the eventual removal of |pushpin_map_size= much easier as all we have to do is remove support from the new entry point for this and poof, all transclusions no longer use it. I just think that removal warrants further discussion. Zackmann (^{Talk to me}/_{What I been doing}) 23:43, 22 June 2026 (UTC)Reply

The technical details here are a bit over my head, but I'm extremely in favor of standardizing and simplifying things like this. Sounds like it would take some work up-front, resulting in things being more streamlined in the future. I'm all for it. Jessicapierce (talk) 01:42, 23 June 2026 (UTC)Reply

NOTE: @Snævar, Justinkunimune, JMF, Phuzion, Primefac, and Jessicapierce:: I have moved this discussion, please update your watchlist if you wish to follow the discussion. Zackmann (^{Talk to me}/_{What I been doing}) 19:55, 23 June 2026 (UTC)Reply

As there seemed to be interest in this solution, I have started working on it in the sandbox: Module:Location_map/sandbox#L-514. Far from done, but making great headway.

• To see how it will be implemented versus the current solution, you can look at Template:Location map/infobox testcases/infobox
• I have setup some testcases for this at Template:Location_map/infobox_testcases which specifically compare how this currently displays versus how the new function will display. PLEASE add more testcases if you can think of any!

--Zackmann (^{Talk to me}/_{What I been doing}) 20:02, 23 June 2026 (UTC)Reply

What do people think of the parameter names I have chosen? |pushpin_map=, |pushpin_caption=, etc... Zackmann (^{Talk to me}/_{What I been doing}) 20:55, 23 June 2026 (UTC)Reply

One thing I'd like to see is the infoboxes accepting raw coordinates, not just the output of {{Coord}}. The VAST majority of articles in Category:Pages with script errors before I just cleaned it out were caused by editors putting raw coordinates into the infobox. I put some code in Module:Coordinates/sandbox that can do the parsing, that could could either be integrated into Module:Location map or that module could just call Module:Coordinates to do the parsing. --Ahecht (TALK
PAGE) 21:02, 24 June 2026 (UTC)Reply

I have no objection to this idea, but I feel like it is outside the scope of what I am trying to achieve here... That can be done from within the existing module and will fix things across the board. All for it, but don't want to make that part of this project... Zackmann (^{Talk to me}/_{What I been doing}) 21:13, 24 June 2026 (UTC)Reply

Without any objection I will be starting to roll this new methodology out in the coming the days. Can always improve on it later! Zackmann (^{Talk to me}/_{What I been doing}) 21:06, 26 June 2026 (UTC)Reply

Support this whole idea. I also agree that the parameter name change should be without any other changes (even if that means two bot edits), as we need to give people less reasons to oppose this. Gonnym (talk) 09:05, 30 June 2026 (UTC)Reply

So I found an issue with what I have implemented... In short, {{location map}} automatically pulls coordinates from Wikidata when no other coordinates are supplied. This only works on articles with existing Wikidata coords (I could not find a supported |qid=... param that works for testing). So If you go to New York City and add the following to the top of the page: {{Location map|World}} {{Infobox tree|pushpin_map = World }} you will see the first one produces a map, the second one does not. So I need to add a call to Wikidata. Will get on this tomorrow.... --Zackmann (^{Talk to me}/_{What I been doing}) 05:13, 16 July 2026 (UTC)Reply

Fixed Zackmann (^{Talk to me}/_{What I been doing}) 02:35, 17 July 2026 (UTC)Reply

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

Please remove the coordinates (latitude and longitude) with no given values in lines 425 and line 426 Rangoon creeper (talk) 06:19, 13 July 2026 (UTC)Reply

 Not done: Those checks are there for a reason and you have offered no reason for why they should be removed. Zackmann (^{Talk to me}/_{What I been doing}) 14:43, 13 July 2026 (UTC)Reply

Sorry, I was in a hurry to go somewhere,and please correct me If I am wrong, but the coordinates with no given values are the reason why the map does not display properly, which is why I asked if they could be removed, so sorry if I caused a misunderstanding. Rangoon creeper (talk) 08:50, 14 July 2026 (UTC)Reply