Jump to content

Template talk:Infobox settlement

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Unreliable maps automatically imported from OpenStreetMap

[edit]

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:

Map
Tehran is located in Iran
TehranHHH
Tehran
Tehran in Iran
Tehran is located in Asia
TehranHHH
Tehran
Tehran in Asia
Map
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]

Capital distance measure

[edit]

@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]
Well, they don't have the same concept of an infobox, so it's not a trivial conclusion about the body. Should we remove our infoboxes because they don't have them? --Joy (talk) 17:01, 6 February 2026 (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 don't think this is useful, we provide maps and coordinates and the prose can better help locate an entity, with the prose being able to mention distances when that is supported by a reliable source. Traumnovelle (talk) 19:19, 6 February 2026 (UTC)[reply]

Image param

[edit]

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]
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]
I think |image should be made the main parameter with image_skyline just being removed from documentation/template. I don't support mass changing image_skyline to image. Traumnovelle (talk) 19:20, 6 February 2026 (UTC)[reply]

Native name parameter

[edit]

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 "dᶻidᶻə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: dᶻidᶻəlal̕ič" or "dᶻidᶻə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 dᶻidᶻə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, dᶻidᶻə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 [1]), 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: dᶻidᶻə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 dᶻidᶻə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: dᶻidᶻə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 "dᶻidᶻə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]

Proposal

[edit]
  • 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]

Issue with coordinates...

[edit]
Moved to Module talk:Coordinates § Issue with inline coords
 – Zackmann (Talk to me/What I been doing) 02:53, 19 December 2025 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Infobox settlement
Coordinates:  

So I keep coming across pages where the |coordinates={{coords|...|display=title}}. The issue with this is that the logic in the if statement sees that {{{coordinates}}} is not empty, and therefore renders the Coorindates: text. See the example at right, note I have used a nbsp to achieve the same result here so as not to throw random coords on the talk page title.

We should fix this somehow... The options I see include:

  1. Detecting if |display=title and if so, hiding the Coordinates: text.
  2. Somehow modifying Module:coordinates so that in certain circumstances you can use the coordinsert functionality to change the display from just title to title and inline, though I now realize that would still require detecting what the current value of |display= is. We don't want to run into errors because the coords are defined as inline in the infobox then at the bottom of the page there is a 2nd set of coords defined for the title...

Open to any suggestions! Zackmann (Talk to me/What I been doing) 23:04, 14 December 2025 (UTC)[reply]

@Jonesey95 and Hike395: any thoughts on this? Zackmann (Talk to me/What I been doing) 18:40, 15 December 2025 (UTC)[reply]
Looks like the coordinates module already has some helper functions that parse the display parameter value, so maybe just make sure they are exported in a namespace from which they can be reused? --Joy (talk) 19:42, 15 December 2025 (UTC)[reply]
Not sure how exactly that would look. I'm only able to picture an additional function that would return the a parsed display parameter. Zackmann (Talk to me/What I been doing) 22:33, 15 December 2025 (UTC)[reply]
Can we test the output of |coordinates= to see if it wants to display the inline portion? Alternatively, can we somehow inject display=inline into the parameter, maybe with a string replacement? – Jonesey95 (talk) 01:02, 16 December 2025 (UTC)[reply]
Exactly what I am thinking, just not really sure how to do that... Happy to dive into it though. Mainly wanted to sanity check that I wasn't missing something obvious before I went down the rabbit hole. Zackmann (Talk to me/What I been doing) 01:04, 16 December 2025 (UTC)[reply]
This is a total hack and will definitely have negative side effects (I think), but {{Str rep|1={{coords|1|1|N|3|3|E|display=title}}|2=-hidden noexcerpt|3=}} might be fun to play with. – Jonesey95 (talk) 02:18, 17 December 2025 (UTC)[reply]
Because there's no mention of 'display' or 'inline' or 'title' in the second or third parameters, nobody will remember what it does tomorrow. Let's not make it more complex and less likely to be maintained. --Joy (talk) 08:19, 17 December 2025 (UTC)[reply]
I'm referring to isInline() and similar functions, Module:Coordinates#L-633. With a few relatively small interventions, this could be brought out of the local scope and we could conceivably use it to quickly check the display value from the outside. --Joy (talk) 08:47, 16 December 2025 (UTC)[reply]
Hmm that could certainly help! I'll get into this later this week and see if I can't mock something up in the Sandbox. Zackmann (Talk to me/What I been doing) 16:46, 16 December 2025 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Template-protected edit request on 22 December 2025

[edit]

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]

order of images

[edit]

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]

Infoboxes for former municipalities

[edit]

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

I've opened a discussion at the village pump (proposals) on the matter. --Friniate ✉ 14:28, 9 January 2026 (UTC)[reply]

image_sizedefault

[edit]

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]
@Zackmann08 if there's no objection, I'll do the latter. --Joy (talk) 15:05, 7 January 2026 (UTC)[reply]
I'll be honest I don't completely understand what frameless does. I just want to make sure we don't see an explosion of image sizes. Besides that concern, no objection from me! Zackmann (Talk to me/What I been doing) 15:44, 7 January 2026 (UTC)[reply]
|frameless is like |thumb in that it scales images to 250px wide, or whatever their user preference is. The main difference from |thumb is that there's no border; other differences are that any caption is hidden unless you mouseover (when it shows as a tooltip) and it doesn't float unless you specify |right (or |left) explicitly. See WP:EIS#Type. --Redrose64 🌹 (talk) 23:18, 7 January 2026 (UTC)[reply]
So if we look at the diff of the previous change, are we safe to remove those:
  • |sizedefault=250px
  • |sizedefault={{#if:{{both|{{{pushpin_map_narrow|}}}|{{{pushpin_map|}}}}}|85px|100x100px}}
The first one seems safe to kill, right?
About the second one, template params tool says pushpin_map_narrow is used by 350 calls, so that part should be maintained somehow. But can we do that and switch to upright style? By the looks of it, this is mostly about Chile, so it sounds reasonable. But strictly hardcoding 85 and 100 pixels, not so much. --Joy (talk) 06:35, 8 January 2026 (UTC)[reply]

If you want to use a default that is "like" 85px or 100px, but scales with user preference, then the right answer is to set |upright=0.4 (for 100px) or |upright=0.34 (for 85px) or even |upright=1 (for 250px) instead of |sizedefault=. This will supply a default size that scales with user preference.

Hope this helps. — hike395 (talk) 06:26, 10 January 2026 (UTC)[reply]

Later -- I tested this, and it doesn't quite do the right thing, because 100x100px is not the same as upright=0.4 @ 250px -- 100x100px makes sure that the maximum of the width and height are 100px, while upright=0.4 only sets width=100px. — hike395 (talk) 08:03, 10 January 2026 (UTC)[reply]
Okay, but if we use this for various flags and other emblems, why would we even want to enforce the 1:1 aspect ratio anyway, and potentially cause images to be twisted wrong? --Joy (talk) 08:31, 10 January 2026 (UTC)[reply]
I implemented this in the sandbox, and I can see an issue in the Briarcliff Manor test case. The seal and the symbol should be the same height (100px, see left), but when you set |upright=0.4, you get something lopsided (see right) — hike395 (talk) 01:13, 11 January 2026 (UTC)[reply]
Note that 100x100 does not enforce 1:1 aspect ratio. It keeps the aspect ratio and scales the image so that the maximum of the height and width are 100px. — hike395 (talk) 01:59, 11 January 2026 (UTC)[reply]
Oh, so the meaning isn't an actual "size default", wonderful naming :) My browser says that picture has calculated aspect-ratio 82 / 100 in the live version, and 100 / 121 in the sandbox.
At the same time, it's hard to assess whether this is good or bad, because I can barely read the letters on Seal of the Village of Briarcliff Manor.png, too. Are these pictures supposed to be just vaguely decorative with the expectation that everyone will zoom in and/or click through, or are readers supposed to be able to see stuff on them without clicking through? --Joy (talk) 08:57, 11 January 2026 (UTC)[reply]
On this note, I checked the original article, and the labels are already not aligned perfectly there (the right-hand size image is aleady higher), and it's apparently at featured article standard. So this test case is also confusing, it's hard to say what would actually be wrong with the upright version. --Joy (talk) 09:06, 11 January 2026 (UTC)[reply]
Zackmann08 wanted to take over the sandbox: they can sync the sandbox and try their edit out. We can restore the upright hack when he's done. In the meanwhile, I'll let other editors decide whether to use |upright= or not here. What do editors think?— hike395 (talk) 00:21, 12 January 2026 (UTC)[reply]

Sandbox is restored to the new edit. Should we promote to main? What do other editors think? — hike395 (talk) 12:25, 12 January 2026 (UTC)[reply]

Let's note for the record that the 85 vs 100 change might affect articles using image_blank_emblem minus those that use a blank_emblem_size which overrides this. So according to TemplateParams right now, that's 3,990 - 1,919 = 2,071. The LA wordmark test cases use fixed blank_emblem_size values, so Briarcliff is the only one. Maybe we can find some more test cases to double check this, and/or cross-post to the image policy talk page where people who decided on upright usage presumably listen. --Joy (talk) 10:05, 13 January 2026 (UTC)[reply]

Political parties

[edit]

Is there a reason we have |leader_party= for |leader_name= but no |leader_party1= for |leader_name1=??? Zackmann (Talk to me/What I been doing) 03:15, 22 January 2026 (UTC)[reply]

Change native name parameter to first language

[edit]

As seen here we have a large segment of our population that equates the term native name to Indigenous peoples versus it's academic use related to first language. Really think we should swap out this parameter as it keeps causing problems as people simply don't understand the context of the parameter. (Native language). Change it to first_language or local_name.Moxy🍁 01:03, 24 January 2026 (UTC)[reply]

I think that sort of thing is best left to local adaptions of this infobox, like the Australian Place infobox discussion you cite. Personally, I think 'local name' or 'first language' is far less clear than 'native name'. And playing about with the name of this field would likely cause edit wars for UK council district articles which use this infobox, particularly in Northern Ireland and Wales. Dgp4004 (talk) 09:11, 24 January 2026 (UTC)[reply]
Its clear in the link provided that the interpretation of native name equates to Indigenous which is clearly not correct. The dominant native language (first language (L1), native language, native tongue, or mother tongue) maybe Indigenous in nature in some cases but most times it is not. And if I'm not mistaken it's really only Australia that has their own separate template for this correct? Moxy🍁 16:46, 24 January 2026 (UTC)[reply]
You are VERY much mistaken that only Australia has their own separate template... See Category:Templates calling Infobox settlement (30)... Zackmann (Talk to me/What I been doing) 17:01, 24 January 2026 (UTC)[reply]
Ok so a few - but with the vast majority using this template raw (no wrap}. Moxy🍁 17:36, 24 January 2026 (UTC)[reply]
Not sure what difference that makes?? Additionally, 30 is more than "a few". Also note those are the ones that have been place in the category... There are certainly more than have not. Zackmann (Talk to me/What I been doing) 20:44, 24 January 2026 (UTC)[reply]

Public transit and local airport in infobox

[edit]

There is a lengthy discussion at Talk:Culpeper, Virginia#Highways in infobox regarding including infrastructure like public transit and a local airport to the infobox of a mid-sized town. Your input would be welcome. Magnolia677 (talk) 23:17, 5 February 2026 (UTC)[reply]

Standardization of infoboxes

[edit]

For those who haven't seen the hubbub at Talk:Culpeper, Virginia, there's a lot of arguing about what does or does not belong in city infoboxes, including standard data that's always included - not just items specific to that article. Would it be prudent to have a guideline for what info should ALWAYS be included (basic stats such as population) and what information should be subject to specific criteria - for example, in the current discussion about airports they might only be included if they're international, or have commercial passenger service - with anything else subject to editor judgement (and consensus as needed) on a case by case basis? That would hopefully help minimize arguments like this where the information is included on some articles but not others, with no clear reasoning. I understand that article text should be unique, even if it covers the same general information as others, but templates are already standardized, so I don't see why inclusion criteria shouldn't be. Anything not qualifying but still deemed notable enough to mention can still be included in the article body. The criteria should be determined by subprojects, since such data varies by country.

If this kind of thing has already been discussed in the past, please point me towards those records. ChompyTheGogoat (talk) 11:54, 8 February 2026 (UTC)[reply]

Tread softly. I can tell you that Infoboxes are one of Wikipedia's designated Wikipedia:Contentious topics, and there has even been an Arbitration Committee case about it. I realize this doesn't answer your question, but I thought you might like to have some background, first. Mathglot (talk) 00:49, 24 February 2026 (UTC)[reply]
I thought contentious topics referred to the actual subject of the article, not tools used within it? ChompyTheGogoat (talk) 01:05, 24 February 2026 (UTC)[reply]
Nope. Even the MOS (neither tool, nor article) wrt capitalization of articles (!!) is subject to it. But you're right; most of them are about article topic areas; obvious ones, like Israel–Palestine, Abortion, and so on, but some very nonobvious ones, too (like a 16th century Samurai). Mathglot (talk) 01:12, 24 February 2026 (UTC)[reply]
Oof. That case makes this situation look like a picnic. It's largely simmered down, but without having reached any consensus on the specific content in question. Most involved editors seem to be in general agreement that guidelines/broader consensus on infoboxes is desirable, and ArbCom repeatedly recommended RfC which still seem to be avoided for unknown reasons? That seems like the best course of action to me as well. I don't have a strong opinion either way on the article/content in question - my priority lies with the potential desirability in uniformity of formatting across articles of a common type. I believe consensus at the project level for whether articles within that project are improved by the inclusion of infoboxes, and if so what contents they should contain, is the best way to maintain a positive user experience and also minimize editor conflict. I can appreciate that discussions at the project level would need to proceed with caution, given the history. Hopefully having numerous senior editors involved with no bone to pick on specific issues would help to maintain civility and focus. ChompyTheGogoat (talk) 02:09, 24 February 2026 (UTC)[reply]
Let's hope. Like you, I don't care that much how the content discussion comes out (I suppose I lean towards the too-full/leave it out crowd) but mostly just want it to be consistent. That view is also behind my comment at the DR thread, where I argued that a WP:CONLEVEL issue is involved, and the discussion is happening at the wrong venue. I guess it's also worth pointing out, that Infoboxes are also a point of contention, that is, not the content, but whether they should even exist at all. I thought that was one of the designated WP:CTOPICS, but apparently not. Mathglot (talk) 02:39, 24 February 2026 (UTC)[reply]
Yeah, I feel the city boxes are overly long in general, but I'd rather leave the inclusion or exclusion of specific items to the community. None of it will make or break an article.
I think that like me CSGinger was a bit overwhelmed by all the spinoff discussions and knew it needed more objective eyes, but wasn't sure of the best forum. If nothing else opening the DRN seems to have put a lid on the civility issues, so that's something. Avoiding ANI (let alone ArbCom) is a win in and of itself. Unfortunately I suspect that won't be possible in certain other situations... ChompyTheGogoat (talk) 02:58, 24 February 2026 (UTC)[reply]
We should get together and get some sort of consensus about file and info overload in infoboxes like at New York city (17 files) is an accessibility nightmare WP:INFOBOXTOOLARGE. As CMD said before " City infobox image bloat has been longstanding issue, and picture selections and arrangements are a common cause of dispute. However, it's reasonably entrenched, so any change would likely require very wide reaching RFC ". Moxy🍁 03:15, 24 February 2026 (UTC)[reply]
At least we made some headway on that point, but yeah. I think Culpeper just happens to be where these long standing issues finally boiled over. Or did so again due to not being addressed properly, as the case may be. ChompyTheGogoat (talk) 03:51, 24 February 2026 (UTC)[reply]
Although city articles in my view are quite bad they're are many bios that are simply outrageous in size Chiang Kai-shek. Moxy🍁 03:59, 24 February 2026 (UTC)[reply]
Oh good grief.

That's exactly why I've tried to be as general as possible with my wording - I raised this at the city level since it's the template used for the article in question, but I firmly believe all projects where infoboxes are used on a regular basis need to develop their own guidelines for implementation, or this will just continue to get rehashed periodically. There may need to be some kind of site wide directive requiring they do so. The fact that it's been allowed to go on for so long feels like a failure on the community's part. ChompyTheGogoat (talk) 04:17, 24 February 2026 (UTC)[reply]
We've had a lot of issues with this, even with basic population stats.
There's currently no requirement for the inclusion of infobox data to be referenced. This I think is pretty critical. In the lead sections, we summarize and don't place reference tags unless needed, because this naturally flows from referencing the main text. But in infoboxes, the context is probably a fair bit different, and the data is supposed to be better organized, yet can be conceptually disorganized.
And it's often unclear what is meant by "total", "urban", "metro" and whatever other population description is used. It's rarely clear which of these are really key points and if this has any relation to article sources, or if it's just arbitrary editorial choices.
Indeed, the inherent precision of the data is often in subtle fundamental conflict with the concept of a key point - it is probably a key point that a city has e.g. a population of around 150,000, but it's hardly important for the average reader to immediately have to know whether it's 156,732 in a census 15 years ago or 148,290 in a census 5 years ago.
So when even the basic data is messy like that, people often just tend to throw their hands up in the air and start tolerating stuffing infoboxes full of other data.
It has also been historically very unhelpful that the implicit standard has been that whoever first added an infobox, they added not just the fields they filled in, but all the various empty fields. These empty fields remained forever in the page source, regardless of whether they were actually prospective in context. Because the infoboxes are the first thing people see in the article source text, it's like moths to a flame, all sorts of stuff starts getting added.
The various images have probably been the most egregious thing, esp. when it's four rows of colorful pictures for a place that has very few landmarks. At the same time, the various clerical images have also been a consistent distraction, like the flags and the seals of tiny places. Likewise for time zone and other administrivia.
And then in turn this built up a bit of frustration with editors, where on talk pages it seems like everyone just wants to get rid of everything, and the pendulum swings the other way, and then we start trying to arbitrarily restrict additions because of this overwhelming previous debt.
Discussions about broad infobox standards should probably be done in a more general forum first, like the village pump, so we get a broad consensus, and then in more specific infobox talk pages, which are comparatively sparsely attended (this one is huge so it's an exception). --Joy (talk) 10:09, 24 February 2026 (UTC)[reply]
Well, there's a middle-ground venue, namely WP:WikiProject Infoboxes, which seems like the right place to me (an WP:APPNOTE at the Pump linking to it would be fine); otherwise I generally agree. Mathglot (talk) 10:40, 24 February 2026 (UTC)[reply]
It looks like that's mostly relating to technical aspects at the moment, although expanding the scope of the project certainly might be a reasonable step to help address the issue. It does mention improving standardization. However, I expect far more editors will have an opinion on infobox content vs those interested in technical implementation, so it might be best to start with pump to get an idea of what direction any plans should go, and take it from there. Developing broad guidelines will not be a fast or easy process. ChompyTheGogoat (talk) 18:49, 24 February 2026 (UTC)[reply]
Yeah, I saw that other discussion. I don't think most users are going to care about the minutiae that are often the subject of such debates - editors tend to get rather myopic about such things and forget WP:PURPOSE.
I will note that one of the benefits listed at WP:WPINFOBOX is Emission of machine readable metadata, which I do think is valid, but there needs to be a balance between that and stuffing it full of cruft that would never be considered for body inclusion. Maybe some such data should be included in a collapsed footer instead so it doesn't distract from the user experience. ChompyTheGogoat (talk) 19:08, 24 February 2026 (UTC)[reply]
I mean, isn't that in turn also the purpose of the Wikidata item link? :) --Joy (talk) 19:17, 24 February 2026 (UTC)[reply]
Despite the relative size, the Wikidata page for eg New York doesn't appear to contain common data such as zip and area codes. I also have no clue whether it's skimmed by external sources to the same extent Wikipedia is. ChompyTheGogoat (talk) 19:51, 24 February 2026 (UTC)[reply]
Isn't that indicative in itself - that even a data repository didn't attract this data. I think this is a hint to us that a lot of this data is a borderline WP:NOTSTATS violation. --Joy (talk) 08:49, 27 February 2026 (UTC)[reply]
Stuff it full, then collapse it so it doesn't distract from the user experience? Sounds like a very schizo infobox that doesn't know what it's about. I remember the good ol' days, when people read the article... Mathglot (talk) 19:50, 24 February 2026 (UTC)[reply]
Not in the main infobox, but a different footer template that would make it available for the small subset of users actually interested in such data. Not necessarily the best solution, just one possible compromise that came to mind. Such proposals really should be discussed wherever the larger conversation ends up taking place. ChompyTheGogoat (talk) 19:54, 24 February 2026 (UTC)[reply]

You still haven't provide an reasonable argument of WHY transportation trivia MUST be included in the infobox box, instead be placed only in the transportation section. Basically your argument is "I should be able to put any trivia in the infobox that I want at any time I want". Just because every little detail about the infobox hasn't been fully documented, it doesn't automatically mean there isn't any very long term concensus. BTW, the actual New York City article does have information in the Zip Code and Area Code fields, and if this information is missing from any infobox examples, then it should copied over. • Sbmeirow • Talk • 11:25, 26 February 2026 (UTC)[reply]

No it shouldn't, zip codes and area codes are pure unencyclopaedic infobox cruft. Traumnovelle (talk) 19:57, 26 February 2026 (UTC)[reply]
You'll always find many people love filling infoboxes with what many consider junk, that others consider relevant. It could be worse look at Melbourne they list totally misleading distances between places like people travel in a straight line. Very bad too make our readers think that driving from point A to point b is actually these numbers. Sometimes trivial spam is more important than factuality to the detriment of our readers and time sink for WP: CONTENTEDITORS Moxy🍁 20:57, 26 February 2026 (UTC)[reply]
It looks like that might be intended to give the location as it appears on a map, rather than actual driving distance - at least, that's my interpretation as someone who's studied mapping. But I don't find such a thing particularly useful to the average user, especially as someone who also lives in a region where there's always mountains or water in between two places and the only thing that can actually travel in a straight line is a helicopter. Anything that uses "as the crow flies" distances is extremely unhelpful (and we measure distance in time, not mileage). In any case, Wikipedia is not a guidebook - nor GPS - and the infobox already includes TWO visual maps, so a textual description of the location is a prime example of cruft, IMHO. ChompyTheGogoat (talk) 22:16, 26 February 2026 (UTC)[reply]
These repetitive screeds against geographical distances would be much easier to agree with if they weren't done like this - as blatant whataboutism in response to code data.
This is exactly what I meant above when talking about frustrations.
We are not in a good place with these sorts of forum-like discussions. We need to interrupt this cycle. --Joy (talk) 08:46, 27 February 2026 (UTC)[reply]
How is discussing what content belongs on articles "forum like"? They just gave a different example of the larger problem. The only issue I see is that this needs to go to RfC for wider (curated) input, since it's clear now that the issue is bigger than even project level. Once again I'm disappointed that the community just keeps letting it drag on and none of the senior editors have taken it upon themselves to solve it by now. I'm not trying to making sweeping changes as a new editor, but they're clearly called for here. ChompyTheGogoat (talk) 08:54, 27 February 2026 (UTC)[reply]
It's not just a different example, we had the exact same discussion before, where no amount of nuance about a new parameter was good enough to add it, but no amount of criticism of an existing parameter was good enough to remove it. We're repeating the same pattern and I doubt it's actually building a consensus. --Joy (talk) 09:04, 27 February 2026 (UTC)[reply]
That's my whole point. A few people with conflicting strong opinions on individual data points don't get anywhere and these will keep cropping up until it's addressed at a higher level. Broad guidelines for infobox use in general and individual items decided by project/category. Consistency benefits everyone and will save many future headaches. ChompyTheGogoat (talk) 09:40, 27 February 2026 (UTC)[reply]
I suspect you're on the wrong thread, because I'm not arguing for OR against the inclusion of any particular data. I just want them to be standardized based on consensus to put an end to these debates - even moreso now that I know it's been such a problem for YEARS that it was flagged as contentious. Continuing like this only proves that to be true. ChompyTheGogoat (talk) 21:54, 26 February 2026 (UTC)[reply]
Infobox consolidation implemented over the past decade despite the objection by content editors has led us to this path. We have consolidated all the data from so many different templates with so many different parameters that were stuck now arguing over which parameters to use all over the place. In some cases the community has been able to keep separate templates like Template talk:Infobox province or territory of Canada that only has parameters specific to its regional application. Even though the Template:Infobox Australian place wrap includes parameters implemented that the community at large has rejected be it in physical application or by a conversation. I do believe it's best to let the editors that actually work and construct these articles to do what they think is best and if there's something of great concern then a conversation could take place... over constant discussions about unwanted parameters for certain regions, provinces, states etc. Moxy🍁 22:35, 26 February 2026 (UTC)[reply]
But they keep turning into arguments like this, which often include opinions based on whether or not other pages list the information in question - when so often it is included on some but not others, as was the case here. By your method every single page for an article with an infobox would need to have a debate over whether or not each individual piece of information is useful enough to include on that particular article. It would make far more sense to have one large discussion with input from many experienced editors to define what should or should not be included in infoboxes for eg US cities. Then most subsequent debates can be put to bed simply by pointing to that consensus, except when there's something unique about a specific article/piece of information that someone believes merits inclusion against the main consensus.

Holding such discussions at the project level would help ensure that the parameters are decided by editors who work on that GENERAL category, but not just two or three who are specifically interested in a single article and may be inexperienced or biased. ChompyTheGogoat (talk) 23:23, 26 February 2026 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Infobox_settlement&oldid=1340735764"