Template talk:Infobox settlement

Any contributor may edit the template's sandbox . Functionality of the template can be checked using test cases .

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) [reply ]

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) [reply ]

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) [reply ]

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) [reply ]

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) [reply ]

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) [reply ]

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) [reply ]

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

• 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) [reply ]

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) [reply ]

• 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) [reply ]
• One counterexample comes to mind: Caernarvon Township, Berks County, Pennsylvania, and Caernarvon Township, Lancaster County, Pennsylvania. – Jonesey95 (talk) 01:55, 14 October 2025 (UTC) [reply ]

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) [reply ]

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) [reply ]

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

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) [reply ]

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) [reply ]

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) [reply ]

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) [reply ]

• 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) [reply ]

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) [reply ]

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

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) [reply ]

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) [reply ]

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

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) [reply ]

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) [reply ]

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) [reply ]

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) [reply ]

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) [reply ]

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) [reply ]

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) [reply ]

So I've BOLDly gone ahead and done this... Category:Pages using infobox settlement with potentially too many maps (15,465) 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) [reply ]

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) [reply ]

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) [reply ]

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) [reply ]

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) [reply ]

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) [reply ]

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) [reply ]

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) [reply ]

@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) [reply ]

@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) [reply ]

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

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) [reply ]

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) [reply ]

@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) [reply ]

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.

Map

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) [reply ]

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) [reply ]

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) [reply ]

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) [reply ]

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) [reply ]

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

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) [reply ]

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) [reply ]

We're discussing how to handle the rendering of shapes/lines in Template:Infobox mapframe, given that OSM data is unreliable. This will likely affect this template. You're welcome to join in the discussion. — hike395 (talk) 09:49, 8 November 2025 (UTC) [reply ]

There's currently a discussion at Template talk:Infobox UK place#Conversion to use Infobox settlement as a wrapper about whether and how to make that template a wraper of Infobox settlement.

There are some potential changes that we could do here to facilitate that migration, and potentially improve things for other settlements out there, too. There's already two main use cases it seems - distances and public emergency services. I'll start separate subthreads for each.

Just a few common links first:

• Template parameters report for UK place
• Template parameters report for Australian place

--Joy (talk) 14:43, 25 November 2025 (UTC) [reply ]

A place to include distances from the topic settlement to other points of interest.

This is ostensibly a geographical field, similar to coordinates and maps. Zackmann08 has recently complained about how this is redundant with various maps. I don't think it's inherently redundant, because different readers absorb different types of information better, but the risk of overkill is real. We don't have a mechanism of preventing geography/location overkill, just like we don't have it for the various flags and seals and images. I don't think this risk should impede trying this out. It's easy enough to just pull the plug on it later if it truly gets out of hand, by just removing the rendering of any such new fields.

The UK infobox specifically uses this concept for four types of distances to capital settlements, and their standard seems to be a single entry in that list, with a length that is passed through {{convert }} etc.

A use case like this is already also improvized by WP:IAUP through |subdivision_type6=+|subdivision_name6=. That is a bit of a kludge, but seems to have worked out. It comes after the block of parameters described as Location by the documentation here, so it seems to make a modicum of sense. They use it for a list of up to 5 other locations, with some formatting.

Historically there doesn't seem to have been much acrimony about the concept at the UK place talk page, the last signs of it are in Template talk:Infobox UK place/Archive 9 from 2010. The later discussions seem to be about implementation details. In the recent discussion, people actually started discussing about how the distance expressed in kilometers/miles isn't informative enough.

Current UK usage of these parameters:

Likewise, at the Australian place talk page, the last question about this was in Template talk:Infobox Australian place/Archive 9 from 2022 where an editor asked about more flexibility, just to be able to indicate remoteness structure (which seems to be a statistical category in that country). Others before that also asked about whether to use lengths by straight line or by road (like the recent discussion at the UK place infobox talk).

Current Australian usage for these parameters:

• location1 10,769
• location2 7,578
• location3 5,432
• location4 3,001
• location5 903

I can envision editors wanting to use different distance indication/measurement methods depending on settlement type. It's reasonable to assume that for certain places they may want to include conventional time of travel, esp. for far away places, like islands in the ocean, oases in huge deserts, etc. Some readers may appreciate a distance in length units, some maybe in flight time. A predictable time of transport to some conventional point of interest like a far-away regional capital is plausibly useful to the average reader. Elsewhere, they may just want to have some other, not terribly specific or even numeric distance indication.

Because of this, I don't think we should import any implementation complexity here, rather, just give people a free-form option to include something in the first place, and later reassess if we need to provide more guardrails.

We could start by adding an optional |distances_label=Location and |distances_list= here. This would allow for a technical cleanup in the Australian template and remove one conversion blocker for the UK template. --Joy (talk) 13:22, 25 November 2025 (UTC) [reply ]

A place to include more basic public services information, for emergency/rescue.

This is ostensibly an administrative field, similar to time zones, postal codes, etc.

The UK infobox specifically uses it for three types of services retrieved through Template:Infobox UK place/local:

• Police
• Fire
• Ambulance services

That approach seems fairly useful to maintain shared information in one place, instead of having a lot of copy&paste everywhere.

Given that we already summarize other regional properties like time zones, ISO codes, registration plates, this seems like a fair request. In some settlements it'll just be national service links (reminds me of time zones), which we could probably optimize, but somewhere else it'll require a bit of nuance.

We had an initial thread about this at Template talk:Infobox settlement/Archive 33#Edit request 1 June 2024 but it wasn't formatted right and no discussion followed. There doesn't seem to have been a whole lot of discussion in this regard before, only one inquiry about police and fire departments in Template talk:Infobox settlement/Archive 24 in 2014.

I'm not sure immediately about how to organize new fields for this, suggestions welcome.

• |emergency_services_label= and |emergency_services_list=?
• |police_service_label= and |police_service_list=, |fire_service_label= and |fire_service_list=, |emergency_medical_service_label= and |emergency_medical_service_list=?

Or something else?

I wouldn't add specialized emergency services yet, that seems like a slippery slope. --Joy (talk) 13:39, 25 November 2025 (UTC) [reply ]

I will just voice my 100% opposition to adding either one of these to {{Infobox settlement }} and reiterate some of what I have already said at {{Infobox UK place }}

• Wikipedia is not a directory, and per MOS:INFOBOXPURPOSE The purpose of an infobox is to summarize, but not supplant, the key facts that appear in an article. Listing of Fire/Police/Medical services in an Infobox is way overkill. Put that in the article, NOT in the Infobox.
• We already have maps (multiple of them) in the Infobox, we do not need a list of distances to random cities that may or may not be nearby. What purpose does this serve that cannot be achieved with a mapframe? Unless my desire is to know EXACTLY how far city X is from one of the 6 or 7 arbitrarily chosen cities, this information does not help at all. Additionally if my primary goal of looking at the page for Princetown (for example) is to find out exactly how far it is from London, I'm sorry but Wikipedia is the wrong place for that. Google it.
• I believe that the goal of the "distance to city x" parameters is to give the user some idea of where a place is. That goal is already well achieved by the pushpin maps and the relatively newer mapframe. We do not need a list of distances as well.

Adding these values to {{Infobox settlement }} to make users of UK place happy is a mistake. These values do NOT belong in an Infobox and should be removed from UK place. Nothing against including them as needed in the body of the article. --Zackmann (^{Talk to me} /_{What I been doing} ) 16:41, 25 November 2025 (UTC) [reply ]

I'm not sure how the Wikipedia is not a directory of everything in the universe that exists or has existed. policy really speaks to the quality of what's the best infobox summary of an article.

The obvious arguments would be by comparison to existing optional fields - how is the time zone or some random code of a place a key fact for it, one we have to make room for, but their basic public emergency services are not, and we must not make room for them? Or why is listing a village's 2nd or 1st level country subdivision a key fact, while saying what their local fire department would not be?

I agree with the basic summarization argument - the articles on settlements should describe these matters in detail, and then the infoboxes should summarize them. But I don't see how preventing or dissuading editors from summarizing this by restricting infobox formatting accomplishes this purpose, or really any other.

The purpose of showing a distance would be to assist readers who understand distances better than maps. I don't see why the possibility of readers who do not like to do multiple clicks, pans and zooms on a maps in order to understand where a place is - would be inconceivable. I myself like browsing maps, yet I find the thought of just seeing:

• "[That town is] 47 miles east of Dallas", or
• "[That village is] 22 km south of Pretoria", or even
• "[That island village is a] 25 minute ferry ride from Suva", or maybe even
• "[That hamlet in the tundra is] 92 km by air or 103 km by river from Irkutsk" (the thought being - no airfields are actually nearby)

...very useful to summarize geography sections of settlement articles, because they can provide orientation in a few simple words as opposed to requiring analysis.

Fundamentally, as we already support a variety of free-form fields, including completely blank ones, the idea that we would really need to try to artificially restrict named fields strikes me as strange. --Joy (talk) 17:36, 25 November 2025 (UTC) [reply ]

@Joy: Just to clarify my comment that Wikipedia is not a directory was directed specifically at the inclusion of Fire/Poice/Medical services, not about the distances to locations. If we are including Fire/Police/Medical, why are we stopping there? What about including all the public transport of a place? What about listing the airports in a settlement? Should we list all the hospitals in a settlement along with who provides EMS? What about the public radio stations that serve a given area? Pretty soon we have the entire article crammed into the infobox. We need to remember MOS:INFOBOXPURPOSE and not try to cram every piece of information about a place into the infobox. THAT is my point.

I will reiterate that I have no problem with including this information in the body of the article... But the idea that we need to list the name of the fire department in the infobox doesn't hold water in my opinion... Zackmann (^{Talk to me} /_{What I been doing} ) 03:29, 26 November 2025 (UTC) [reply ]

I agree, it can be a slippery slope. But that doesn't change the fact these emergency services can be key pieces of information to summarize in an article, much as anything else that we already have in this infobox.

I think we need to consider this based on what would practically be affected. For instance, if we have a village that has a firehouse that is located in the center next to the main church, and the article explains the 150-year-old history of the local fire brigade, then that's something we shouldn't prevent noting in the infobox.

It does leave us with a risk someone will list a fire service from the nearby town, which maybe doesn't have a strict connection to the settlement described, it could just be by and large not key info. But it's no worse a problem than the risk that someone will list a pointless time zone, the ISO code for the wider region, the registration plate for the municipality, etc.

For instance, if we have a remote town in Alaska whose main lifeline is the local airfield, its article would presumably tell us that, and its infobox would probably be right to include the same. In a town in a more densely populated area, where the closest airport is 12 other places away and/or 50 miles away, and the main mode of transport is roads, it probably makes no sense to talk about the airport. At the same time, if there's one or two main highways connecting the place, it may well make sense to list these.

And we also can't ignore the possibilities of a disconnect between editors and readers with the status quo. Editors can list 4 different area statistics, 3 different population stats, the current mayor and all the local council members, and the flag and the shield and the postal codes, the works. For a lot of readers, a substantial portion of these will just not be key facts about the article topic, even if the infobox syntax allowed for it and they are key for some other readers. They might have wanted a single area stat and a single inhabitant stat, the insignia may have been pointless visual distractions, and in turn something they might consider a key fact was missing. Like the link to the primary emergency service provider, or a distance to the closest big city :)

The key thing here is context - is the context of the infobox syntax the right place to decide these matters, or is the context of the article the right place to decide these matters?

With over half a million transclusions, I think we've outgrown the possibility of doing a lot in the former context (of the infobox), because the variety out there is so large. If we were to remove a field for e.g. leader_name4 or image_blank_emblem or code2_name or timezone5_DST, we'll easily find a lot of articles where this was key info and it was actually appropriate to have it.

We may be able to decide to try to actively dissuade listing e.g. radio stations or hospitals or timezones or similar, but we'd need to develop some sort of coherent criteria for this, because key facts just seems too vague when it's based on articles that are free-form, and not fair given the status quo assortment of fields. --Joy (talk) 10:03, 26 November 2025 (UTC) [reply ]

I also agree that the distance to x does not belong in the infobox. Do articles that use that information in the infobox, have that information also in the article prose? I'd be very surprised if they do. That doesn't mean that information isn't interesting to some people, but that information is much more WP:TRIVIA and belongs more at tourist destinations. Gonnym (talk) 21:03, 25 November 2025 (UTC) [reply ]

Reading this, it occurs to me that this sort of logic could also be used to try to remove locations and maps from infoboxes altogether.

If you are surprised to see "The place is [X distance] away from another place" in the article prose - and that actually happens in settlement articles, quite often - how easy would it then be to say: why do we need a map?

Also, a map will typically contain some geographic features between and around that place and those other mentioned places. But all these map features are not in the article prose, so the infobox actually adds more information rather than just summarizing, right?

Besides, if the prose says a place is in country X, does that actually justify drawing a map of this country? The article doesn't talk about the entirety of the country, therefore that country's whole map is not a summary of the article, right?

Suffice it to say that I don't think any of this is actually a useful line of reasoning.

The location of a settlement is not miscellaneous information, because locations are defining characteristics of places. A reader who arrives at an article about a settlement will habitually ask - where is this place? That is a common question, so an article should not be artificially restricted in answering that up front, in the infobox or otherwise.

Because it's common sense to not treat readers as if they're just some pesky tourists.

And because Wikipedia combines many features of general and specialized encyclopedias, almanacs, and gazetteers. The common element of gazetteers is that the geographical location is an important attribute of the features listed. A location of a settlement is normally presented in relation to other places, so showing distances, on a map or in a list or whatever other way is conventionally useful to readers, is not something out of the ordinary. --Joy (talk) 22:39, 25 November 2025 (UTC) [reply ]

I hold several of the sentiments listed by Joy. I added on the UK page that Wiki is firstly and foremost an educational resource, and there has to be an element of breaking down the article for those less knowledgeable or where English isn't a primary language. Giving a semblance of where a place is is key detail, and the distance from a well-known place starts to help build up that picture. I'd go as far to say that mentioning political features such as the district or state it is in does not relay any idea where a place is, yet no one questions having those in the box.

It is yes harder for a polycentric country such as the US to use a capital when other cities are more well-known, but most countries have one main city. People with special accessibility issues would also appreciate getting a location idea quickly from the box, even automated tools can use the infobox detail to build a profile on a place. Same with the services, they are key ecosystems which allow a place to essentially exist and they deserve a mention in said infobox. Regs, The Equalizer (talk) 00:04, 26 November 2025 (UTC) [reply ]

• Definitely not a thing we should be jamming into an infobox especially if it's not even important enough to be mentioned in the articles.Moxy 🍁 00:09, 26 November 2025 (UTC) [reply ]

  It should be as prose since accessibility concerns means a map is not always suitable, a reader might not be able to interpret distance using the minimalist maps on Wiki, or the visually impaired for example would depend on a screen reader to read out the text to explain where the place is. Regs, The Equalizer (talk) 08:46, 26 November 2025 (UTC) [reply ]

  @The Equalizer: Is this really the function of Wikipedia though? To tell you the exact distance that city X is from some arbitrary city Y? That seems like the function of a very simple Google search. As I said above, if your end goal is to find out how far a certain is from another, I don't think Wikipedia is where you would turn to... Zackmann (^{Talk to me} /_{What I been doing} ) 03:34, 28 November 2025 (UTC) [reply ]

  Yes Zac, but one, it doesn't have to be exact, only approximate/rounded and two it's not any other city - it should be the recognized capital. The UK settlements WikiProjects UK Geography guide states it for example. And being an encyclopedia Wiki is the right place to provide such basic detail. Regs, The Equalizer (talk) 21:41, 28 November 2025 (UTC) [reply ]

  @The Equalizer: So while I get where you are coming from, how do we globalize this for {{Infobox settlement }} so that it works for everywhere, not just the UK? Do we add a parameter for the distance to every country's capital? If we leave it up to the transfusions to chose the "x" in "distance to city x" then what is to stop people from choosing an arbitrary city that they think is noteworthy of including?

  Again I maintain that if you want to know how far from a certain city another city is, that is not the function of an encyclopedia... That is the function of an atlas or a search engine. Furthermore, it is certainly not the function of the Infobox in an encyclopedic article (I reiterate I have nothing against including in the article that city x is y distance from city z). Hope that makes sense... Zackmann (^{Talk to me} /_{What I been doing} ) 03:46, 29 November 2025 (UTC) [reply ]

  I made a new talk section to discuss further. Regs, The Equalizer (talk) 02:36, 4 December 2025 (UTC) [reply ]

• I'd like to point out that the fire/police/ambulance rows aren't generated directly from parameters - you won't find articles showing e.g. |police=Metropolitan. Instead they're derived from various other parameters which are passed through Template:Infobox UK place/local, see Template:Infobox UK place#For automated features, it's the "Services" row. --Redrose64 🌹 (talk) 21:37, 27 November 2025 (UTC) [reply ]

  Which reminds me, there's another option - we could also have a technical feature for that here, but only as a technicality, and not actually documented for further usage by anything else. --Joy (talk) 21:54, 27 November 2025 (UTC) [reply ]

There is a general problem in letting an infobox template automatically import in Wikipedia information from another wiki (such as Wikidata), because a wiki is, by definition, an unreliable source by itself, and because such an automatic importation cannot be individually challenged by a « citation needed » requirement.

One such wiki is OpenStreetMap which is not backed by any official national office of topography or cartography. It is liable to contain mistakes, and it does. This has come to my attention through pages using Template:Infobox Switzerland municipality The particular problem there is that the maps imported (« location of ... ») represent all the municipalities that are located on the shores of a lake as containing within their borders a portion of this lake. To my knowledge this is never true in Switzerland: the portions of lakes within the borders of some canton are under its direct jurisdiction, and never belong to any smaller municipality. For the Canton of Geneva this is specified by the « Constitution de la République et Canton de Genève (art. 159 al.2) and by the « Loi sur les eaux (LEaux-GE) (art. 3 al. 4 et 5 al. 2) ». An additional unfortunate consequence of this is the incorrect indication as « neighboring municipalities », in the infobox, of municipalities located on the opposite shore of the lake.

This is just an example, and a number of other mistakes are very likely. I think it it imperative that this automatic importation by various templates of potentially erroneous maps from OpenStreetMap be altogether stopped, and I am aiming to reach a consensus on this. It could be replaced by another automatic importation, which would have to be very strongly reliable: I doubt there is any possibility. I favor instead a new entry in the infobox template such as « | location map = » to be filled individually (and in which a new entry could always be challenged by a « cn » template). There might be other solutions, as still authorizing automatic importation, but only if it is with the possibility of individually challenging it (and eventually suppressing it). Sapphorain (talk) 21:31, 29 November 2025 (UTC) [reply ]

What do you mean it can't be challenged? Just add:

| mapframe-caption = {{citation needed}}

?

I'd say it's we shouldn't make rash conclusions about a global data source based on a sample of up to 117. --Joy (talk) 21:35, 29 November 2025 (UTC) [reply ]

Thanks for the tip, this could be useful. However, only for the particular example I mentioned, this would mean individually challenging several dozens of maps, maybe more. Not very practical. There must be an easier way to correct a general error. --Sapphorain (talk) 21:58, 29 November 2025 (UTC) [reply ]

Mapframe has been in use for years on wikipedia. This is the nature of the beast with ALL open source wiki's. The information can technically be edited by anyone and is thus not always reliable. To suggest that we remove it from at least a half million pages is not backed by any real data other than one user's dislike of the system. Zackmann (^{::::Talk to me} /_{What I been doing} ) 01:43, 30 November 2025 (UTC) [reply ]

« The information can technically be edited by anyone and is thus not always reliable. » This is precisely the description of an unreliable source, and Wikipedia normally aims to avoid unreliable sources. Claiming that we shouldn’t do anything about one particular unreliable source simply because it has been widely in use for many years appears to me to be a rather poor argument.

There should at least be an easy way to suppress an individual map from an infobox (or replace it by a correct one if available) if it turns out to be inaccurate.--Sapphorain (talk) 09:54, 30 November 2025 (UTC) [reply ]

Background of OpenSteetMaps are extracted from reliable satellite maps, so background is always true, but the unreliable part is the labels and roads that are added to this background.

Even though it is likely that these meta-background add-ons be subject to vandalism, its likelihood is low. But other maps (like satellite map, and custom map) can provide a reliable proof for that unreliable OSM map. Using Template:MergedMap, there would be a nice way to validate these unreliable OSM maps. Hooman Mallahzadeh (talk) 10:27, 30 November 2025 (UTC) [reply ]

@Sapphorain I really propose to add an instruction for "Template:MergedMap" that claims "Try to provide image type maps to validite OSM". Thanks, Hooman Mallahzadeh (talk) 10:48, 30 November 2025 (UTC) [reply ]

@Hooman Mallahzadeh. I don't quite understand what you propose to do, but if it can solve the problem, please do it! Thank you. --Sapphorain (talk) 13:00, 30 November 2025 (UTC) [reply ]

@Sapphorain: I mean the second and third maps of this switcher element are validators of the first unreliable map:

And we ask users to provide map validators for OSM maps. Do you agree? Thanks, Hooman Mallahzadeh (talk) 13:08, 30 November 2025 (UTC) [reply ]

Thank you very much for your involvement Hooman Mallahzadeh. This would be better than nothing of course. But if the main issue is about borders (or other labels), if the first map appearing in the infobox shows the challenged labels whereas the validators don't show any label, this will not solve the problem. It would be better if the first map appearing in the infobox contained no labels of any sort. In fact it would be even better if all imported maps were satellite maps without any added on potentially subjective labels.--Sapphorain (talk) 21:02, 30 November 2025 (UTC) [reply ]

@Sapphorain - The boundaries uploaded at OSM have their sources named. I have also checked the Swiss federal geoportal site at https://map.geo.admin.ch - the municipalities boundaries are reflective of what is at OSM, namely that they extend into the lake. Where are you understanding that the boundaries should follow the coastline. Regs, The Equalizer (talk) 10:47, 1 December 2025 (UTC) [reply ]

@The Equalizer Once again, for the Canton of Geneva this is specified by the « Constitution de la République et Canton de Genève (art. 159 al.2) ["Sous réserve des droits privés valablement constitués, le lac, les cours d’eau, les nappes d’eau principales et profondes, tels que définis par la loi, sont des biens du domaine public et doivent être sauvegardés"] and by the « Loi sur les eaux (LEaux-GE) (art. 3 al. 4) ["Les dispositions de la présente loi s'appliquent au lac"] and 5 al. 2 ["Les tronçons des cours d'eau formant frontière nationale et les nappes d'eau souterraine principales et profondes font partie du domaine public cantonal"] ». There are similar specifications for the cantons of Vaud and Valais but I didn't look them up. The portions of the lake belonging to the Canton of Geneva are under the direct jurisdiction of the canton, and don't belong to any particular smaller municipality.--Sapphorain (talk) 15:35, 1 December 2025 (UTC) [reply ]

If there is a separate arrangement for management of the lake with higher level authorities that wouldn't be reflected in the map as it only shows the boundary of the municipalities and cantons separately. Those responsibilities aren't typically mapped as primary boundaries.

In the UK multiple 1st tier 'parishes' handle basic functions (gardens, bus shelters etc), the 2nd and 3rd tiers municipalities (districts and counties) cover higher level and more strategic responsibilities and a physically wider area across such as environmental matters (including bodies of water), trunk road upkeep, building code etc.

Therefore, a Swiss 1st tier municipality might cover a certain type of land area, they ultimately have no say with how it is managed - it is normally accepted that the canton area covers that responsibility (see Municipalities of Switzerland#Structure and responsibilities) and the Water Law you quote reads as such to me. Regs, The Equalizer (talk) 16:46, 1 December 2025 (UTC) [reply ]

I think you didn’t read correctly. « Les tronçons des cours d’eau formant frontière nationale [...] font partie du domaine public cantonal ». And « Les dispositions de la présente loi s’appliquent au lac ». This means a municipal boundary cannot possibly extend within the lake (i.e., not even as a « secondary » boundary), if the municipality is located on its shore, simply because the portion of the lake belonging to the canton of Geneva is limited by a national boundary (with France). And because the portions of watercourses and of the lake limited by a national boundary « belong to the cantonal public domain ». This is not contradicted by the Wikipedia section for which you provide a link, which by the way is rather vague and not backed by any inline source. (And there certainly is no possible comparison with UK municipal boundaries, which never coincide with a national boundary...).--Sapphorain (talk) 23:03, 1 December 2025 (UTC) [reply ]

Those legislative quotes mean nothing until formally logged at, maps updated at, and shape files provided by the Swiss national mapping authority which when uploaded to OSM will update here. I recommend it is taken up with this authority, if it is such a fundamental mistake they will update it quickly...

But I doubt it as the mapping link I gave earlier clearly showed the Céligny municipality exclaves as part of the Geneva canton into the lake. Until then no maps should be updated and certainly shouldn't be adding validations to maps here @Hooman Mallahzadeh - it should be done at the OSM end, which as said before has the Swiss authority referenced. Regs, The Equalizer (talk) 02:38, 2 December 2025 (UTC) [reply ]

Céligny is particular, as it is one single isolated municipality surrounded by the canton of Vaud. So of course there is an extension of the municipal borders within the lake, which as soon as in the lake are not anymore here in order to indicate the limits of the municipality, but the limits of the cantonal domain (of the canton of Geneva).

The laws specifying cantonal and municipal jurisdictions and borders are cantonal, and cartography/topography is federal. I’ve checked on their (paper) printed map I own, and even those with 1:25 000 resolution show nothing else than the national and cantonal borders on the surface of the lake, which is correct.

Anyway, I give up. I am not going to spend more time on this. So the infoboxes will contain both the incorrect maps automatically imported, and reliable references to the cantonal laws from which the correct maps could and should be drawn. This is rather clumsy but better than nothing.--Sapphorain (talk) 15:27, 2 December 2025 (UTC) [reply ]

@Joy@The Equalizer@Zackmann08 Hi, and sorry for pinging again. After about one week of testing Template:MergedMap, I created a sandbox version of Infobox settlement in Template:Infobox settlement/sandbox which has this code:

| data27 = {{MergedMap|{{{mapQuery|}}}| mapframe-marker = {{{mapframe-marker|town}}}|customMap1 = {{{customMap1|}}}}}

It is tested successfully in Sadra, Fars article.

It works by only one line of mapQuery argument, i.e.,

| mapQuery = Iran#OSM

If it is good, please apply that to start Infobox testing process of this template. Thanks. Hooman Mallahzadeh (talk) 08:43, 3 December 2025 (UTC) [reply ]

I don't think we should use it here until the basic implementation questions have been resolved at Template talk:MergedMap, such as the query label format. It's bad enough that changing the labels will already break a few articles that already use it, we should not make it even worse. --Joy (talk) 09:39, 3 December 2025 (UTC) [reply ]

@Joy Ok. Thank you for your response. I propose to create a "request for comment" for deciding about labels of this template. I am ready to implement final decisions. I think merging maps is such a good idea that should be implemented as soon as possible. Nowadays, many of existing infobox of articles have 2 maps (both OSM and pushpin) which is not good at all and makes infoboxes ugly. Thanks again. Hooman Mallahzadeh (talk) 09:50, 3 December 2025 (UTC) [reply ]

They've been like that for decades, let's make sure we do things right before we commit too many volunteer hours to it :) --Joy (talk) 10:00, 3 December 2025 (UTC) [reply ]

Ok. I think, these decision should be made:

1. Template name
2. Label for OSM map
3. Lable for pushpin map
4. Lable for satellite map
5. Label for jpg map

I think using more than 4 maps in infobox radio button is not rationale. So these decisions also should be made:

1. Number maps and Type of maps
2. Order of maps (Which one should be the first one and so on)

Thanks agian. Hooman Mallahzadeh (talk) 10:07, 3 December 2025 (UTC) [reply ]

User:Hooman Mallahzadeh I want to be careful here because I do not want to WP:BITE...

I will reiterate what I have told you previously, I think what you are working on is a wonderful idea that has a lot of potential, but you are moving too fast. This is NOT ready for the most used Infobox on the English Wikipedia...

I speak with major experience here. When I recently wrote Module:Person date, the LAST infobox I added it to was {{Infobox person }}, not the first.

I get and understand the inclination to push forward code that you think is an improvement but you need to start small and build. I flat out guarantee you that when you insert this into the first few infoboxes you are going to find bugs and areas for improvement. You want that to happen with an infobox with as few uses as possible. Not {{Infobox settlement }} with well over half a million.

I don't have time to give specific feedback for your code right now (I will do my best to later today as I do have a few thoughts) but my STRONG advice to you is to find an infobox with fewer than 100 uses and start there instead of here.

Again, I like what you are doing and will reiterate that I think it has great potential... But also to be clear, I will object to an insertion of this to {{Infobox settlement }} at this point. Zackmann (^{Talk to me} /_{What I been doing} ) 16:29, 3 December 2025 (UTC) [reply ]

Thanks for your response. Certainly after consensus about its labels, I will start from small ones, and I will inform you about results. Best regards. Hooman Mallahzadeh (talk) 16:51, 3 December 2025 (UTC) [reply ]

Good plan. I'll give more specific feedback tonight when I'm off work. Again, keep up the good work. Don't let the feedback get you down, keep chugging away and feel free to continue to ping me with updates. Zackmann (^{Talk to me} /_{What I been doing} ) 16:55, 3 December 2025 (UTC) [reply ]

@Zackmann08, @Joy, @Redrose64 and any other interested parties:

Off the back of the UK place infobox talk and the continued discussion above with adding distances to the infobox, I thought best to open a new section to flesh this out some more. I have created a demo template which when placed on a place (or general location) page can generate an automated approximate distance from it to its country capital. It can be tested in preview mode without saving a page, but I have also provided an optional parameter to customise the place by using the Wikidata ID so it can be tried out in a sandbox. The template does need coordinates in WD for the page.

{{User:The Equalizer/sandbox/Template:Capital Distance}}

can be used standalone on a page. Adding |qid=Q100 for Boston

{{User:The Equalizer/sandbox/Template:Capital Distance | qid=Q100}}

creates this output:

-->

Article - Boston

Capital - Washington, D.C.

Country - United States

Distance from article place to capital: 390 miles (634 km)

-->

Let me know if this has some merit for further development.

Regs, The Equalizer (talk) 02:35, 4 December 2025 (UTC) [reply ]

So while I applaud the effort, I respectfully, don't see the use for this. As I have stated elsewhere, if I am looking at the article for Boston (using your example), I really don't care how far it is from the Washington D.C.. This tells me nothing of note about Boston and certainly nothing that I feel belongs in the infobox, and that is the key point here. Now if you were to convert this into an inline type template that could produce a sentence like: "Boston is located 390 miles (634 km) NNE of Washington D.C. " that is an entirely different discussion. Not sure how useful that would be, but I certainly would not object to it being used in articles.

At the moment, I maintain my objection that this information does not belong in the infobox. If my goal of logging on to the internet is to find out "how far city X is from its nation's capital", I'm not turning to an encyclopedia. I'm turning to either Google or ChatGPT/Siri/Alexa/etc. Now looking at the Infobox for Boston or "Tiny Town in middle of Wisconsin" I may well want to know where the heck it is... But that is what the Mapframe/Pushpin Map is for. Telling me that it is 390 miles from DC doesn't really tell me anything of use other than how far from the capital it is. It doesn't help me understand where in the world it is in any real way. I still don't understand the use case for how it helps anyone understand where a place is by saying it's X miles/km from another city, even if that city is the capital.

Maybe it would be useful for small countries? But when you start looking at the distance of Sacramento, CA from Washington, the distance between cities in Russia, India, Australia, Argentina, etc. I just don't see how knowing you are hundreds or thousands of miles from a city helps anyone with anything besides that specific trivia fact that is so much easier to obtain with a Google/AI query. Zackmann (^{Talk to me} /_{What I been doing} ) 03:01, 4 December 2025 (UTC) [reply ]

It's completely fine if you don't care how far it is from somewhere. You just have to fathom that in the body of readers of an article like Boston, which is... 130 thousand people a month, there are some readers who do care for that and consider this key information that tells them something important about Boston. --Joy (talk) 11:42, 4 December 2025 (UTC) [reply ]

Virtually nobody needs this feature. From MOS:INFOBOXPURPOSE: The less information that an infobox contains, the more effectively it serves its purpose, allowing readers to identify key facts at a glance. Does any encyclopedia, atlas, or other reference work about places prominently state each place's distance from a capital? Joe vom Titan (talk) 17:06, 6 December 2025 (UTC) [reply ]

So, you speak for everybody? :) The first thing that popped into my mind was to check what does the Britannica say about Perth. At https://www.britannica.com/place/Perth-Western-Australia there's no infobox, but there is a map with a scale immediately next to the first paragraph. The first mention of distances is in the second paragraph, where it says It was linked to Adelaide (in South Australia) by telegraph in 1877 and received strong impetus for growth from the discovery (1890) of gold at Coolgardie-Kalgoorlie (374 miles [602 km] east). Compared to noting the distance to Coolgardie-Kalgoorlie exact to a mile/kilometer (!), I think listing general distances to other major places is entirely mundane. --Joy (talk) 19:25, 6 December 2025 (UTC) [reply ]

I then checked Boston there. Same thing about the map and scale. This one showed me "Top Questions" between the heading and the first paragraph, and the #2 item is "Where is Boston located in the United States". Sadly the AI answer didn't list distances, just directions (northeastern). The third paragraph is after the "Landscape" heading, where it goes into a large amount of detail about the geographical location. --Joy (talk) 19:32, 6 December 2025 (UTC) [reply ]

Those look like nice examples of including geographical details, including distances from other places, in the body of the article. Thanks for that research. – Jonesey95 (talk) 02:29, 9 December 2025 (UTC) [reply ]

I'd probably realign my proposed template to create prose that calculates distance between the article place and another named place. Regs, The Equalizer (talk) 11:54, 10 December 2025 (UTC) [reply ]

So for use in an infobox, we could just use the variables 2 and 4 from your draft?

For example, the Perth article now has these parameters:

:| dist4 = 3632 :| dir4 = WNW :| location4 = [[Canberra]]<ref name="Distance"/> :

This could be changed to have the value of location4 looked up by a prospective {{geographic distance|capital|name}} call?

And the value of dist4 could be looked up by a prospective {{geographic distance|capital|value}} call?

That seems quite useful already.

It could also be further integrated into infobox syntax if the template would provide a prospective syntax such as:

{{geographic distance|capital|nameandvalue|WNW|of}}

which would then show some sort of a simple, standard rendering like "$distance 3ドル 4ドル $name"? --Joy (talk) 11:40, 4 December 2025 (UTC) [reply ]

Also, obviously, if we could have argument 1ドル of the prospective {{geographic distance }} template parsed for a special string like capital but also for an arbitrary string, which could be looked up as a Wikidata entry name of some type, then this would allow for distances to other major points of interest as well (and in the case of Perth, we could use it to replace the hardcoded values for Adelaide, Brisbane, Melbourne and Sydney, too). --Joy (talk) 11:45, 4 December 2025 (UTC) [reply ]

Problem with Perth is that it is using the Infobox Aus Place so the template pulling in distances for all the main cities would have to be customised. I like the passing of the cardinal into the template to allow it to show. The text certainly is adjustable, my solution was just to prove the distance from the capital could be obtained with automation using very little coding efforts from a template editor as Zackm was reluctant to have to code it in with the UK infobox migration, how we integrate with the infobox would have to be determined once we get a consensus. Regs, The Equalizer (talk) 13:36, 4 December 2025 (UTC) [reply ]

Oh, we're in agreement there. I just mean there's many ways to integrate this functionality at various points of rendering infoboxes. It can happen in the articles calling the infoboxes, in the wrappers, or in the infobox settlement, depending on circumstances and consensus about where it's best. --Joy (talk) 14:05, 4 December 2025 (UTC) [reply ]

Just a follow on from this Joy - I've made some improvements on this to use for any migrated UK box and in the existing Aus box, It has an option to script it as inline prose or adds a bulletpoint to each line.

 {{User:The Equalizer/sandbox/Template:Capital Distance3|Q5112|Q34932|Q3141|Q3130|addcapital=yes|qid=|precision=|format=}}

I have also added the cardinal which auto populates. All the parameters are optional, but add one at least one Q# to measure a distance. Add a Q# to the qid= to allow it to measure from a sandbox or other page that doesn't have coords, can leave it off a page which has coords, it will use that as default. Format is either list or inline, precision for decimal points. Addcapital, leave blank if not needed.

The above code uses the main Aus cities in the article for comparison. I used it on the Perth page in the est parameter field to place the layout together with the existing and it compares well and wraps text ok etc - in fact it highlights the existing figures in that page, Brisbane maybe other Aus places are miles off... also it's not quite the same layout as used in the UK box but that's a minor right now.

Regs, The Equalizer (talk) 16:52, 17 December 2025 (UTC) [reply ]

What are the plans for disputes over whether the Aberdeen infobox should measure to Edinburgh or to London? CMD (talk) 03:07, 18 December 2025 (UTC) [reply ]

This could theoretically accommodate both, but the sometimes complex relationships with countries' subdivisions means Wikidata (which my template uses) is mostly summarising that detail at very high level. Regs, The Equalizer (talk) 10:15, 18 December 2025 (UTC) [reply ]

• Definitely not something that should be in the infobox causing more bloat considering it's not even relevant enough to be in prose within the article itself. (As reiterated by multiple editors above in previous discussion). This is a great example of misleading and irrelevant data... As no one travels in a straight line and these kilometers are meaningless when it comes to time parameters of travel.Moxy 🍁 19:16, 9 December 2025 (UTC) [reply ]

  Geographic distances are not misleading just because they don't help readers exactly understand travel distances. This is a general encyclopedia, not a travel website. (WP:NOT#HOWTO.) --Joy (talk) 08:12, 10 December 2025 (UTC) [reply ]

  Yes but why would we intentionally add data that is confusing and misleading? Unless you plan to specify that the distances listed are direct distances, and not travel distances, this serves no helpful purpose. Zackmann (^{Talk to me} /_{What I been doing} ) 08:15, 10 December 2025 (UTC) [reply ]

  Wait, I thought I addressed this just now :) like I said above, I do not think geographic distance data is confusing or misleading. It's akin to the standard scales on maps. Sure, it can be nicely clearly labeled. (Did someone say it shouldn't be?) If they appear in an unhelpful manner in practice somewhere, let's fix it. Thinking about it now, I noticed that in the Australian template they usually appear with a cardinal direction. Maybe that makes it clearer? --Joy (talk) 08:27, 10 December 2025 (UTC) [reply ]

• Per Joe vom Titan and Moxy. This is not a key fact to be add to infoboxes and contrary to MOS:INFOBOXPURPOSE. Cinderella157 (talk) 00:11, 10 December 2025 (UTC) [reply ]

  One thing about this functionality to call out - it should be an optional feature, not a mandatory function, editors should choose whether to add it or not. Other infoboxes are using distance measure to other key locations to give a basic idea of where a place is. Using the name of a subnational region or area it is within isn't always enough. We shouldn't depend of maps alone to portray an idea of where something is due to accessibility reasons. No one is disputing having that detail within the prose of the article as the detail is genuinely useful to educate readers. Regs, The Equalizer (talk) 11:02, 10 December 2025 (UTC) [reply ]

  As at the UK place infobox discussion, I am also opposed to the inclusion of this field in the settlement infobox. I consider it bloat. And the more optional and flexible it is, the more inconsistent the articles and the wilder the arguments will be about all sorts of petty things, like should the distance be as the crow flies or by car or train; should a distance be given to a county town even though it may be tiny and insignificant; should distances be given to cities in a neighbouring (and possibly hostile) country if close to the border etc. It won't just be useless bloat, it will be divisive and time consuming useless bloat. Dgp4004 (talk) 11:46, 10 December 2025 (UTC) [reply ]

  Surely people can already have the exact same kind of arguments for every other infobox field? --Joy (talk) 11:53, 10 December 2025 (UTC) [reply ]

  There certainly are similar infobox fields which are equally hard to reference such as elevation. And I would also support removing such fields.

  How can we reference where the centre of a large city is? Should it be a landmark? The town square? The railway station? A random point calculated from the appropriate edges of a settlement on a map? Which map? Should the centre move if somewhere expands? Should it be the centre of its local authority district? What if the local government area is far bigger than the city? It's going to be very difficult to provide a reliable source for these distances because we can all calculate it in a different way. I seem to recall somebody kept repeatedly adding a note to the Birmingham infobox on where the exact zero point of the city was. Dgp4004 (talk) 12:27, 10 December 2025 (UTC) [reply ]

  That's too much. The distance measure is meant to be indicative/mean due to the varied ways a settlement is determined. An encyclopedia isn't a final authority on these things, it's meant to be a summarised high-ish level view of the topic. If a detailed look at geography concepts is desired a textbook on the subject or study is always going to be a better place. Wikidata holds coordinates for places and those are used extensively now and is broadly accepted use. Regs, The Equalizer (talk) 13:11, 10 December 2025 (UTC) [reply ]

  I agree, it's too much. 'If a detailed look at geography concepts is desired a textbook on the subject or study is always going to be a better place.' - Or perhaps a map, we're all agreed on the need for a map. The infobox is not the place for such detail as a list of distances to random places. Dgp4004 (talk) 14:13, 10 December 2025 (UTC) [reply ]

  Maps are great but to me a means to an end - I mentioned to @Cinderella157 above the limitations such as the visually impaired unable to use a screen reader with a map. Wiki maps may display a scale marker but not advanced tools such as a ruler or route measure so a diagonal or meandering road route is not easily measurable. I think it is accepted that the detail ideally is included as prose maybe in article lead certainly in body, just this thrashing out of whether it gets included in the box. Regs, The Equalizer (talk) 16:54, 10 December 2025 (UTC) [reply ]

  Clearly you're not going to gain consensus for this by the wider community for this template overall. At this point the discussion should turn to is this a valid parameter for any settlement template like Australia's. Question should be... does the community think a subset of articles should contain information that the wider community feels may be misleading or irrelevant for inclusion at all. Moxy 🍁 17:10, 10 December 2025 (UTC) [reply ]

  A list of distances to distinct places is far less of a showing of distances to random places compared to a map. A mapframe in particular, which allows for arbitrary panning and zooming across the world, is so far beyond the narrow scope of a short list of key distances, it's genuinely bizarre to me that we're having this discussion. --Joy (talk) 19:58, 10 December 2025 (UTC) [reply ]

  The capital of a nation is not a "random place". Also, far from being a list, only one is relevant therefore only one is given; very occasionally (places near a border) two may be warranted, but never more. --Redrose64 🌹 (talk) 21:20, 11 December 2025 (UTC) [reply ]

  Sure. Please tell those who want to ban the list altogether :) --Joy (talk) 22:41, 11 December 2025 (UTC) [reply ]

• Agree with Zackmann08 and Moxy, this is needless clutter in the infobox. -- P 1 9 9 ✉ 00:44, 16 December 2025 (UTC) [reply ]

I'm not sure personally what percentage of visitors are specifically looking for the distance to Washington DC or any other capital from a city. This just seems useless to me. Pineways (talk) 14:01, 31 December 2025 (UTC) [reply ]

It's not for that - this is for educating readers who want to generally read up on a place they have never heard of and get a semblance of what, when, where, how, who and why. This template can be added to any settlement box now without code changes, the UK and Australian ones use an earlier take of it. I put a mockup of those infoboxes using distances in my testcases page. Regs, The Equalizer (talk) 20:48, 31 December 2025 (UTC) [reply ]

I monitor Category:Pages using infobox settlement with unknown parameters (0) daily and am constantly fixing errors. One of the most chronic is people adding |image= (it needs to be |image_skyline=. Is there some historic reason that we do NOT support |image= as an alias to |image_skyline=?

Does anyone object to me adding |image= so that it will work in addition to |image_skyline=? No plan to change any existing transclusions, just allow for both to work. Zackmann (^{Talk to me} /_{What I been doing} ) 22:17, 8 December 2025 (UTC) [reply ]

Redundant parameters often lead to more burden in the future, because someone has to look for both |image=foo and |image_skyline=foo cases, and inevitably they (or I) will forget to search for one of them, leading to bugs.

I never understood why it's called |image_skyline= anyway: most of the settlement images are not of skylines per se (i.e., they aren't an outline against a horizon). — hike395 (talk) 00:49, 9 December 2025 (UTC) [reply ]

I mean the alternative is to replace |image_skyline= with |image=, but that seems like a ton more work than its worth.... Zackmann (^{Talk to me} /_{What I been doing} ) 00:53, 9 December 2025 (UTC) [reply ]

Or this parameter was initially envisioned for a big city with a cool skyline image, but then in practice a variety of settlements need a variety of far less glamorous pictures :) --Joy (talk) 08:50, 9 December 2025 (UTC) [reply ]

• No objection to adding |image= as a alternative for |image_skyline=, but just make it an undocumented feature. -- P 1 9 9 ✉ 00:48, 16 December 2025 (UTC) [reply ]

  That was EXACTLY my thinking. Let it work, just don't advertise that it works... Shall be a secret Zackmann (^{Talk to me} /_{What I been doing} ) 00:53, 16 December 2025 (UTC) [reply ]

  The parameter is so obvious that will just lead to eventually people start using it more, then some will get confused, complain why is it not documented properly, and then we'll document it anyway. Might as well skip the charade. --Joy (talk) 08:45, 16 December 2025 (UTC) [reply ]

That is fine by me too. I see absolutely no problem with a dual parameter for lead image (if nested {{{image_skyline|{{{image|}}}}}}, then there will be no issue when people inadvertently use both). -- P 1 9 9 ✉ 15:04, 16 December 2025 (UTC) [reply ]

At this 2023 RFC, a consensus agreed the "native_name" parameter can "be used to display an alternative placename that is used by First Nations peoples".

My questions regard its use at Seattle:

• Should the name be in English? Currently it is "dzidzəlal̕ič".
• Should the name be one that is currently in use by First Nations people, or a historic First Nations name? (If 0.3 percent of Seattle is Native American, this is likely a historic name)
• Should other former/historic names be merged into this template? Europeans first called Seattle "Duwamps", "New York" and "New York Alki".

Thank you. Magnolia677 (talk) 15:31, 11 December 2025 (UTC) [reply ]

No to the first and last items. Also, native people are very much still around despite the prodigious efforts of invaders, so I would advise caution in describing native names as "historic".

I'm surprised to see that the name is not preceded or followed by the language name. For Seattle, I would expect it to read "Lushootseed: dzidzəlal̕ič" or "dzidzəlal̕ič (Lushootseed)", as we see at e.g. Newport, Wales or Augsburg. – Jonesey95 (talk) 16:23, 11 December 2025 (UTC) [reply ]

Let me see if I have this straight...the Welsh are first nations to Wales, the Germans are first nations to Germany, and the Scotts are first nations to Canada.

"The less information that an infobox contains, the more effectively it serves its purpose", per MOS:IBP. And because this parameter is so frequently misused, the less value it is to readers.

Do we need an etymology in the first sentence of the article, the top of the infobox, and within the article? Magnolia677 (talk) 21:46, 11 December 2025 (UTC) [reply ]

Yes, less is better! Cinderella157 (talk) 00:57, 13 December 2025 (UTC) [reply ]

As mentioned multiple times.... we need to change the title of this parameter. Not the place to list all minority translations. "With respect to nationhood, the first language (native name) is defined by the language used by the "vast majority of the inhabitants" and is the dominant language spoken by the population in a particular region; though this may not be the official language. Moxy 🍁 22:31, 11 December 2025 (UTC) [reply ]

@Jonesey95, Cinderella157, and Moxy: Should this go to an RFC? Magnolia677 (talk) 11:30, 15 December 2025 (UTC) [reply ]

Agree Seattle RfC maybe needed to determine the communities path on this one case. Must be aware we have {{native name}} for the 'main language that people use in a region or country other than English.......{{Name in official languages}} that I believe by template name is self-explanatory.....and for unofficial minority languages we have {{Name in various languages}}. Moxy 🍁 21:36, 15 December 2025 (UTC) [reply ]

@Moxy: Might be best to do the RFC here, as it is specific to this template. What do you think? Magnolia677 (talk) 15:24, 16 December 2025 (UTC) [reply ]

What question would be proposed? Looking to merge all the different language templates? Moxy 🍁 16:00, 16 December 2025 (UTC) [reply ]

@Moxy: My concern is that this parameter has become a catch-all. To some, it is an Indigenous name for the place (regardless of whether Indigenous people ever lived there). To others, it is the name used by the first people who settled there, such as Welsh, Germans or Scots. I would suggest deprecating all the languages, and adding the etymology to the text. Magnolia677 (talk) 16:13, 16 December 2025 (UTC) [reply ]

As someone with no horse in this race (I'm kind of indifferent to the outcome and don't have a strong opinion on which way to go on this) I do think an RFC would be helpful here. To Moxy's point, (and based on my own RFC experience) I would just make sure you construct said RFC with a clear list of options for people to !vote on as opposed to an open ended question of "what the heck do we do about this problem". Just my unsolicited 2cents. Zackmann (^{Talk to me} /_{What I been doing} ) 16:44, 16 December 2025 (UTC) [reply ]

I generally agree with the comments regarding an RfC. As I see it, there are two issues: there is the specific case of Seattle and there is the more general question that Seattle represents. An RfC for the more general could be seen as overturning or refining RFC on usage of native_name parameter for First Nations placenames. The conclusion of the RfC is that it is permissible for the "native_name" parameter be used to display an alternative placename that is used by First Nations peoples and that it does not only apply to places where said First Nations people are the dominant ethnic group. Just because something is permissible in an infobox, it does not mean that we should or must do it. We are guided by INFOBOXPURPOSE that less is better and it is for key facts.

I see several issues with including dzidzəlal̕ič in Seattle's box. It is an obscure name (based on the number of speakers of Lushootseed) and not a key fact. Reading the article on Lushootseed, I gather (I may be wrong) that it is a spoken language and that its orthography is a modern construction to preserve the language. I was surprised by an historical native American language base on Latin characters. Skeptically, I wonder if it is a neologism (The name for the modern city of Seattle in Lushootseed, dzidzəlal̓ič ...) or whether it was used historically for the European settlement. I saw this in the infobox and thought WTF is that?

As a general observation, the nuance and detail of names and nicknames is probably best left for a section on names and (per INFOBOXPURPOSE) a section in the TOC would substitute for such entries in the infobox.

The more general question is less cut and dried IMO. Looking through the archive discussions (see search [4]), the intent in the discussions appears to reflect the template doc: Name or names in the local language, if different from name, and if not English - eg München at Munich. However, in some [English speaking] countries (New Zealand, I believe) the native and English name have dual official status. We also have an example such as Uluru/Ayres Rock - officially gazetted under both names and well known by both names. In such a case, the two names are arguably both key facts. I see that some of these points were made in the previous RfC. IMO, there will be cases where it is appropriate to include a First Nations name and others, when it is not. The question to be asked should differentiate such cases.

The previous RfC asked whether the parameter could be used for a First Nations name - not when it should be used. The second part asked whether the First Nations people needed to be the prominent ethnic group. The outcome of the previous RfC is not surprising since there are a significant number of cases where the First Nations name could be considered a key fact and not just a factoid. When is it a key facts is what we need to determine. I suggest that this occurs when it more generally known - ie outside of the particular place (or nearby) and outside a small group of people. How does one then phrase this as an RfC question - I am not certain at the moment. Cinderella157 (talk) 02:11, 17 December 2025 (UTC) [reply ]

I'd like to address a few points to keep us focused on policy and the existing consensus.

1. Regarding the population statistics (cited as 0.3%, though Census data indicates ~0.6–2%): We need to be careful not to re-litigate settled matters. The 2023 RfC explicitly asked: "Should this only apply to places where said First Nations people are the dominant ethnic group?" The consensus was No. Arguments relying solely on the fact that Indigenous people are a minority in Seattle are effectively asking to overturn that RfC. The community has already decided that dominance is not a prerequisite for inclusion.

2. I agree that infoboxes should contain key facts, but the assertion that the Indigenous name for Seattle is "obscure" overlooks a critical encyclopedic connection. The city derives its name from its First Peoples, being named after Si'ahl (Chief Seattle). The Lushootseed name (dzidz∂lal′icˇ) is not a random translation; it is the original name used by the people from whom the city takes its name and who first lived there. Comparing this to colonial placeholders is a false equivalence with temporary exonyms. The Indigenous name represents a continuous cultural presence and the etymological root of the location's history. It is a key fact by any definition of place history.

3. There seems to be some confusion regarding Lushootseed. The orthography is the academic standard for writing Salishan languages. It is not a "neologism" or a "modern construction" in the fake sense; it is simply how the language is written in reliable sources and by the community today. Wikipedia follows sources, and we shouldn't remove valid data based on personal skepticism about non-Latin scripts.

4. I must object to the tone of some comments above. Referring to First Nations names as "random minority dialects" is unhelpful. It trivializes a complex topic and borders on being dismissive of the living history we are trying to document. Please let’s keep the discussion focused on encyclopedic value rather than cultural grievances.

Proposal I agree that clarity is good. The solution to confusion regarding the spelling is not deletion, but better formatting and accessibility. I support changing the display to include the English pronunciation:

Lushootseed: dzidzəlal̕ič{{efn|Anglicized pronunciation: ''Dzid-zil-ahl-itch''}}

This satisfies MOS:IBP while respecting the 2023 RfC. (talk) 12:42, 22 December 2025 (UTC) [reply ]

This response appears to misconstrue or misrepresent a number of points raised in my comment. The response states: I must object to the tone of some comments above. Referring to First Nations names as "random minority dialects" is unhelpful .... Neither I nor anybody else in this section used the phrase "random minority dialects". The etymology (it being the name of one of 17 indigenous settlements in the bay area) tells us how the name was selected but not when.

Wikipedia follows sources, and we shouldn't remove valid data based on personal skepticism about non-Latin scripts. What I said is: Reading the article on Lushootseed, I gather (I may be wrong) that it is a spoken language and that its orthography is a modern construction to preserve the language. I was surprised by an historical native American language base on Latin characters. It is an oral language with no tradition of writing - ie the orthography is a modern construction to preserve the language and it is based on Latin characters. My skepticism is whether dzidzəlal̕ič was used historically [by the indigenous population] for the European settlement or the name for Seattle is a recent addition to the vocabulary. The statement: the original name used by the people from whom the city takes its name and who first lived there, is an unverified assertion and no comparison was made with colonial placeholders.

I used the proportion of native speakers as an indication of the obscurity of the name. The argument that this is a key fact rather than simply a factoid is based on assertion rather than verifiability. The RfC being referred to is permissive, not mandatory. I give examples where it is seen to be appropriate and rises to being a key fact consistent with reporting it in the infobox per INFOBOXPURPOSE. Aboriginal Australians are a small minority of the population, with only a small proportion speaking a First Nations language. Despite this, some Aboriginal place names are well known (ie not obscure).

Reading the comment by PK-WIKI below, I believe they are expressing similar concerns to mine, albeit in a different way - reasons why the name should not be reported in the infobox here. Cinderella157 (talk) 03:37, 23 December 2025 (UTC) [reply ]

@Magnolia677 When starting a discussion like this please notify other users who are part of the discussion. @Slakr I'm pinging you because you settled the previous RFC. @Pinchme123 I'm pinging you because you are involved with a discussion on Seattle, @PersusjCP I'm pinging you for the same reason and because it seems you actually speak this language being discussed. Poketama (talk) 13:12, 22 December 2025 (UTC) [reply ]

Thank you for the ping.

I agree with Jonesey95 and Poketama that, in Seattle's specific case, it should provide the language of origin. I prefer: dzidzəlal̕ič{{efn|Anglicized pronunciation: ''Dzid-zil-ahl-itch''}} (Lushootseed) for consistency between articles with no apparent justification for the difference, but only have the two examples from Jonesey95 to go off of. Regarding the broader discussion all of Poketama's numbered arguments hold true for me as well and wish to point out the dichotomy displayed in one comment above, between listed European cultures as having "settled" a place, while questioning whether Indigenous people ever lived there at all (there is a complex issue with this related to living patterns – roughly, nomadic, semi-nomadic, and sedentary – where preferencing sedentary cultures/populations would be inappropriate).

I would think any RfC here would be about setting forth principles for how to maintain consistency between infoboxes when displaying {{native_name}}, given the outcome of the 2023 RfC; it would not seek to overturn that RfC or limit Indigenous place names' presences in the infobox, but could provide guidance on which Indigenous name to use when multiple are involved.

--Pinchme123 (talk) 17:21, 22 December 2025 (UTC) [reply ]

I fully support using this parameter to surface Lushootseed place names when the native word is WP:DUE. Examples might be when it is the etymological base of the current or former name, is an officially adopted name by the city, and/or if the name is in widespread use. Mukilteo, Carnation, and Mount Rainier are all examples that should display Lushootseed.

However, I very strongly disagree with providing "translations" for every single PNW place name on Wikipedia. WP:NOTDICTIONARY / WP:NOTDIRECTORY / WP:NOTDB. This type of usage is absolutely not in common use for all places in Washington state, as it likely is in a country like Ireland.

I'm especially wary of displaying translations in large text on the second line of the infobox on one of the most popular sites on the internet. This gives the impression that these are official names or in widespread use. Often, they are not. Often, they amount to essentially neologisms that have been applied to unrelated settlements well after the fact and have never enjoyed widespread use (or any use at all) that can be cited in reliable secondary sources. As it pertains to Seattle, the two WP:TERTIARY sources currently cited for "dzidzəlal̓ič" do not indicate any real usage of this term as a name for the city of Seattle at all. This was previously discussed for Stanwood, Washington as well.

We must follow Wikipedia:Neutral point of view and and be wary of WP:UNDUE weight given to these translations. Wikipedia needs to reflect reliable secondary sources on the matter. Our purpose isn't WP:ADVOCACY for the Lushootseed language or to WP:RIGHTGREATWRONGS. The prominent display of these names on Wikipedia WILL generate partial citogenesis that is undue for the current usage of many of these translations. PK-WIKI (talk) 20:00, 22 December 2025 (UTC) [reply ]

I think whether the name is well sourced is a fair question. However, the question of: is the name relevant enough for the infobox is a given. Yes, if its a name of the city used by people native to the region its entirely relevant. Poketama (talk) 15:00, 24 December 2025 (UTC) [reply ]

I don't think that view is nearly as widely held as you are making it out to be, and would be unlikely to find consensus in an RFC.

For example, it would be entirely inappropriate for Washington, D.C. to display "Anaquashatanik" in large letters on the second line in the infobox. Even if the people native to the region ever did or still do use that "for the name of the city". The article describes a NEW federal district built in the 1790s. Discussion of previous geography or settlement in the area is important for the body of the article, but the prominence of placement of some past/current name and the juxtaposition of statements in the infobox is WP:UNDUE given the sourcing. The same name would perhaps be WP:DUE for prominent placement at articles like Anacostia or Theodore Roosevelt Island.

For Seattle, the sourcing for me points to the native name being undue for the infobox. Where as somewhere like Mukilteo it would be due. PK-WIKI (talk) 18:44, 24 December 2025 (UTC) [reply ]

This argument about the continuity of place is worth a policy discussion in its own right as its been had again and again. As for if First Nations names would pass an RFC, they did. Its in the first line of this discussion. Poketama (talk) 05:30, 26 December 2025 (UTC) [reply ]

WP:5P2 is one of our Five Pillars and Wikipedia:Neutral point of view is non-negotiable, and the principles upon which it is based cannot be superseded by other policies or guidelines, nor by editor consensus. PK-WIKI (talk) 19:21, 26 December 2025 (UTC) [reply ]

• As mention many times over the past two decades native name has a specific academic meaning. Perhaps best we implement a parameter as seen at Template:Name in various languages alongside our Template:Name in official languages into the template to avoid all this confusion around the meaning of native name versus indigenous name. When referring to language "native name" means the dominant language of a region. We should not be misleading our readers about what the dominant language is in a region or area.....let's just implement various language name template and have editors discuss the merits of what to include at each individual article over arguing over a parameter that seems to be widely misunderstood. Moxy 🍁 16:09, 24 December 2025 (UTC) [reply ]

My preference would be to deprecate this confusing parameter, and add etymologies to the text of the article. This could only happen via RFC. Magnolia677 (talk) 19:09, 24 December 2025 (UTC) [reply ]

Just because an infobox has a particular parameter does not mean that we should or must use that parameter. How we populate an infobox is guided by MOS:INFOBOXPURPOSE and the maxim that less is better. We need to discern between key facts and interesting factoids, noting that the infobox is a supplement to the lead and the article should remain complete without the infobox. On the subject of names more broadly, the Big Apple or the Windy City are widely known nicknames that reasonably rise to being a key fact but in many other cases, nicknames for cities are less widely known and only have a local or regional significance. In many cases, these interesting factoids about names are best left to a section in the body of the article where the TOC will quickly direct the reader. In other cases, a mention in the lead might suffice, without necessarily requiring it also appears in the infobox. Cinderella157 (talk) 01:00, 26 December 2025 (UTC) [reply ]

The argument that this is a factoid or trivia mischaracterises the data. The Indigenous name is a primary historical and current identifier, distinct from nicknames.

To address the readability concerns I have proposed using a footnote style for the pronunciation. This keeps the infobox visual footprint minimal while preserving the key fact. Poketama (talk) 05:46, 26 December 2025 (UTC) [reply ]

You argue that native name has a specific meaning regarding the dominant language. However, this specific interpretation was the subject of the 2023 RfC, where the community explicitly rejected the requirement for demographic dominance (Question 2: "No").

Re-litigating the definition of "native" in the context of this specific article ignores that global RFC outcome. Poketama (talk) 05:44, 26 December 2025 (UTC) [reply ]

Obviously the obscure RFC did not solve anything ....we're looking for a solution....please join in. Moxy 🍁 00:08, 27 December 2025 (UTC) [reply ]

So sorry you feel the RfC was "obscure".

I oppose this proposal, based upon the discussion so far and the lack of value in arguments of those supporting this change, setting aside their concerning characterizations of longstanding Indigenous place names as "factoids" (possibly because oral tradition is being relegated to second place behind written codification, which is also being downplayed because languages' writing conventions are somehow too new to be counted) and the misguided understandings of the outcome of the 2023 RfC. There's no problem here that needs a solution beyond what that RfC already provided.

--Pinchme123 (talk) 22:23, 27 December 2025 (UTC) [reply ]

obviously we're all here because there's still an ongoing problem with debates about the meaning of the parameter. Why anyone would reject clarification of a parameter is beyond me. Moxy 🍁 01:44, 28 December 2025 (UTC) [reply ]

Looks like we're here because editors aren't respecting the 2023 RfC result. It doesn't need clarification, it needs to be followed. --Pinchme123 (talk) 02:38, 28 December 2025 (UTC) [reply ]

Yes everyone that disagrees with you is bad and should be immediately sanctioned. Or we solved the problem. Moxy 🍁 02:49, 28 December 2025 (UTC) [reply ]

Any reason you're talking about sanctions and moralistic evaluations when no one else has brought them up? Additionally, yes, the "problem" has already been "solved". Time to move on. --Pinchme123 (talk) 06:44, 28 December 2025 (UTC) [reply ]

Support some kind of a change here regarding parameters and/or their current display in the infobox. Rome, Dublin, and Seattle are three unique situations and, per WP:NPOV, should not necessarily be displayed the same. PK-WIKI (talk) 19:25, 26 December 2025 (UTC) [reply ]

Just a comment... I have not kept up on this discussion and have no particular feeling about the outcome as long as CONSENSUS is reached. However, I do want to voice that this will likely set a precedent for the nearly 200 infoboxes that use the parameter |native_name=. So that needs to be considered carefully. I might recommend taking this discussion/proposal to the village pump with a formal RFC, then tagging the above Infoboxes talk pages with {{Discussion notice }} as this will have FAR reaching implications. Additionally consider what changes might need to be made to {{Native name }} and {{Native name list }}.

Again, I'm not arguing for any particular outcome here. Just want to make sure that ALL participants consider the fact that this discussion and its implications extend FAR beyond just {{Infobox settlement }}. If this discussion stays on this talk page, it needs to be made clear that any consensus reached here only applies to {{Infobox settlement }} and should not be used to mass change all 180+ Infoboxes without a much larger discussion. Zackmann (^{Talk to me} /_{What I been doing} ) 00:10, 27 December 2025 (UTC) [reply ]

• Renaming to something like "local_name" would probably help reduce potential confusion and better fit the usage and match the description of Template:Native name. Renaming rather than removing would preserve the use in the nearly 200 infoboxes without much disruption. CMD (talk) 23:25, 27 December 2025 (UTC) [reply ]

I request an update to the documentation for the |native_name= parameter. The current text restricts usage to the "first language" or "main language," which directly contradicts the consensus established in the 2023 RfC.

The 2023 RfC explicitly asked: "Should this only apply to places where said First Nations people are the dominant ethnic group?" The consensus was no. The documentation was never updated to reflect this, leading to confusion in current discussions.

Current text: Name or names in the local language, if different from name, and if not English. In this case "native" does not necessarily mean indigenous but first language (the main language that people speak in a region or country). This will display below the name/official name.

Proposed text: Name or names in the local language, if different from name, and if not English. This parameter may be used for the name in the de facto local language (e.g. German for Munich). Per the 2023 RfC, it may also be used for names used by First Nations/Indigenous peoples, regardless of whether they are the dominant ethnic group in the location.

Notes:

Link to the closed 2023 RfC

The current documentation is factually incorrect regarding community consensus and is currently causing disputes on Talk:Seattle. Poketama (talk) 13:05, 22 December 2025 (UTC) [reply ]

Not done: it's not clear what changes you want made. Please detail the specific changes in a "change X to Y" format and provide a reliable source if appropriate. Zackmann (^{Talk to me} /_{What I been doing} ) 17:09, 22 December 2025 (UTC) [reply ]

Under the heading Parameter names and descriptions, subheading Name and transliteration, within the native_name parameter, please change the Description from "Name or names in the local language, if different from name, and if not English. In this case "native" does not necessarily mean indigenous but first language (the main language that people speak in a region or country). This will display below the name/official name." to "Name or names in the local language, if different from name, and if not English. This parameter may be used for the name in the de facto local language (e.g. German for Munich). Per the 2023 RfC, it may also be used for names used by First Nations/Indigenous peoples, regardless of whether they are the dominant ethnic group in the location.". Poketama (talk) 14:50, 24 December 2025 (UTC) [reply ]

@Poketama: it sounds like you are requesting a change to the documentation (Template:Infobox settlement/doc) which is not a protected page... -Zackmann (^{Talk to me} /_{What I been doing} ) 15:16, 24 December 2025 (UTC) [reply ]

think it's best we implement Template:Name in various languages as native name has a specific academic meaning that seems to be lost on many people. Moxy 🍁 15:52, 24 December 2025 (UTC) [reply ]

@Poketama: I will also say, while I have no opinion on the outcome, it would seem there is an ongoing discussion above that should be resolved before any changes are made. Zackmann (^{Talk to me} /_{What I been doing} ) 15:54, 24 December 2025 (UTC) [reply ]

Zackmann, thank you for pointing out that mistake and I'll keep it in mind for the future. There seems to be a misunderstanding regarding the "ongoing discussion." The discussion above is about the application of the parameter on a specific page (Seattle). It can't retroactively invalidate the community-wide consensus established in the 2023 RfC (Question 2: "No" to dominance requirement).

The documentation currently contains a factual error. It states a restriction ("must be first/main language") that the community explicitly voted to remove. Updating the documentation is a strictly administrative maintenance task to ensure the page reflects the current binding consensus.

Moxy, regarding the 'academic meaning', that exact argument was central to the 2023 RfC and was rejected by the consensus. We cannot keep the current documentation in a state that contradicts the actual closed RfC result. Poketama (talk) 06:09, 26 December 2025 (UTC) [reply ]

Agree we need to change it. I like "local_name" CMD suggestion above. This would move the debate about what to include to individual pages. Its a hard one when you have people familiar with the term and those unfamiliar with the term arguing over what the term means over merits of inclusion. No one reads documentation pages so there is constantly a debate over usage of the parameter because of its actual meaning despite what an RFC says. Thus parameter name change may help this. Moxy 🍁 01:34, 28 December 2025 (UTC) [reply ]

is it possible to have the map display above other images? EnTerbury (talk) 23:58, 23 December 2025 (UTC) [reply ]

@EnTerbury: there are hacky ways to do it... But it shouldn't be done. The order is supposed to be the way it is for consistency... What page are you looking at/what is the goal you are trying to achieve here? Zackmann (^{Talk to me} /_{What I been doing} ) 00:14, 24 December 2025 (UTC) [reply ]

so for subdivisions that dont have flags but use images like grand est i think the map belongs above the images. i noticed the matter on search when a thumbnail appears for an article. to me it implies some sort of representation which i dont necessarily agree with for subdivisions. for actual settlements like paris i dont mind EnTerbury (talk) 01:43, 24 December 2025 (UTC) [reply ]

It sounds like you don't care what order the images display on the article, but you want to suppress the infobox image in the search results. |class=notpageimage in a File: call is the typical way to do that. It looks like we don't have |image_skyline_class= in this template, so we can't pass that image class, but it could be added to the code for this infobox. – Jonesey95 (talk) 23:42, 24 December 2025 (UTC) [reply ]

@Jonesey95 no, i do think the map should display on top, and more importantly, i do think the map should be the thumbnail. EnTerbury (talk) 02:27, 25 December 2025 (UTC) [reply ]

Making a change to over a half million pages because one editor doesn't like the way 2 or 3 pages displays is most likely a non-starter... If you feel strongly that this order should be changed, you are certainly welcome to continue the discussion and see if there are others who feel this order should be changed, but I would temper your expectations. Zackmann (^{Talk to me} /_{What I been doing} ) 02:30, 25 December 2025 (UTC) [reply ]

The OP is not asking for the order to be changed in every infobox, or even in the article they linked to. Their initial question was an XY problem error. They really want to prevent the top infobox image from being the PageImage. I think the parameter addition above may allow editors to make that change on a per-article basis. – Jonesey95 (talk) 04:57, 25 December 2025 (UTC) [reply ]

Guess I misinterpreted their follow up response. Zackmann (^{Talk to me} /_{What I been doing} ) 05:33, 25 December 2025 (UTC) [reply ]

both of you are half right and half wrong, so thats on me for being too terse. anyway. it seems to me the original sin here is using infobox settlement (a template optimised for settlements) instead of infobox country (a template optimised for administrative divisions of the planet) for administrative divisions, though im sure theres a great wp reason for this arrangement. cheers. EnTerbury (talk) 07:53, 25 December 2025 (UTC) [reply ]

I've opened a discussion regarding also this infobox here. --Friniate ✉ 20:28, 28 December 2025 (UTC) [reply ]

In 3 places we are currently allowing for a user to set |image_sizedefault= for images in this template. This makes no sense to me... You can set the |image_size= for any transclusion... Why would you ever need to set or change |image_sizedefault=?

The ONLY use case I can think of is for wrappers of this template to set a custom default for their transclusion... Based on my reesearch this is done for exactly ONE template, {{Infobox Australian place }} which sets |image_sizedefault=frameless. Is this needed? Zackmann (^{Talk to me} /_{What I been doing} ) 18:28, 2 January 2026 (UTC) [reply ]

I think I saw this to be based in the WP:IMGSIZE policy, we're not supposed to be encouraging people to enter pixels, yet we do, and the frameless thing is the way to start fixing that? Not sure about the specific semantics of sizedefault, though. I checked Module:InfoboxImage now and its documentation says frameless is the default already? --Joy (talk) 19:06, 2 January 2026 (UTC) [reply ]

Default is indeed frameless so any objection to removing this? Zackmann (^{Talk to me} /_{What I been doing} ) 19:12, 2 January 2026 (UTC) [reply ]

No objection here. Moxy 🍁 19:55, 2 January 2026 (UTC) [reply ]

I looked further into the history, and it seems I carried it over from the existing code during the latest big conversion, where it had originally been added in this big 2013 edit that had no specific explanation for those frameless parameters, and it doesn't seem to have been discussed in detail at the the talk page discussion about that conversion either. --Joy (talk) 11:33, 3 January 2026 (UTC) [reply ]

Wait, but that's exactly it. The global sizedefault = frameless default is effectively *undone* by the implementation in Infobox settlement, which sets it to pixels instead.

If we're thinking about changing this, we should instead remove the hardcoded pixels here. --Joy (talk) 12:04, 3 January 2026 (UTC) [reply ]