Template talk:Infobox settlement

enable mapframe wherever pushpin_map is specified, but no other map

So, currently we have mapframe enabled wherever no map is specified. The rollout went fairly well, we patched up various syntax errors, and I've seen zero reader complaints about having the mapframe enabled.

Because the pushpin maps are generally used to give a more general overview (small dot in a large area), while the mapframes by default zoom in at coordinate type level, it would make sense to try showing both.

We'd continue to skip mapframe by default if any sort of image map is specified.

I suspect we'd have to deal with a smattering of new syntax errors, but beyond that, the readers would be by and large happier to have this. --Joy (talk) 10:40, 17 June 2025 (UTC)

Sounds good, but may want to check whether users are already adding mapframe maps manually either by placing {{infobox mapframe}} <mapframe> code via the |image_map (which you mention), |module or indeed any other parameters. An insource search should find examples. Regs, The Equalizer (talk) 00:14, 18 June 2025 (UTC)

This may be a bad idea. Infoboxes are often used on very short pages. Having a second map automatically appear can push other infobox information below the bottom of the article content, which makes the layout look bad and may lead to readers ignoring the information. We should be careful about infobox length bloat. — hike395 (talk) 03:40, 18 June 2025 (UTC)

Any infobox content, such as a picture or a map, next to a short stub is going to make the layout look imbalanced. That is the nature of having a very small amount of content, surely?

We're not going to affect the general concept of stub content being short by adding generally helpful information to the infoboxes. These things will remain orthogonal.

Who are these readers who depend on information in an infobox, but can't figure out when there's a need for vertical scrolling to see more? Which part of the internet teaches them not to scroll? Honest question, because we seem to be neck deep in scrolling these days :)

I tried to come up with an example for what you seem to be describing, so I skimmed randomly through Wales geography stubs for a while, but the best I could find was Gendros - where someone added a map manually near the bottom. D'oh.

So I gave up on that method and tried a search like incategory:"United Kingdom geography stubs" hastemplate:"Infobox settlement" and that quickly found Walton (grounds).

On my desktop browser, that infobox at Walton grounds gets cut off at "Region" already. Not sure how an extra map would change anything substantial here, it would just get cut off at a different visual element, but it would be equally as obvious that you have to scroll down to see more.

I checked the same stub on my mobile browser, and most of the screen was taken up by Wiki Loves Earth already :) and the infobox only showed the title. Still, that was enough to visually indicate that there's a box there and scrolling would show more. When I pressed the (X) on the banner, it rendered up to half the existing map. It was likewise pretty obvious you have to scroll down.

Coming back to the example of Gendros, my mobile browser, without the top banner, showed the infobox down to "Post town". After the box, there was a paragraph, and then the map, and then another bit of content. Based on that, I don't quite see what would be the downside of integrating that map into the infobox there, either.

So I'm at a loss as to what the actual concern is here. Could you please elaborate? --Joy (talk) 15:02, 18 June 2025 (UTC)

We don't need more stuff added by default to infoboxes! • Sbmeirow • Talk • 06:59, 18 June 2025 (UTC)

Could you explain why, please? --Joy (talk) 15:03, 18 June 2025 (UTC)

Agree we definitely don't need more files... A page like New York city has 17 images in the info box we definitely do not want to force more to be open.... thus causing even more accessibility problems by sandwiching everything down to the wrong section or in between the info box and left angle files. Moxy🍁 22:21, 23 June 2025 (UTC)

@Moxy The article New York City already has an image_map with an embedded mapframe already. There would be no change in that case. --Joy (talk) 06:52, 25 June 2025 (UTC)

New York City is the bad example in my view. I prefer Toronto format .....still mass minni image spam....but only one map with option for someone interested to see others with click. City infoboxes are the examples people use when talking about infobox bloat. Moxy🍁 06:19, 27 June 2025 (UTC)

Toronto has a image_map with an embedded mapframe made collapsible, behind a {{hidden begin}}. That is doable in the defaults as well. --Joy (talk) 07:37, 27 June 2025 (UTC)

Why is pop density displaying?

Working on a clean out of Category:Pages using infobox settlement with unknown parameters (0) and came upon Sterkenburg. I can’t figure out why the population density is not displaying. Can anyone help me out? What am I missing?

Sterkenburg
Area
• Total	24 km2 (9.3 sq mi)
Population  (637)	12,580

{{Infobox settlement
|name                   = Sterkenburg
…
|area_total_km2         = 24
|population             = 12580
|population_as_of       = 637
|population_density_km2 = auto
…
}}

—Zackmann (^{Talk to me}/_{What I been doing}) 21:46, 18 September 2025 (UTC)

@Zackmann08: it's |population_total= Ponor (talk) 22:11, 18 September 2025 (UTC)

Interesting. So it will display |population= but only do the calculation on |population_total=? Zackmann (^{Talk to me}/_{What I been doing}) 22:46, 18 September 2025 (UTC)

As far as I can tell:

• |population= was added in September 2009 after a single talk page posting with no responses.
• It does not appear to have been documented or fully integrated into the rest of the population display and calculations.
• It was semi-complained about in 2010.
• I'm guessing that it wasn't used very much at first, since a request to remove an obvious closing brace after the number was filed in 2013.
• I did not see any mentions of it in the talk page archives after 2013.
• It is used in only 2,900 articles.

IMO, adding it was a mistake, it was never integrated correctly, and it should probably be formally deprecated with a tracking category, converted to population_total or some other sensible parameter in each article, and then removed. – Jonesey95 (talk) 00:33, 19 September 2025 (UTC)

I think deprecating it and adding a tracking category sure sounds like the way to go! —Zackmann (^{Talk to me}/_{What I been doing}) 05:42, 19 September 2025 (UTC)

Change to display of native_name

So I’m testing out a change to how |native_name= is displayed. If both {{{native_name}}} and {{{native_name_lang}}} are defined, my thinking is to call {{native name}}. This template wraps it in the proper span tags but also outputs a helpful link to the language in question. IMHO this is a much nicer user experience than just displaying the name in some unknown language. I have setup a couple of testcases and would love some feedback… —Zackmann (^{Talk to me}/_{What I been doing}) 05:42, 19 September 2025 (UTC)

I don't have time to look right now, but poke around other infobox templates to see what they do. I am almost sure that there is code that you could copy from somewhere, which will prevent a later editor, or maybe you, from coming back later to say "why can't we standardize how this works?" – Jonesey95 (talk) 23:12, 21 September 2025 (UTC)

Question about multiple images

Hello! I have a question about the template, I hope this is the right place to ask, it’s about this segment specifically:

“For large urban areas, the template is often used in place of a single image to create a collage of the settlement's skyline and several notable landmarks.”

I was wondering if there was any guidelines about when multiple images vs. a single image can/should be used. For example I currently have an article: Capreol where I have added multiple images, but it is not a large urban area. Platttenbau (talk) 12:24, 22 September 2025 (UTC)

wikidata data

hello

please why the infobox not take the information automaticlly from the wikidata sources like the french infobox

thanks Othman.ifni (talk) 19:34, 22 September 2025 (UTC)

This template does retrieve some information from Wikidata, including coordinates that generate a mapframe map. You can see a list of retrieved items in the box labeled "This template uses the Wikidata properties". This 2018 RFC limits what can be pulled from Wikidata. – Jonesey95 (talk) 12:55, 25 September 2025 (UTC)

False positives in Category:Pages using infobox settlement with no map

Pachi, Kerman shows a mapframe map because it has Wikidata coordinates, but it is a member of Category:Pages using infobox settlement with no map and Category:Pages using infobox settlement with no coordinates. Some ambitious person could probably update the template's code to limit the population of those categories to articles that are truly missing click-through maps that use available coordinates. It might get a little tricky: check for edge cases like Pacajá, which has Wikidata coordinates and a picture of a map (via |image_map=), but no way to get to a mapping web site because image_map may be suppressing the mapframe map (I am currently lazy and haven't checked the code to see what the logic is). – Jonesey95 (talk) 12:52, 25 September 2025 (UTC)

We could just rename those maintenance categories to "... with no specified (map|coordinates)" or "... with no explicit (map|coordinates)", too. --Joy (talk) 14:15, 25 September 2025 (UTC)

That would not address the actual issue. The difference between an article that shows a mapframe map just fine and an article that legitimately has no available coordinates and therefore can't show any map is a significant one. The categories are out of date, possibly because the template was updated since they were created (I haven't checked). – Jonesey95 (talk) 17:58, 25 September 2025 (UTC)

Well, that depends on your point of view. An article that shows unverified wikidata coordinates, maybe also on a bland base map without proper context, could well be worthy of cleanup, maybe even more so than one that doesn't show any map. Maybe the real question is do we actually expect anyone to ever parse these categories with tens of thousands of entries and start cleaning them up based on that. --Joy (talk) 21:10, 25 September 2025 (UTC)

This seems difficult to get high precision. I would suggest just dropping these tracking categories. — hike395 (talk) 00:39, 26 September 2025 (UTC)

Another idea might be to automatically subdivide them by the value of |subdivision_name=, which will split it up by about 200 and make it possible to e.g. ask members of WikiProject $Country go into their respective categories and see what they can do about it. --Joy (talk) 08:25, 26 September 2025 (UTC)

Nomination for merger of Template:Infobox Australian place

Template:Infobox Australian place has been nominated for merging with Template:Infobox settlement. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Thank you. Zackmann (^{Talk to me}/_{What I been doing}) 19:48, 4 October 2025 (UTC)

Rfc: Deprecation of the state and county name in U.S. settlement articles

The use of state and county names inside the |name= parameter to be deprecated.--2600:1700:6180:6290:E53B:9874:8B16:1C3D (talk) 16:25, 13 October 2025 (UTC)

The addition of the state and county name in U.S. settlement articles field is a tendency for settlement articles across the United States. The case to be made to deprecate such usage should be considered within WP:INFOBOXGEO:

Infoboxes for geographical items (e.g. cities and countries) should generally be headed with the article title, although the formal version of a name (e.g., Republic of Montenegro at Montenegro) can be substituted. Where the article title is disambiguated, the plain name can head the infobox, as long as the topic is clear (e.g., São Paulo at São Paulo (state)). Alternative or native names can appear beneath this if beneficial. Extensive historic names are often better in a second infobox, as at Augsburg.

There is a good case to deprecate the use of state and county name in U.S. settlement articles per WP:INFOBOXGEO. --2600:1700:6180:6290:E53B:9874:8B16:1C3D (talk) 16:25, 13 October 2025 (UTC)

Some examples: Bloomington, California; Midway, Calloway County, Kentucky; Spring Valley, San Diego County, California; Lincoln, Illinois; Champaign, Illinois; Victoria, Texas; and Normal, Illinois. --2600:1700:6180:6290:E53B:9874:8B16:1C3D (talk) 16:25, 13 October 2025 (UTC)

Wut? The first part of the first sentence of WP:INFOBOXGEO says "Infoboxes for geographical items (e.g. cities and countries) should generally be headed with the article title", which would mean the article Bloomington, California should have the text Bloomington, California above the infobox. • Sbmeirow • Talk • 05:42, 14 October 2025 (UTC)

I agree that the proposer appears to be misreading, or failing to read, WP:INFOBOXGEO. Putting the article title at the top of the infobox appears to be the MOS guideline. – Jonesey95 (talk) 14:08, 14 October 2025 (UTC)

Perhaps you are failing to read the second sentence of that guideline: "Where the article title is disambiguated, the plain name can head the infobox ..." Deor (talk) 15:18, 14 October 2025 (UTC)

NOTE: A random IP editor proposing changes with this much information smells extremely fishy to me!! Notice how O.P. only made edits on only one day. I'm almost 100% sure this is the same person that is jumping between numerous IP addresses in 2025 from the Augusta, Georgia region. I wouldn't doubt this person had a banned account and/or was a sock puppet too. • Sbmeirow • Talk • 06:00, 14 October 2025 (UTC)

Wikipedia:Casting aspersions — HTGS (talk) 20:19, 25 October 2025 (UTC)

Survey

• Support. I agree that state names are superfluous in infobox headers. I tend to remove them when I notice them. Deor (talk) 16:49, 13 October 2025 (UTC)

I would also agree… since the standard is to include state names in the article title, there is no need to also include them in the infobox header. Blueboar (talk) 17:26, 13 October 2025 (UTC)

• But the counties are used when the comma convention is not sufficient to distinguish a place - this seems like personal preference that can go either way. One of the examples of WP:POSA is New York City even though "City of New York" and the link to city are the correct ways to use Template:infobox settlement. I mean I get it, the county name is present, it's redundant. There's some redundancy in these named places articles. – The Grid (talk) 22:17, 13 October 2025 (UTC)
• One counterexample comes to mind: Caernarvon Township, Berks County, Pennsylvania, and Caernarvon Township, Lancaster County, Pennsylvania. – Jonesey95 (talk) 01:55, 14 October 2025 (UTC)

There's no reason just "Caernarvon Township" shouldn't be the header in both infoboxes: "Where the article title is disambiguated, the plain name can head the infobox, as long as the topic is clear." Deor (talk) 15:18, 14 October 2025 (UTC)

Nothing is clear about two townships in Pennsylvania with the same name. The dab is needed there to avoid confusion. – Jonesey95 (talk) 17:46, 15 October 2025 (UTC)

Needed in the article's title, certainly. But not in the infobox header. Deor (talk) 21:58, 15 October 2025 (UTC)

but then why have a settlement_type parameter in the infobox at all? An infobox is a panel that summarizes key facts about the page's subject. – The Grid (talk) 01:08, 17 October 2025 (UTC)

I don't see what |settlement_type= has to do with the subject of this RfC. In Ada, Nolan County, Texas, for example, the infobox header is just "Ada" and the settlement type is "Ghost town". How would having the header be "Ada, Nolan County, Texas" improve matters, and how does the "Ghost town" designation affect the question? Could you explain? Deor (talk) 14:24, 17 October 2025 (UTC)

It's because Ada, Lampasas County, Texas exists too. Typically, when you see the county in the title of a community article, it means there is another community with the same name in the same state. There far more conflicts with unincorporated communites and ghost towns. Other than states, the railroads and post offices often helped resolved community naming conflicts by saying they wouldn't put a depot or post office in a community unless you changed their name (or railroads would pick another name for the depot), because they didn't want to deal with confusion problems associated with 2 or more communities with the same name in the same state. • Sbmeirow • Talk • 01:22, 18 October 2025 (UTC)

I understand all that, but I still don't see what it has to do with infobox headers. Deor (talk) 01:49, 18 October 2025 (UTC)

• The current guideline suggests disambiguation is not needed in the infobox, and given the infobox includes other administrative divisions it certainly reads strange. However, is a formal rule needed? Are there previous discussions about this? CMD (talk) 16:51, 14 October 2025 (UTC)

This is basically beating a dead horse, because there has been discussions in the past about the name above the infobox. Search the archives in: this talk section, in talk section at Wikipedia:USCITY, and maybe need to search in talk section in one of the articles meant for article tiles in general. • Sbmeirow • Talk • 01:41, 18 October 2025 (UTC)

Can you cite these discussions? Deor (talk) 01:49, 18 October 2025 (UTC)

I really don't feel like wasting my time on an "Rfc" that was likely requested by an IP sock puppet. • Sbmeirow • Talk • 02:02, 18 October 2025 (UTC)

Obviously, when two or more places have the same name, we need to disambiguate the article title - and adding the state (and even the county) name is the most appropriate way to do this. The question is: do we ALSO need to include that disambiguation in the header of the infobox?

For the moment, forget what “the rules” currently say (we can always change the rules if there is consensus to do so). Go back to first principles: those who want the disambiguation repeated in the infobox need to explain WHY it needs repetition. And those who disagree need to explain WHY NOT. Blueboar (talk) 12:54, 27 October 2025 (UTC)

Thinking about it this way, I start to wonder why infoboxes have titles at all. — HTGS (talk) 18:03, 27 October 2025 (UTC)

That's actually a much better question. Let's stop worrying about how it should be formatted and just get rid of it. Nikkimaria (talk) 03:40, 28 October 2025 (UTC)

Since all infoboxes are supposed to have "a large, bold title line", I don't think we could dispense with one in this infobox. Deor (talk) 13:20, 28 October 2025 (UTC)

That ignores Blueboar’s point: stop appealing to the rules.

I’m truly not sure if Nikkimaria is joking or not. While my question was genuine, I’m still quite far from considering abolishing titles from infoboxes all together. — HTGS (talk) 23:17, 28 October 2025 (UTC)

Max size

I was going to modify the call to Module:InfoboxImage to set image_skyline's |maxsize=300px. Just came across a page where a user had set the image size to 450px. Terrible user experience and no reason to have an image that large. Any objections? Zackmann (^{Talk to me}/_{What I been doing}) 22:09, 15 October 2025 (UTC)

Can you link that article so we can all see? --Joy (talk) 07:23, 16 October 2025 (UTC)

@Joy: ahh sorry I should have made note of the article. Sadly it was a few thousand edits ago at this point. Obviously any article that has a single image (not {{Multiple images}}) for |image_skyline= will work for a test case. I just reproduced on Rosslyn, Virginia for example (didn't save the edit for obvious reasons but if you just add |image_size=450px you'll see essentially what I saw). Happy to throw up an example on the testcases if that would be helpful? To be clear I don't think is happening often, most editors know better than to set an infobox image to anything much larger than 300px... But since Module:InfoboxImage does have that maxsize parameter, I figure we might as well make use of it. Zackmann (^{Talk to me}/_{What I been doing}) 07:34, 16 October 2025 (UTC)

I added |maxsize=300px to the sandbox and added a testcase with a |image_size=450px just to show what the difference would be. Worth noting that the same issue exists with the other images parameters... Flag, seal, shield, emblem, map and pushpin_map all have the ability to set whatever size you want to... Ideally those should have a reasonable |maxsize= as well. Zackmann (^{Talk to me}/_{What I been doing}) 07:44, 16 October 2025 (UTC)

I think it would be good if you copy&paste the rest of the LA infobox content in that test case, so it becomes more obvious what this width does to the rest of it, how much empty space appears. --Joy (talk) 08:36, 16 October 2025 (UTC)

Good point! I was focused on just the impact of the image. I'll do that now. --Zackmann (^{Talk to me}/_{What I been doing}) 08:38, 16 October 2025 (UTC)

That's interesting, I actually expected it to be far more horrible.

On desktop, there's a lot of whitespace, though it's only slightly wider than the label "Highest elevation (Mount Lukens)". So I'd say skyline width 450px is too much, but I wouldn't necessarily ban skyline width 400px because it's plausible someone could make that work.

Whereas, on mobile, it seems to be clamped down already by something else, so there's no difference anyway.

For flag_size, 400px seems bad, except if I think of a use case where there is no seal - in which case it's fine to let it go up to 300 or even 400. And it's weird that the 110px flag has unreadable text on it, but the 400px one allows me to read "City of Los Angeles" and "Founded 1781". Can we somehow clamp down the combination of flag_size and seal_size to 400px? --Joy (talk) 12:05, 16 October 2025 (UTC)

Could we be a bit more conservative and set |max_size=320 for the main image? — hike395 (talk) 12:47, 16 October 2025 (UTC)

I set it to add up to 350px in the sandbox, see how you like it now: Template:Infobox settlement/testcases#Case 19: Very large image. --Joy (talk) 13:16, 16 October 2025 (UTC)

Full disclosure I'm editing on an iPad in desktop mode these days, so I'm on a VERY small screen. My experience may not be reflective of the most common use case.... That being said it sounds like there is general consensus thus far that some form of a maxsize is good (does anybody want a 900px image???) ... More of a question of what that should be. Zackmann (^{Talk to me}/_{What I been doing}) 18:50, 16 October 2025 (UTC)

Why are we not implementing what the MOS recommends MOS:IMAGESIZE Lead images should usually use upright 1.2 at most.....and what our policy recommends WP:IMGSIZELEAD The lead image in an infobox should not impinge on the default size.of the infobox. Therefore, it should be no wider than upright 0.9 (equivalent to 228px). Moxy🍁 19:07, 16 October 2025 (UTC)

@Moxy: So a couple of things. I'm wary of making a change that FORCES people to use an image that is too small. I think we can all agree you never want an infobox image that is 500px... But is there a case where a 300px image is warranted? Maybe there is (I can't actually think of one though). That being said, if the MOS says it should never be wider than 228px... I don't have an objection to making that the maxsize. I just worry that there might be pushback from those who prefer a slightly larger image. Zackmann (^{Talk to me}/_{What I been doing}) 19:18, 16 October 2025 (UTC)

In my view if there is to be an exception to our community consensus - that is what deserves a discussion. Implementing the community consensus should take place over concerns of pushback..... if push back occurs we can revert and have a talk. City articles have a huge problem with image spam in the lead ..... for example Los Angeles has 15 files for four paragraphs of text.... simply crazy my view. The least we can do is reduce the size of these so they're not as intrusive for readers...... text inside the box will still be the same we're just reducing the sizes of the images to make the prose lead paragraphs more readable/accessible..... as in not sandwich for some devices and formats. Moxy🍁 19:29, 16 October 2025 (UTC)

Sounds pretty reasonable to me! - Zackmann (^{Talk to me}/_{What I been doing}) 19:30, 16 October 2025 (UTC)

That 228px was added in this April '25 edit whose edit summary said This is not intended as a permanent change; discussion is still ongoing at talk and we should continue working out a new consensus there. The wording can be adjusted after this happens. It's related to Wikipedia talk:Image use policy/Archive 16#Lead image size which isn't particularly clear. --Joy (talk) 19:31, 16 October 2025 (UTC)

Not sure what your trying to say here? To me it seems like our recommendations were changed and have not been reverted.... and the so-called ongoing discussion has been dead for months and it's about to be archived. Is there a new chat about the changes to our protocols? Moxy🍁 19:39, 16 October 2025 (UTC)

I think Joy's point (and correct me if I'm wrong) is that this is still a work in progress and consensus on it is fluid. That being said, I don't see anything in the discussion they linked to that should prevent this change from being made. I think it should be WP:BOLDly done, and if there is pushback, then we can discuss it further. Zackmann (^{Talk to me}/_{What I been doing}) 19:43, 16 October 2025 (UTC)

I don't think infobox template code, which can't be edited by everyone, should try to enforce a manual of style change that isn't backed by strong consensus. The manual of style is not a policy, but a guideline. --Joy (talk) 19:50, 16 October 2025 (UTC)

In particular I'm referring to the fact that nobody really disputed the comment by @User:Pi.1415926535:

15 or so years ago, a typical infobox occupied 1/5 of screen width (200px infobox on a 1024px screen, the most common size in 2010). Since then, screens have approximately doubled in pixel size but stayed similar in physical size, so a 200px infobox occupies only half the screen width that it once did. No one is suggesting infoboxes that infoboxes take up half the screen, just that they are scaled to keep a roughly constant width (on a given physical screen size) over time. Infoboxes are for the most important information and the most representative image - and are typically where readers look first - so why should they get narrower and narrower as screen resolution increases?

There was an answer from @Fyunck(click) but it didn't seem to address this question well. What does seem instructive from the later comment was the mention of infobox pictures as large as when happened a couple days ago - but I don't know what that was specifically referring to. Had there been some sort of a change in April that was then backed out? --Joy (talk) 19:48, 16 October 2025 (UTC)

In my view we should implement what our protocols say and if they change it changes here. Moxy🍁 19:56, 16 October 2025 (UTC)

That entirely depends on what you mean by "protocols", though. Please see Wikipedia:Policies and guidelines. --Joy (talk) 20:01, 16 October 2025 (UTC)

What are the thoughts on a more conservative initial approach? The current maxsize in the sandbox is 320px. How about we start there. I think we all agree that it is an improvement... If down there road there is more clear consensus on 228px (or another number) that can easily be changed. But how about we start with 320px and go from there? Zackmann (^{Talk to me}/_{What I been doing}) 20:16, 16 October 2025 (UTC)

Yes both are policy and guideline pages make this recommendation.... I consider these to be our protocols as outlined at WP:GOV. I should be transparent and explain I help write both the policy guideline page and our administration page. Moxy🍁 20:21, 16 October 2025 (UTC)

A guideline is not a policy. Considering the spirit and letter of their definitions, we're not supposed to prevent any exceptions to the guideline by hardcoding numbers. We're especially not supposed to do that without verifying that we have proper consensus about it. --Joy (talk) 21:25, 16 October 2025 (UTC)

sorry my bad I thought I was linking the policy the whole time Wikipedia:Image use policy.... just regurgitates the guidelines WP:IMAGESIZE and WP:IMGSIZELEAD. My bad this is why there's so much confusion..... was wondering why you were discussing the difference between policies and guidelines here.Moxy🍁 21:36, 16 October 2025 (UTC)

Oh yeah, that was confusing. But still, the argument about unclear consensus about the changes to the image use policy stands. Sure, we've collectively let @David Eppstein's edit from April stand for months now, and the discussion died out to the extent that the bot archived it, but did the consensus-building process actually complete, or did we just lose interest? :)

Besides, we didn't even bring up what seems to be a major point of the same policy - using relative units instead of absolute. If that's so important, why would we be using these template parameters which are still with pixels? --Joy (talk) 04:44, 17 October 2025 (UTC)

Researching this matter further, I found that this April edit by @Jonesey95 had been reverted. What was this default thumbnail size change from 220px to 250px? --Joy (talk) 04:48, 17 October 2025 (UTC)

So one thing I will say to hopefully get this conversation a little back on track, the change I am proposing is to limit the MAX size, not to make any change to the default size... Enforcing a default size is a much more involved discussion. I'm just trying to limit the extremes. Zackmann (^{Talk to me}/_{What I been doing}) 05:01, 17 October 2025 (UTC)

My strong preference would be to follow MOS:IMAGE in using relative sizes (multipliers of the user's default size from their preferences) not absolute sizes (pixels). That way if someone has a big screen and wants to take advantage of it they don't have to squint at tiny thumbnail-sized images sized for people reading on their phones, or vice versa. Beyond that I don't have a strong preference for what the multiplier should be. —David Eppstein (talk) 05:31, 17 October 2025 (UTC)

Agreed, but even that max isn't clear, if the preferences are allowing users to select 300px and 400px, but then infobox code clamps this down without telling them, that looks like it's going to produce weird results at best. --Joy (talk) 10:25, 17 October 2025 (UTC)

The default size (Using |thumb| with no specified size) in the underlying software was changed from 220px to 250px. Not sure where it is documented though. CMD (talk) 05:11, 17 October 2025 (UTC)

Oh, like a Mediawiki systemwide default? Interesting.

https://en.wikipedia.org/wiki/Module:InfoboxImage#L-218 still has a hardcoded reference to the magic number 220. Maybe we need to move this there so it's more consistently addressed in all infoboxes, not just this one.

And having said that, I just realized Module talk:InfoboxImage#Default maxsize to 250px already exists :) --Joy (talk) 10:14, 17 October 2025 (UTC)

@Joy: full disclosure, the thread you linked to was started by me to address this same issue... Zackmann (^{Talk to me}/_{What I been doing}) 17:34, 17 October 2025 (UTC)

Too many maps

So recently came across Vancouver which has FIVE maps in the infobox. 1 mapframe, 1 image map and 3 pushpins. To me this is way too much, particularly since the mapframe duplicates what the image map shows. Was thinking to address this I would do add the following to the Infobox.

{{if all|{{{mapframe|}}}|{{{image_map|}}}{{{image_map2|}}}|{{{pushpin_map|}}}
 | n = 3
 | then = [[Category:Pages using infobox settlement with potentially too many maps]]
}}

Would be helpful to at least know how often this happens? Anyone have any thoughts? --Zackmann (^{Talk to me}/_{What I been doing}) 00:13, 31 October 2025 (UTC)

Makes sense to me, let's investigate. Please add image_map1 to the list as well.

It should be noted that in that case the 3 pushpins don't occupy 3x the space by default. Likewise in that case the image_map1 has a value, but visually it's hidden. But it's still a lot overall, and a situation worthy of tracking. --Joy (talk) 00:39, 31 October 2025 (UTC)

Yes I have to actually look at the code to make sure I'm getting the param names correct. Also Joy is 100% correct, while there are 5 maps on Vancouver, only 3 of them occupy space (as the pushpins switch out). --Zackmann (^{Talk to me}/_{What I been doing}) 01:20, 31 October 2025 (UTC)

In general city articles are the example used of what not to do for an infobox - mass file/image spam. New York city has 17 images being rendered... including teeny little flag icons.Moxy🍁 02:34, 31 October 2025 (UTC)

So I've BOLDly gone ahead and done this... Category:Pages using infobox settlement with potentially too many maps (3,904) should populate in the next few hours/days. We definitely need further discussion on what to do with these pages, but I want to at least see how big of a problem this really is... --Zackmann (^{Talk to me}/_{What I been doing}) 03:58, 31 October 2025 (UTC)

That's a separate problem from this one, because that's usually within the image_skyline parameter. To track that, we'd have to recurse into the value and try to find something like {{multiple image}} and in turn check that. I don't know how much more expensive such a check would be compared to {{if all}} used here (4 #ifexpr:'s), but it sounds like something to ponder first.

Tracking here could be done in a similar manner to maps if we e.g. concluded that having something inside all of image_skyline, image_flag, image_seal and image_blank_emblem is suspect. Judging by the totals at [1] the possible lower bound to that would be the 3880 image_blank_emblems. --Joy (talk) 11:42, 31 October 2025 (UTC)

Pushpin maps are far inferior when it comes to zoomability (click on the map, lose the marker), so only one should be used to show the position within a well-recognizable larger entity. Ponor (talk) 12:16, 31 October 2025 (UTC)

Thanks to the tracking category, I started reviewing these. The first case for me was this:

• [2] - rm extra map of a higher level subdivision, it doesn't point out the topic of this article so it's unlikely to be very helpful to readers, just explain and link it in the caption instead

I'm not sure how easily this sort of an edit can be automated. It required detecting the extra subdivision map which I did visually, dropping it in favor of a caption linking the subdivision name, and shifting the more useful map up from image_map1 into image_map. Possibly the detection could be done using filenames, but it requires parsing an intricate pattern ("Map NL - Veere - Aagtekerke.png") that probably isn't global. --Joy (talk) 10:14, 4 November 2025 (UTC)

My next case was simpler:

• [3] rm excessive map of a higher level subdivision, already part of pushpin_map

But then I came across Agoo, which has:

• File:Ph locator la union agoo.png, which is sort of okay WRT scope for local viewers, and has some labels
• Mapframe hidden behind a label saying OpenStreetMap, showing a zoom level slightly higher than the map above
• Pushpin map of the country, which is sort of okay WRT scope for international viewers, but has no labels

An ideal fix in my mind would be to implement the same thing as Minneapolis to replace all three of these, but OSM doesn't have the shape from the static map at the top (or Wikidata doesn't have it linked). Plus the current implementation monstrosity of the Minneapolis solution. --Joy (talk) 10:21, 4 November 2025 (UTC)

I agree that many infoboxes are cluttered with too many maps. The problem is that because all these options exist, people think that they must be used. Well, just because we can doesn't mean we should. It would be better if we roll back some of these features, or come up with some guidelines for their use. -- P 1 9 9  ✉ 15:35, 4 November 2025 (UTC)

Relief

Can | pushpin_relief = be added to the various sub-templates of {{Infobox settlement}}? {{Infobox Greece place}}, {{Infobox Turkey place}}, and {{Infobox Russian inhabited locality}}, among others, do not let me add maps in relief to their infoboxes. Antiquistik (talk) 17:53, 3 November 2025 (UTC)

 Doing... @Antiquistik: This has been on my todo list... I'm going to convert these all to use Module:Template wrapper so that all params from {{Infobox settlement}} will work as expected. This is going to take a little while but I'll get started on it now. You can track the progress here:

• Need to convert
• Already converted

--Zackmann (^{Talk to me}/_{What I been doing}) 17:59, 3 November 2025 (UTC)

@Zackmann08 Thanks. How do I change the map to the one in relief on the templates which have already been converted? Antiquistik (talk) 21:22, 3 November 2025 (UTC)

@Antiquistik: short answer, |pushpin_relief=yes. Turkey and Greece are done. Working on Russian inhabited locality right now.

Longer answer, see the documentation for {{Infobox settlement}}. Any parameter not hardcoded or overridden by the wrapper code will work exactly as described in the documentation for settlement. If you run into any issues, if you can provide me with a link to a specific page I'll be happy to help ya out! Zackmann (^{Talk to me}/_{What I been doing}) 22:23, 3 November 2025 (UTC)

Thanks! Antiquistik (talk) 22:32, 3 November 2025 (UTC)

Ooh I had noticed that issue, but didn't have the time to invest into dealing with it. Happy to see progress on that front. --Joy (talk) 21:48, 3 November 2025 (UTC)

Why does everyone on WP want relief maps now??? I don't think that is a good idea. We should use relief maps only for rivers, lakes, and such, not human places and jurisdictions, because borders and subdivisions are not or barely visible on the relief maps. There was some consensus or best practice for this at one time, but I don't remember where I read that. But it was briefly discussed at Wikipedia:Help desk/Archives/2025 January 28#Relief on City Pushpin Maps? Maybe another centralized discussion should be started to adopt some standard/guideline on this. -- P 1 9 9  ✉ 03:07, 4 November 2025 (UTC)

@P199: FWIW I agree with you. I would be in favor of removing support for relief in Infobox settlement and all its subsidiaries... But that would def require consensus. Zackmann (^{Talk to me}/_{What I been doing}) 03:10, 4 November 2025 (UTC)

I don't quite understand this argument. The linked discussion was about Santo Domingo, a capital city.

I can't say that seeing the internal borders of the Dominican Republic on these two maps is particularly useful for the average reader. It's a lot of lines, but no apparent value, because it's not explained, there is no legend. There's elements of physical geography on both maps, like bodies of water and coast indentation, but one shows the internal subdivision lines more while not showing elevation.

For a reader, knowing that a place is close or far away from a sea or a mountain is similarly general information compared to knowing that it's close or far away from the nearest national border. These are everyday things that affect basic orientation of a reader about a place, like how far from another such place it might be, or how hard it might be to travel around there.

For borders of lower-level administrative subdivisions, it's much more specific information, probably too specific for the average reader who isn't from the area.

For comparison, here's how the infobox mapframe map would look like there. At this similar zoom level, it has a lot of these unexplained lines, but over them it also has basic labels, country and big cities. It also has a basic scale, for distance comparison.

And once you click it, you can zoom in and out, and see more labels. At higher zoom levels, green blocks start to appear for areas of nature, which isn't a direct replacement for the placement of mountains, but it's often a reasonably close approximation.

If we're thinking of making changes, it's probably good to think in terms of our entire mapping arsenal. --Joy (talk) 06:09, 4 November 2025 (UTC)

The lines don't need a legend, because the maps are consistent in showing internal borders. For large countries especially, those lines are far more helpful then the green and brown shades, because it also shows its location relative to province/state boundaries. A good example is the USA - many, if not most readers, will be familiar with the individual states. So I disagree with the statement that political maps are "probably too specific for the average reader who isn't from the area".

Ultimately, all your arguments can also be said about the relief map: just a field of green and browns without explanation, giving a bit of basic orientation. Political maps do the same AND are more helpful to those who do know the political geography of a place.

As for "making changes of our entire mapping arsenal", that's too big a step for now (getting consensus for that would be near impossible). Maybe a good start would be removing support for relief in Infobox settlement, which I would support. -- P 1 9 9  ✉ 14:16, 4 November 2025 (UTC)

I'm sorry, that's a hard disagree from me on your first claim. When I look at a map of a large country, let's say the biggest one, Russia, most of the time I have no idea what the internal lines mean. Is it the Krasnoyarsk Krai or is it the Republic of Bashkortostan - I'd be hard pressed to answer. Likewise for the US. I am interested in geography and the US is a superpower so a matter of above average interest, so I may claim the ability to make sense of most of those American lines, but the average English reader is not a geography enthusiast. I'm pretty sure most of our readers can't figure out what most of the internal lines mean to save their life.

This is a general encyclopedia, this is not a scientific journal. Let's not ignore accepted policy just so casually.

Elementary schools teach people how to read maps in general, so they can know the meaning of a line being a border and the color scheme being topography, but labels are still beyond useful to know which county or mountain a map is displaying. Knowing the fine details of political geography beyond one's own country is just not part of the average curriculum and we should not design maps based on any such wishful thinking.

The idea that we're going to improve anything for the readers by making it impossible to present vague relief maps, but keep presenting political maps that are no less vague - is misguided. ---Joy (talk) 16:42, 4 November 2025 (UTC)

I think probably the best map type depends on the country doesn't it? Maybe for vast nations with a varied geography like the US, Russia or Australia, a relief map might be helpful. But in smaller densely populated places like England, a little dot in an expanse of green doesn't help much and can actually be misleading, hiding quite how built up an area is. The best map choice there is usually a mix of political and man-made structures such as motorways. Like York, for example. Dgp4004 (talk) 17:18, 4 November 2025 (UTC)

And London's pushpin map of England uses a combination of relief and political. That sort of combination might be a good compromise. Dgp4004 (talk) 17:27, 4 November 2025 (UTC)

The UK pushpin basemaps are of markedly better quality than the average, agreed. --Joy (talk) 21:14, 4 November 2025 (UTC)

Disagree with you on all points too. It's so dismissive to claim that "most of our readers can't figure out what most of the internal lines mean". Anyway, the entire discussion boils down to different points-of-view and subjective criteria. We won't reach consensus on this. -- P 1 9 9  ✉ 03:56, 5 November 2025 (UTC)

It's not dismissive, it's just recognizing the reality that this is a general encyclopedia with a broad readership. There's nothing subjective about being cognizant that people who may read an article may come from Adelaide, El Paso, Newfoundland, Gujarat, Merseyside, Cape Town... --Joy (talk) 06:31, 5 November 2025 (UTC)

Mapframe wikidata

@Joy: (and anyone else) can you think of a reason we don't have |mapframe-wikidata=yes in the template? It seems like that is what is missing from the desire to convert from the Template version of the mapframe to the Module version. The template seems to pull from wikidata automatically, the module does not. Zackmann (^{Talk to me}/_{What I been doing}) 19:49, 7 November 2025 (UTC)

I think it's because Wikipedia:Requests for comment/Mapframe maps in infoboxes#Q4. Wikidata coordinates - whenever there's local data here, it should override data from Wikidata by default.

The problem is, our local method of using shapes clearly doesn't scale as well as Wikidata references to OSM. I for one never used it, editing OSM with the default web editor just seemed too easy. --Joy (talk) 20:04, 7 November 2025 (UTC)

I thought that if {{infobox settlement}} had {{{coordinates}}} that would override the wikidata call.. I've just found that the shape doesn't show up without |mapframe-wikidata=yes. See this revision. If you remove the |mapframe-wikidata=yes call, you won't get the red border around the city. It would seem that the best solution is to have that be built in. I've seen it on numerous other Infoboxes I've recently converted. Zackmann (^{Talk to me}/_{What I been doing}) 20:13, 7 November 2025 (UTC)

I think it's more subtle than that - the red shape you can get with |mapframe-shape=yes. You don't need the entire override from wikidata. At least that's how I think it should work. --Joy (talk) 20:25, 7 November 2025 (UTC)

Facepalm Didn't know that |mapframe-shape=yes would do the samething... Why is this SO confusing?!?! lol. Ok so what do we think about adding |mapframe-shape=yes to the code for {{infobox settlement}}? You can always override it on individual transclusions if needed, but I have yet to see or think of a case where on a settlement page you would be disappointed to see the boundary lines. Zackmann (^{Talk to me}/_{What I been doing}) 20:28, 7 November 2025 (UTC)

I would agree with that, yes. The usage of local map shapes seems comparatively tiny and doesn't seem likely to grow. That is, we're not really be impeding any local development by doing this. Seeing the shapes linked from Wikidata seems safe enough.

Worst case we show some bad ones and this visibility helps get them fixed faster - the same as what happens with bad coordinates (and we do have a fair few of those, usually hiding in plain sight without mapframe rendering). --Joy (talk) 20:46, 7 November 2025 (UTC)

I'm going to go ahead and add it. Obviously if it causes any issues we can revert. - Zackmann (^{Talk to me}/_{What I been doing}) 20:49, 7 November 2025 (UTC)