Template talk:Infobox settlement/Archive 31

This is an archive of past discussions about Template:Infobox settlement. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Apologies if this has been discussed before; if so, just point me to it. But I've been fixing up the collages on a bunch of city pages, and I've noticed that the |width= parameter for {{Multiple image}}, often used to create the collage, varies. Sometimes it's around 280px, whereas other times it's 300. Is there agreement on how wide this infobox ought to be? {{u|Sdkb}} ^talk 12:16, 8 January 2021 (UTC)

The default width for the lead image in the infobox is 250px, which IMO is just fine. Any larger and the images, especially collages, will make the infobox too large. For many cities, the infobox is already far too long (we can't seem to stop adding more fields to it). Blowing up images larger than 250px will only make it worse. -- P 1 9 9  ✉ 14:32, 8 January 2021 (UTC)

if a person can't fit it in 250px max, they need to re-evaluate what the heck they are trying to shoe-horn in that space • Sbmeirow • Talk • 15:42, 8 January 2021 (UTC)

How does one fix these? Which settlement types are "good"? I spent like 5 minutes looking at the source and the docs but couldn't figure it out. GregorB (talk) 20:26, 18 January 2021 (UTC)

Pinging Galobtter, who created the category. – Jonesey95 (talk) 22:17, 18 January 2021 (UTC)

Looks to me like every page using Template:Infobox Switzerland municipality is in the category, but if you filter those out [1] it looks like it doesn't like things like "Municipality in Switzerland" or "City in California" or anything that includes the parent entity (e.g., this fixed one). I would imagine that not all of these should be fixed. Thanks! Plastikspork _―Œ^(talk) 17:49, 19 January 2021 (UTC)

These are settlement types that have a subdivision name in them or have multiple settlement types in them. It doesn't really make sense to have a subdivision name in a settlement type and that also makes it harder to generate short descriptions. Galobtter (pingó mió) 21:37, 20 January 2021 (UTC)

Indeed, e.g. this edit fixes the "bad settlement type" issue, and not having subdivision names in settlement types makes sense too. GregorB (talk) 11:13, 25 January 2021 (UTC)

I am making some changes to subtemplates of this template in order to fix Category:Pages with non-numeric formatnum arguments errors. If I have broken any transclusions of this template, all of my changes can safely be reverted back to yesterday's version of the subtemplates. – Jonesey95 (talk) 07:02, 28 September 2020 (UTC)

I think that I have fixed most of the errors. Numbers using commas as decimal separators, in contravention of MOS:DECIMAL, will probably show incorrect numbers. An error-tracking category could be set up for those. – Jonesey95 (talk) 07:17, 28 September 2020 (UTC)

There are some interesting edge cases left, like population references in the population parameters instead of |population_footnotes=, and some odd handling of negative numbers. If they are worth fixing, it will probably be best to set up some tracking categories within this template and its subtemplates, but it is probably best to let the category population decrease via the job queue before digging in to these stragglers. – Jonesey95 (talk) 00:55, 29 September 2020 (UTC)

Jonesey95: I unarchived this section because it seemed to be a good start to a discussion about the fact that this template is still putting pages into Category:Pages with non-numeric formatnum arguments. See, for example, 's-Heerenberg, where the markup

{{Infobox settlement 
...
| population_total       = ca. 8000
...
}}

puts the article in that category. (Separate issue is that ca. is deprecated in Wikipedia and it should be c.) —Anomalocaris (talk) 23:28, 18 February 2021 (UTC)

Also, Template:Infobox settlement itself is in Category:Pages with non-numeric formatnum arguments, and the reason is bad markup in Template:Infobox settlement/doc:

{{Infobox settlement 
...
| population_metro        = 4285832 (US: [[List of United States metropolitan statistical areas|13th]])
...
| population_blank1       = 5207434 (US: [[List of United States combined statistical areas|11th]])
...
}}

These two lines need to be fixed, and I leave it to others who understand how things are supposed to work to come up with replacement compliant markup. —Anomalocaris (talk) 00:13, 19 February 2021 (UTC)

Also, Template:Infobox settlement/doc specifically recommends Windsor, Ontario as example usage, and that article has three lines, each of which individually put the article into Category:Pages with non-numeric formatnum arguments:

{{Infobox settlement 
...
| population_total                = 217,188 ([[List of the 100 largest municipalities in Canada by population|23rd]])
...
| population_urban                = 276,165 ([[List of the 100 largest urban areas in Canada|16th]])
| population_metro                = 344,747 ([[List of the 100 largest metropolitan areas in Canada|16th]])
...
}}

Wikipedia needs to decide from one of these alternatives:

1. We don't care about Category:Pages with non-numeric formatnum arguments. Delete the category and don't worry about it.
2. We care about Category:Pages with non-numeric formatnum arguments, deprecate markup like in Windsor, Ontario, and don't allow for the display of population and rank on the same line in this infobox
3. We care about Category:Pages with non-numeric formatnum arguments and create formatnum-compliant markup to enable the display of population and rank on the same line in this infobox.

Well, which is it? I don't really care which one we choose, but we need to choose one. —Anomalocaris (talk) 08:06, 19 February 2021 (UTC)

A fourth option is to create a replacement for the formatnum function that is more tolerant of a variety of input and does not generate this tracking category, and then use that replacement here. – Jonesey95 (talk) 14:29, 19 February 2021 (UTC)

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

Add a field in the codes section for Nomenclature of Territorial Units for Statistics NUTS codes. Its an international standard used for European country divisions Bluealbion (talk) 02:52, 26 February 2021 (UTC)

 Not done for now: please establish a consensus for this alteration before using the {{edit template-protected}} template. — JJMC89 (T·C) 03:48, 26 February 2021 (UTC)

Hello, I have noticed that population in many settlement infoboxes are not updated. I presume it's because it has to be done manually(?) What if we made it so that if there is more recent claims about population on Wikidata then this data is fetched from wikidata? I have made it so for settlement and municipality infoboxes (population, area, land area, water area, population density) on Latvian wikipedia. OPTIONALLY - We could do it so that also area is updated and population density is calculated from these fetched values if they are more recent and with credible references.Liinisx (talk) 10:46, 5 March 2021 (UTC)

Please see {{Infobox settlement/Wikidata}}. – Jonesey95 (talk) 15:16, 5 March 2021 (UTC)

@Jonesey95 So you do not support the idea that there could be some "fetch wikidata" code in "Infobox settlement"? Even if it would fetch only referenced values from wikidata only in cases when manual input is with older date? And not even in the Population attribute? - Liinisx (talk) 14:13, 9 March 2021 (UTC)

There is no common guideline here, so I wanted to start a discussion. For example, some cities like New York City, does not include the state in the name parameter, while others like San Diego do. I believe it should not, and it should only include the name of the city/settlement itself. Eccekevin (talk) 22:53, 4 March 2021 (UTC)

It's the 50 largest cities (by population) that aren't suppose to include the state, per some newspaper guideline. I think this is stated somewhere in one of the general Wikipedia rules. • Sbmeirow • Talk • 23:29, 4 March 2021 (UTC)

It is fairly common for the title above the infobox to match the article title. • Sbmeirow • Talk • 23:29, 4 March 2021 (UTC)

I think this topic was discussed in the distant past. Please search the archive at the top of this talk page. • Sbmeirow • Talk • 23:31, 4 March 2021 (UTC)

There's this: [2] which says

Follow the examples. The name of the place is only "Chicago". "Illinois" is the state which in this example uses |subdivision_name1=. If at any point, the infobox decides to change the layout of how the infobox title is shown, and show it as "Chicago, Illinois" then it will just take the value from |subdivision_name1= without requiring any page edit. So to summarize, use |name= for the actual name only.

Eccekevin (talk) 00:08, 5 March 2021 (UTC)

The examples in the template page also give it without the State. I agree with Sbmeirow that additionally, the title of the infobox should match the title of the page. I think it should be made more explicit and made uniform throughout Wikipedia. Eccekevin (talk) 00:11, 5 March 2021 (UTC)

Unless there is disagreement, I think we should change the guideline on the template page to 'the parameter name should match the title of the page, and not include the State unless the title of the page also includes it'. Eccekevin (talk) 03:45, 9 March 2021 (UTC)

The name parameter is for the given name of the city. The state is just a geographic disambiguator and not part of the city’s given name. If it requires disambiguation by state, we have the article title. We also have other infobox parameters (e.g., subdivision_name1) to present a city’s state, as well as the opening line in the article, and if the city shares a name with one or more cities in other states we usually have a hatnote. This makes repeating the state a minimum of two times redundant and up to four times redundant in close proximity of each other. Wikipedia is not an mailing envelope. No need to make the name parameter look like the third line in a mailing address. Hwy43 (talk) 04:05, 9 March 2021 (UTC)

Agreed. How would you phrase it in the guideline? Eccekevin (talk) 20:58, 9 March 2021 (UTC)

@Frietjes: It looks like you were the one who implemented the module feature, related to the module in Old Oaks Historic District and this thread. It looks like the extra table is there to prevent the child box from adding horizontal rules from the geography class? I am wondering if we could use {{infobox|subbox=yes|data1={{{module|}}}}} instead. The reason why I ask is if you put a {{infobox|child=yes|...}} inside a data field that is passed to {{infobox}} then the infobox module generally fixes any linter errors, but (as far as I can tell) it doesn't work when there is another wrapping table in between. This is related to the thread at Template:Infobox Australian place. I suppose we may need to know most of the "use cases" before making any changes, but as far as I can tell, using the "subbox" method would be generally equivalent with a slightly higher transclusion depth. Thanks! Plastikspork _―Œ^(talk) 14:20, 17 March 2021 (UTC)

Plastikspork, should work. do we know if Old Oaks Historic District has linter errors? if not, then the problem is most likely with the "abuse" of the module parameter in Template:Infobox Australian place/sandbox. Frietjes (talk) 15:09, 17 March 2021 (UTC)

Old Oaks Historic District currently has no Linter errors. You can see them listed at the bottom of Page Information. For example, one of my talk archive pages has two Lint errors. – Jonesey95 (talk) 17:09, 17 March 2021 (UTC)

I'm looking at the template code (lines 2 and 9) and I'm trying to think of a valid situation where this template would be embeded in another template. The |embed= isn't even mentioned on the /doc page. If there isn't valid usecases for this, this should be removed. --Gonnym (talk) 21:46, 29 September 2020 (UTC)

The monthly report linked in the TemplateData section is always helpful when you want to know where and how a particular template parameter is being used in article space. In this case, |embed= appears to be used in five articles, at least as of the last database dump at the beginning of September. – Jonesey95 (talk) 22:45, 29 September 2020 (UTC)

Thanks for that. None of them are settlements and all seem needlessly embeding this template. Some, like Sinthan top are just duplicating the same data found in the other fields (it duplicates the |location= parameter), others are misusing it all together. --Gonnym (talk) 22:52, 29 September 2020 (UTC)

Only used in 1 article now, which can just have separate infoboxes. Let's remove this outdated feature. -- P 1 9 9  ✉ 16:00, 11 November 2020 (UTC)

 Done. – Jonesey95 (talk) 19:08, 8 December 2020 (UTC)

Gonnym and Jonesey95, I have temporarily restored it until we can figure out what to do with the articles using this parameter (most through Template:Infobox property development as far as I can tell). Thanks! Plastikspork _―Œ^(talk) 16:22, 12 February 2021 (UTC)

I'm sorry, why does anyone think it's a good idea to remove this functionality? Just because it's lightly used now doesn't mean it won't be more in the future. And just because only a few use it doesn't mean it's useless, it may easily have potential already for the articles it's currently used in. And I just saw Fort Bragg should have been using it, and I just placed it there. I think many military installations that are also settlements could use it. Why remove something that only makes article formatting better?!?? ɱ (talk) 21:54, 18 March 2021 (UTC)

The Template:Infobox settlement/cleaner is pretty amazing, but it looks like it hasn't been updated since 2014, and a lot has changed (e.g., latd/longd -> coordinates). Even better would be to have it read the templatedata to get the parameter order, which I think is possible since Module:Parameter validation reads it in Template:Infobox station. Does anyone want to help, or should I ask at WT:Lua? 98.230.196.188 (talk) 22:07, 22 March 2021 (UTC)

Population density should be calculated on land area rather than total area including water. Yours aye,  Buaidh  talk contribs 03:51, 19 December 2020 (UTC)

Agree, calculating density per land area is also recommended approach by Eurostat (see https://ec.europa.eu/eurostat/databrowser/view/tps00003/default/table?lang=en) and should be used instead of total area if land area is available. Template must be corrected. Dāvis Kļaviņš (talk) 08:02, 15 March 2021 (UTC)

@Jonesey95: What do you think of this proposition? - Liinisx (talk) 14:49, 24 March 2021 (UTC)

I have no opinion. – Jonesey95 (talk) 16:26, 24 March 2021 (UTC)

@Jonesey95: Ok, do you know, which users should I ask about this matter? - Liinisx (talk) 12:56, 26 March 2021 (UTC)

In this thread from many years ago it was suggested that we compute population density based on land area instead of total area. It was pointed out there that for many places, the difference is not significant, and that we just make sure we are not using too many digits. However, for some places it is significant and the local convention is to use land area. So, to resolve the problem, I would like to suggest a few possible solutions (1) have the infobox prefer area_land and fall back on area_total when it isn't available or (2) introduce keywords land and total as an alternative to auto to toggle between using area_land and area_total or (3) create new parameters population_land_density_... which would calculate/show the density based on area_land when set to auto. We could also optionally change the label to "Land density" and "Total density" when the two new keywords are used. What I don't want is to rely on the editor to code the calculation for the infobox. What does everyone think? Thanks! Plastikspork _―Œ^(talk) 14:00, 26 March 2021 (UTC)

I want ask if anyone can code these template boxes to automatically grab certain fields by from wikidata as a default value, like in the case with Template:Infobox person/Wikidata. Fields that would be useful to grab would be:

• coordinates Wikidata:property:625
• elevation_m Wikidata:property:2044
• population Wikidata:property:1082
• timezone data Wikidata:property:421

Automatically grabbing them as defaults from wikidata will reduce the burden for users filling out information in template boxes. I have not implemented wikidata fetches before so I don't want to screw stuff up--Cs california (talk) 22:46, 30 March 2021 (UTC)

Please see {{Infobox settlement/Wikidata}}. – Jonesey95 (talk) 03:00, 31 March 2021 (UTC)

I would like to propose that a new parameter be added to this infobox so that twin towns or sister cities can be added. Many thanks, Vesuvio14 (talk) 21:16, 6 April 2021 (UTC)

• Oppose as problematic. It's difficult enough to keep the relevant sections near the bottom of the city articles up to date and properly sourced. As such, adding to the infobox would have the same issues. To be honest, sister cities and twin towns are really of minor importance, and shouldn't be in an infobox, as it's meant to be a brief overview of important information, and this infobox is probably far too long already. BilCat (talk) 21:30, 6 April 2021 (UTC)

Would someone who is familiar with this template mind taking a look at how it's being used in South Tucson, Arizona. Someone tried to add some invalid parameters (|area_magnitude= and |leader_title5= and |leader_name5=) to the infobox and I can't figure out how to sort them out. The parameters |leader_title= and |leader_name= only go up to four and there's nothing about "area_magnitude" (at least I couldn't find it if there is) on the template's documentation page. I hid just in case there's a quick fix, but otherwise I guess the parameters should be removed if there's no way to sort them out. -- Marchjuly (talk) 05:38, 9 April 2021 (UTC)

|area_magnitude= was removed a few months ago. – Jonesey95 (talk) 13:22, 9 April 2021 (UTC)

When the coordinates field is written with display=inline,title it is displayed overlapping other text at the top of the infobox or the top of the page. I'm looking on a Mac using either Safari or Firefox. If this is not confirmed by someone who knows how to fix it, please ask and I'll post screenshots. Examples New York City (displays on top of DAB line) and Modi'in Illit (displays overlapping location name in infobox). Zero^talk 06:19, 21 May 2021 (UTC)

I brought this up at Template talk:Coord too. Not sure what the issue is exactly. ɱ (talk) 13:28, 21 May 2021 (UTC)

Likely not related to this infobox, see also Wikipedia:Village pump (technical)#Coordinates in title dropped down. Lots of other technical glitches at present, likely all related. -- P 1 9 9  ✉ 13:29, 21 May 2021 (UTC)

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

Want to add: leader_title5 leader_name5 Goswami21 (talk) 20:10, 2 June 2021 (UTC)

 Not done for now: please establish a consensus for this alteration before using the {{edit template-protected}} template. BilCat (talk) 21:29, 2 June 2021 (UTC)

I think it would be a good idea to make a new data section to include more geocodes to the template.

Specifically I was thinking the American FIPS and European Union NUTS codes. Many of these cover places that don't have ISO codes or postal codes. Any thoughts? Bluealbion (talk) 19:31, 4 June 2021 (UTC)

The FIPS article indicates that many have been withdrawn? Nikkimaria (talk) 01:53, 5 June 2021 (UTC)

oops, you are right (I thought they were still using them for counties). So correction I think we should add the GNIS id that replaced it as well as the NUTS codes. Bluealbion (talk) 03:38, 5 June 2021 (UTC)

Note that both example infoboxes in the template documentation (Chicago and Detroit) contain FIPS codes and GNIS IDs, though there aren't dedicated fields for them. Those |blank_name= parameters can also be used to display NUTS codes or anything else that may be thought relevant. Deor (talk) 04:05, 5 June 2021 (UTC)

Embedding the UNESCO World Heritage Site Infobox within the settlement Infobox works on web, but on mobile the embedded infobox is off center/improperly formatted. Examples: Fatehpur Sikri, Samarkand. Is the problem with this template or is it a different/deeper issue? Gowhk8 (talk) 16:53, 17 June 2021 (UTC)

 Done -- Great Brightstar (talk) 13:58, 26 June 2021 (UTC)

It seems like many of the articles listed on List of non-rectangular flags are drawing a rectangular border around non-rectangular flags. Is there a way to search for all uses of this template where the image in image_flag has transparent pixels on its border?

No, but you can just adding |flag_border=no to fix. -- Great Brightstar (talk) 14:05, 26 June 2021 (UTC)

I am working on a project where the Oral history of cities, towns e.t.c. are narrated by native speakers as a means of language preservation.

I need an additional table on the template where I could video.

Can some help me out Olaniyan Olushola (talk) 08:34, 2 July 2021 (UTC)

You can easily do this outside of the infobox. – Jonesey95 (talk) 13:23, 2 July 2021 (UTC)

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

Seen from article Táliga, I feel it's necessary to give even more strict limits for the size of flag, coat of arms, seal and logo, and not require many articles to set custom size via parameters if there is a very long image used there. As my suggestion, they should be limited into 100 x 100 square area. The source code is already available at the sandbox page, and you can see the effect at the test cases. -- Great Brightstar (talk) 08:03, 28 June 2021 (UTC)

 Done User:GKFX^talk 14:48, 3 July 2021 (UTC)

It seems very wrong. First of all, ISO 3166 allows only subdivision at first order or second order. By allowing third order, subdivision3, the module {{#invoke:ISO 3166|geocoord}} is wrong. Coordinate parameters therefore can write region:xx or region:xxx at first or second order only.
Additionally we should include another parameter set, type which take the order as type:adm1st, type:adm2nd or type:adm3rd. (We should also allow fourth order type:adm4th.)
Finally, the default last coordinate parameter is given as type:city(popn) but it is mostly useless. A much better default would be dim:fn(√area) see {{PH wikidata/power}} — Preceding unsigned comment added by Not Samuel Pepys (talk • contribs) 19:53, 13 November 2020 (UTC)

My work is Category:Statistic of Slovak places by Dušan Kreheľ group of templates with statistic informations about Slovak places. I was fork this Infobox template. The template reads some data from the Slovak statistical templates. The user does not have to fill them in.

Maybe would by good to have all in one template. What mind You?

✍️ Dušan Kreheľ (talk) 08:48, 20 July 2021 (UTC)

You should not fork Infobox settlement for this. Some of the templates look useful. If you are working on the infobox for Abovce, for example, you can enter {{Slovakia – Area|{{PAGENAME}}}} in the |area_total_km2= parameter. You should ask at Wikipedia talk:WikiProject Slovakia before making a mass change like this, however. – Jonesey95 (talk) 13:59, 20 July 2021 (UTC)

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

Hi y'all,

This template needs an additional parameter for "largest city," just like the template for US states. Thx. RealIK17 (talk) 01:25, 9 August 2021 (UTC)

Namely {{{LargestMetro}}} {{{LargestCity}}} RealIK17 (talk) 02:42, 9 August 2021 (UTC)

 Not done for now: please establish a consensus for this alteration before using the {{edit template-protected}} template. BilCat (talk) 05:49, 9 August 2021 (UTC)

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

With detailed 2020 Census data being released on August 12 at 17:00 UTC, there should be a {{show by date}}-wrapped "if" parser statement that adds anything in the United States and with 2010 data to a new (redlinked as I type this) Category:United States locations still using 2010 Census population data maintenance category. HotdogPi 00:11, 11 August 2021 (UTC)

 Not done: please make your requested changes to the template's sandbox first; see WP:TESTCASES. – Jonesey95 (talk) 18:11, 13 August 2021 (UTC)

Are there any objections to this change: Special:Diff/1031769801/1036019486? I noticed that the lines in this section are a little too close and sometimes even overlap; the result of my change can be seen especially at testcase 2, testcase 9, and testcase 16. — Goszei (talk) 01:11, 29 July 2021 (UTC)

Looks good to me. ɱ (talk) 01:17, 29 July 2021 (UTC)

Hm... on mobile view, my change's line-height of 1.2 overrides the default, which results in an undesirable display. The root of what I am observing seems to be the special style for geography infoboxes in MediaWiki:Common.css#L-438. I will have to look into this further: retracting my proposal for now (note: the testcase links are no longer representative of the original change). — Goszei (talk) 01:17, 29 July 2021 (UTC)

I did some more testing on desktop and mobile for this line-height fix, and I would like to propose this revision: Special:Diff/1031769801/1037700540. I have aligned the font-size with other major infoboxes (like Infobox person), and have aligned the font-size and line-height with Infobox country (another geography infobox). The changes can be viewed in the testcases (desktop and mobile). If there are no major objections, I will implement this diff in about a week. — Goszei (talk) 05:49, 8 August 2021 (UTC)

 Done in this revision: Special:Diff/1038986244. — Goszei (talk) 00:34, 16 August 2021 (UTC)

Can You add references to item names of population? It is only for population group name now.

It like me new keys in template:

• population_total_footnotes
• population_density_km2_footnotes

I need for Category:Statistic of Slovak places by Dušan Kreheľ and on max 3000 articles.

✍️ Dušan Kreheľ (talk) 06:06, 8 August 2021 (UTC) & ✍️ Dušan Kreheľ (talk) 05:40, 16 August 2021 (UTC)

This edit request to Template:Infobox settlement and Template:Infobox former subdivision has been answered. Set the |answered= parameter to no to reactivate your request.

Can someone please add the Tfm tag to both {{Infobox settlement}} and {{Infobox former subdivision}} because I'd like the latter to be merged into the former because of how similar they are? A former settlement just has a couple extra parameters that a current settlement doesn't have. No need to have them as separate templates, per this discussion. -- PK2 (talk) 06:08, 4 September 2021 (UTC)

 Done Primefac (talk) 11:17, 4 September 2021 (UTC)

I've updated this template to use TemplateStyles for its styling. On the way, I removed the mess of HTML that was the |module= parameter. It didn't look good with it. Using a module now there are some gutter rows when displayed (see #16 in /testcases). (I am honestly surprised that renders at all since I'm probably breaking the fostering algorithm on the MediaWiki side.) Just leaving a note here to see if there is heartburn. I think it might be fruitful to support the "module" case better in Module:Infobox with a dedicated parameter. Izno (talk) 18:03, 8 September 2021 (UTC)

it looks like this can be fixed in Module:Infobox using augmented string processing (see these proposed changes). a dedicated module parameter is not a bad idea, but there are also many places where child boxes are used outside of module parameters. Frietjes (talk) 19:47, 27 September 2021 (UTC)

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

Please add a new tracking category sandbox TerraCyprus (talk) 12:08, 28 September 2021 (UTC)

added. Frietjes (talk) 16:59, 28 September 2021 (UTC)

When you use the 'auto' template it automatically rounds the population density to 2 significant figures. Is there any reason for this? I would think rounding to the units density would be better but there might be something I'm not aware of. C1MM (talk) 16:46, 17 September 2021 (UTC)

there has been some discussion about this before. the obvious thing to do would be to round the sigfigs of area, but apparently that had some unintended consequences when the area had a lot of sigfigs. I imagine we could put a max and min on the number of sigfigs but generally use the sigfigs of area? Frietjes (talk) 17:01, 28 September 2021 (UTC)

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

Please add -- ***Tracking categories*** -- sandbox TerraCyprus (talk) 12:01, 28 September 2021 (UTC)

not done. it's not clear why this is needed when it adds more bytes to the transcluding articles. Frietjes (talk) 16:59, 28 September 2021 (UTC)

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

nothing is "needed", whole WP is not "needed", but it is helpful. TerraCyprus (talk) 02:13, 29 September 2021 (UTC)

 Not done This has already been objected to, hence it lacks sufficient consensus to proceed; reinstating the edit request template is disruptive. * Pppery * _{it has begun...} 04:16, 29 September 2021 (UTC)

The objection was accompagnied by "it is not clear why this is needed" - but I didn't claim it would be needed. On top I stated it is helpful. No one has demonstrated that this claim is untrue. TerraCyprus (talk) 11:40, 29 September 2021 (UTC)

(edit conflict) Curious as to how that edit is helpful? and do other iboxes with checks for unk. parameters have this? If not, do you plan to add it to all such iboxes? P.I. Ellsworth - ed. ^put'r there 04:19, 29 September 2021 (UTC)

Can you first explain why other section headlines are in the template? Maybe then you find an answer yourself? TerraCyprus (talk) 11:40, 29 September 2021 (UTC)

Deactivating edit request template - establish consensus first before re-filing a formal edit request please. firefly ( t · c ) 11:46, 29 September 2021 (UTC)

@Firefly: can you explain why? Is there a policy? TerraCyprus (talk) 11:49, 29 September 2021 (UTC)

@TerraCyprus - the general process for filing and handling edit requests is outlined here. It says that an edit request template should only be used if the change either has consensus or is clearly uncontroversial. This change is not uncontroversial as it has already been objected to, and I do not see a consensus to implement it. firefly ( t · c ) 11:54, 29 September 2021 (UTC)

@Frietjes and Jonesey95: What do you think about Category:Pages using infobox settlement with subdivision type not Country to detect abnormal settings like this. I only found that example because it had another issue, a missing value for type. TerraCyprus (talk) 11:45, 29 September 2021 (UTC)

It appears that other values are allowed. The documentation says |subdivision_type= should be set as follows: "almost always Country" but does not explain when or why. The TemplateData monthly report says that there are > 50 unique values in that parameter across all articles. Do you have any insight into these exceptions? – Jonesey95 (talk) 13:29, 29 September 2021 (UTC)

Also, have you thought about taking on Category:Pages using infobox settlement with unknown parameters, real errors, before attempting to deal with the sort of tidying that you have been taking on recently? I'm not telling you what to do, but there is some ugly stuff in that category. – Jonesey95 (talk) 13:31, 29 September 2021 (UTC)

I am trying to understand the rules on what is allowed in the settle type field. I have looked extensively for a list of rules or guidelines without success.

Stated instructions say, "Any type can be entered, such as...[examples]".

Implied restrictions come from the "Tracking categories" listed at the bottom of the template page. Category:Pages using infobox settlement with bad settlement type, states, "These are settlement types that have a subdivision name in them or have multiple settlement types in them."

So by implication:

1) Do not include specific names of places, ie the settlement name, nor its parent jurisdictions, or sub-jurisdictions. For example: use "State capital" rather than "State capital of New York"

2) Use only one settlement type. If more than one settlement type applies, select [??? please advise ???]. For example: use "County Seat" rather than "County seat & Census-designated place"

Is that correct? Are there other restrictions? Is there a list of approved "settlement types"? On several talk pages there has been discussion about preferring either, "Census-designated place" or "Unincorporated community" (or the merged title "Unincorporated area"). Is there consensus on this topic? Katrazyna (talk) 20:44, 13 October 2021 (UTC)

Yes, in general you are correct. But there is no hard rule on this because this infobox is used for places worldwide - many of which follow their own format. So be consistent with the format of other places in the jurisdiction of the article you want to edit (e.g. if you want to edit articles of place in New York State, follow the pattern of other places in NY or even in the USA). Regards, -- P 1 9 9  ✉ 12:26, 14 October 2021 (UTC)

My following comments only concern communities in the United States...

A) For county seats, I include both in the infobox & intro section. For example: "City and County seat"

B) Any community that is incorporated should be described using legal terms that are defined by each state in USA, which varies from state to state. See Places chapter by U.S. Census Bureau, which I added as a reference to List of cities in Kansas years ago. Please don't automatically change a term as a community increases or decreases in size, because in many cases a community has to legally request the term be changed. If you aren't sure how to describe a community, then look at their website (if they have one).

C) Census-designated place (CDP) is a term defined by U.S. Census Bureau, which is why I use "Unincorporated community" in the infobox and intro section, and add the following to the Demographics section.

"For statistical purposes, the United States Census Bureau has defined this community as a census-designated place (CDP)."

D) See how I handled CDP in the following examples: Bavaria, Kansas / Template:Saline County, Kansas / Saline County, Kansas#Communities

• Sbmeirow • Talk • 15:54, 14 October 2021 (UTC)

Sbmeirow, thank you for the response. Those are great examples, and I like the way you handled the unincorporated communities vs CDPs.

One question. When you put "City and County seat" in the infobox, doesn't that make it show up on the "Category:Pages using infobox settlement with bad settlement type" which means it is "bad"? Can you give an example of using both settlement types? Thank you! Katrazyna (talk) 23:51, 16 October 2021 (UTC)

Leavenworth, Kansas • Sbmeirow • Talk • 01:49, 17 October 2021 (UTC)

Sorry, Sbmeirow but Magnolia677 says that is against the rules and reverts every change that includes 2 settlement types. Reason: "per Template:Infobox settlement". Is there another "not against the rules of Template:Infobox settlement" way to indicate this? Katrazyna (talk) 23:41, 27 October 2021 (UTC)

Not sure which of the timezone templates is causing it, but this template can show broken links to timezone articles. For example on the article Cherokee nation, it links to UTC– 06:00 instead of the correct UTC−06:00. Zt-freak (talk) 13:51, 17 November 2021 (UTC)

That's a GIGO issue: the infobox contained |utc_offset=– 06:00 when it should have said |utc_offset=–06:00. Fixing the article is easier than bodging a fix in the template. Primefac (talk) 14:41, 17 November 2021 (UTC)

Why did it work for −05:00, but not for −06:00? Zt-freak (talk) 09:29, 18 November 2021 (UTC)

is there a parameter? bi (talk) 05:00, 24 December 2021 (UTC)

A discussion was opened at Template talk:Infobox German place#Dialectal version in the field of the German name with regard to the |German_name parameter (corresponding to |native_name in the more general template). 〜イヴァンスクルージ九十八［IvanScrooge98］（会話） 10:56, 6 January 2022 (UTC)

This edit request to Module:Settlement short description has been answered. Set the |answered= parameter to no to reactivate your request.

Module:Settlement short description uses |settlement_type= to generate a short description if one is not provided in the article. This is a request to change that module's code to convert the first character of the resulting short description into a capital letter, per WP:SDFORMAT. You can see a lower-case short description currently at Homokmégy. – Jonesey95 (talk) 01:31, 16 January 2022 (UTC)

I have added an edit request template here, hoping that someone with basic Lua skills can take a look at it. I do not have enough Lua knowledge to suggest a detailed change, but it looks like relevant lines may be one or more of the following:

39: function p.validate  (perhaps a gsub replacement pattern, or some elegant use of {{ucfirst:string}})
76: 	local settlement_type = p.validate(plain(args.settlement_type or args.type), "settlement type") or "Place"
???

Any help will be welcome. – Jonesey95 (talk) 07:03, 20 January 2022 (UTC)

 Done * Pppery * _{it has begun...} 21:11, 20 January 2022 (UTC)

I think that all Townships within Wikipedia should have their Public Land Survey System shown in the infobox. For Hollywood township this would be shown as: Township 117 North, Range 26 West, Fifth Principal Meridian of the Public Land Survey System. I have placed it under geography for the townships of Carver county but I believe it should be placed in the infobox to the right by underneath Coordinates or a new box on its own. Any thoughts? — Preceding unsigned comment added by BradMoe (talk • contribs) 21:15, 20 January 2022 (UTC)

I don't think this is necessary. Nikkimaria (talk) 22:13, 20 January 2022 (UTC)

See Wikipedia talk:WikiProject Geography#Project to standardize treatment of place names. Any views on the feasibility and value of a project to standardize collecting, validating and display place names on geographical templates would be welcome there. Aymatth2 (talk) 20:09, 31 January 2022 (UTC)

Currently, the Infobox settlement template automatically calculates population density based on total area, rather than land area. For example, in the article on Los Angeles County, California the population density is automatically calculated as 2,100 people per square mile (given population of 10,014,009 and total area of 4,751 square miles). In reality, the population density is 2,468 people per square mile, because only 4,058 of the 4,751 square miles in the county are land. Because humans do not live on water, population density should be calculated in terms of land area, not total area. Crossover1370 (talk | contribs) 21:16, 5 February 2022 (UTC)

What do reliable sources do? The article on population density appears to indicate that both methods are valid. Also, is land area reliably available in most articles? Should the template fall back to using total area if land area is not available? You might want to copy the live template to the sandbox and try to adjust the code and look at the test cases. – Jonesey95 (talk) 01:51, 6 February 2022 (UTC)

Yes, the template should fall back to total area if land area is not provided. Land area is available in many settlement articles, including all American settlement articles. The article List of countries and dependencies by population density uses total area, while List of U.S. states and territories by population density uses land area. Using land area is generally preferable to total area, as humans only live on land, and the water boundaries of a region can provide skewed total area figures. For example, the state of Michigan has a total area of 96,714 square miles, but a land area of only 56,539 square miles. Using the total area of the state would provide a skewed population density as nearly half of the state's area is water. Many counties in the U.S. (some of which use this template), especially on the coasts and Great Lakes, have a greater water area than land area, and using total area to calculate population density would provide an inappropriately low density figure. Crossover1370 (talk | contribs) 02:36, 6 February 2022 (UTC)

No, it should not fall back. Either it calculates on total area or land area, not both. If whichever one it's calculated on is not available, it shouldn't be displayed. Nikkimaria (talk) 03:07, 6 February 2022 (UTC)

Should there be a setting (ex. "auto land") to automatically calculate population density based on land area instead of total area? Crossover1370 (talk | contribs) 07:03, 7 February 2022 (UTC)

No. Pick one or the other - I don't have a preference on which - and go with that. What we're trying to avoid is giving the same field a different meaning in different articles. Nikkimaria (talk) 13:19, 7 February 2022 (UTC)

--Worldbruce (talk) 16:20, 21 February 2022 (UTC)

That is cool, but how many decimal places does it take for houseboats to show up in the population density figure? —Michael Z. 17:58, 21 February 2022 (UTC)

On Winnipeg Beach, I'm seeing |map_caption= specified once (current argument is "Town boundaries") but shown twice. I understand it being below the SVG map that is linked from the infobox (the intended behavior), but not under the location map, which appears to be generated from the coordinates. What's going on? I don't have time to reverse engineer this template's parameters at the moment. — voidxor 01:52, 26 February 2022 (UTC)

 Fixed It was a bug, now fixed. — hike395 (talk) 05:05, 26 February 2022 (UTC)

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

This is a separate request from the one above.

At the moment, when label 85 is displayed, and the qualifier "population_as_of" is displayed as part of that label, the label is displayed with the brackets surrounding the qualifier, and also the qualifier, in normal type instead of bold type as per the rest of the label (eg Population (2015 census) instead of Population (2015 census)).

Even if that is not enough of itself to make the infobox look weird (because normally the whole of every label is displayed in bold type), it also creates difficulties of inconsistency if anyone populates another label with a similarly qualified parameter. So, eg, if, as in Baucau Municipality, the label "demographics_type1 =" is populated with the similarly qualified parameter "Households (2015 census)", then that "demographics_type1 =" label will only be displayed as wholly bold, including the brackets and qualifier (ie Households (2015 census). Importantly, it is not even possible to address that problem by emboldening the qualifier of label 85, because that will only embolden what's between the brackets, and not the brackets themselves (ie Population (2015 census) and not Population (2015 census)).

So I now request what appears to be the only solution to this difficulty, which is to modify this template so that label 85 displays the whole of the label, including any qualifier and the brackets surrounding any such qualifier, in bold. Bahnfrend (talk) 11:23, 28 February 2022 (UTC)

I actually think it looks better with the "2015 census" not bolded. Perhaps the answer is to use additional parameters like |demographics1_as_of= to make the formatting more consistent? — Martin (MSGJ · talk) 12:48, 28 February 2022 (UTC)

Since the call for Households (xxxx consensus) comes from {{TL wikidata}}, this typeface change might be gnarly either way. Also, there is concern for the HDI at the bottom, which at Baucau Municipality shows "medium" as color #fc0 on white background, and the contrast does not appear to meet accessibility standards. Is that font color, #fc0, some kind of standard, I wonder? P.I. Ellsworth - ed. ^put'r there 13:31, 28 February 2022 (UTC)

 Not done for now: several different methods have been tried to no avail. Bahnfrend, we did see that {{TL wikidata}} uses Module:Wikidata, which has been deprecated in favor of Module:WikidataIB (IB for "infobox") and Module:Wd, so perhaps if the template were adapted to one of those, this problem would be resolved? That might be worth investigating, because whether or not the bold typeface appears seems to be tied to the Wikidata properties that are called by the TL wikidata template. I've worked a bit on Wikidata; however, I'm not very familiar with the PXXXX pages. Figure this out and then feel free to reopen this request if necessary. P.I. Ellsworth - ed. ^put'r there 07:19, 1 March 2022 (UTC)

Using |demographics1_as_of= should work, but it appears to me that the existing line that it would be split from has some braces in the wrong place. I second the call to use Module:WikidataIB, making sure to require sourcing for all values retrieved. – Jonesey95 (talk) 15:01, 1 March 2022 (UTC)

The guidance here at # subdivisions (Flag icons or flag templates can be used in this field per WP:MOSFLAG.) seems to contradict MOS:INFOBOXFLAG (Generally, flag icons should not be used in infoboxes) — GhostInTheMachine ^{talk to me} 11:45, 9 January 2022 (UTC)

See also an ongoing discussion at WT:MOS#MOS:DECOR and navboxes--Ymblanter (talk) 11:47, 9 January 2022 (UTC)

(edit conflict) The recent revert by DisillusionedBitterAndKnackered at Shrewsbury seems to imply an existing policy against the flags — GhostInTheMachine ^{talk to me} 11:53, 9 January 2022 (UTC)

Thanks but sorry, no, it implies nothing that well-organized – just a belief that I had seen it around, and a quick look at some other places to confirm (biasedly???) that it is not present in some others I randomly checked. Please see my edit summaries there, which are not, I hope, too much of a claim of Cosmic Rightness™. So if I am wrong I am happy to be educated about it, and I had perhaps better stay off these edits if there is an ongoing debate. My personal view is against their use, sure, but I am not going to pick up the cudgels over this and will wait to see what emerges. Best to all, DBaK (talk) 12:16, 9 January 2022 (UTC)

No worries. The above debate is directed to Navboxes, but I assume it would also apply to Infoboxes. I will await any conclusion and then try to clear up the conflict in this documentation — GhostInTheMachine ^{talk to me} 12:53, 9 January 2022 (UTC)

Thank you. I will watch and wait. And I have told the IP I'm backing off too, just in case. Cheers DBaK (talk) 13:33, 9 January 2022 (UTC)

As the originator of the ongoing discussion at WT:MOS, I'd say that it is dedicated to another kind of icons (NOT the inline flags produced by {{flag}} and similar) within another kind of templates (the navboxes). It is aimed to address the very particular issue, and it better stay specific to its original purpose. That said, I of course welcome you all to watch it and to comment there.

And as to the present discussion, I see it simply: there certainly is a contradiction between the doc and MOS:INFOBOXFLAG, and certainly the latter takes precedence, so the former should definitely be edited to comply. Thank you Ghost for pointing it out. — Mike Novikoff 18:12, 10 January 2022 (UTC)

You know, there is a saying: "If you want it done properly, do it yourself". So here's my edit. — Mike Novikoff 00:47, 16 February 2022 (UTC)

I have added a firmer comment to the documentation on each reference to subdivision_name (and 1-6). Please check! — GhostInTheMachine ^{talk to me} 18:20, 6 March 2022 (UTC)

I am seeing parts_type = Control ... added to the infobox for villages in Ukraine. Unsurprisingly, this often leads to a flurry of edits about who is control.
Do we have a view that adding a Control part is OK / {{Speculation}} / {{Disputed}} / WP:CURRENT WP:RECENT / WP:POV ?
Should we change the label Control to something else? Should such parts section "simply" be removed? — GhostInTheMachine ^{talk to me} 14:17, 6 March 2022 (UTC)

I cannot point to a guideline prohibiting it, but I think it's unwise to put rapidly-changing information into an infobox. — hike395 (talk) 15:56, 6 March 2022 (UTC)

I too can find no policy, but I agree that fast moving events are best left out of an infobox. However, considering the current situation, I really do want to point to a specific policy if I revert such additions — GhostInTheMachine ^{talk to me} 19:39, 7 March 2022 (UTC)

I revert on sight all instances which are unsourced.--Ymblanter (talk) 06:36, 7 March 2022 (UTC)

Hi. Trying to keep it brief:

1. Yes, I am a klutz at templates and how they work, sorry;
2. I have a simple objective, which is in the infobox of the article Northumberland to change the label for where Blyth is mentioned from Largest city to Largest town since the former is wrong and the latter correct: Blyth is not a city.
3. Just changing city to town in the parameter name doesn't work, obvs.
4. I can't see where it even getting Largest city from; it doesn't seem to be listed in {{Infobox English county}} and, bizarrely (to me) I can't even find here in the parent template either, but that might well just be me being thick. I've already unsuccessfully asked at the English County one, btw.
5. I vaguely understand that if I could find where these parameters live then I could edit the template (or, more realistically, ask for it to be edited) so that Largest town is available, but I Can't even Get Started on that when I can't even see where it is picking up Largest city from.
6. Help, please!
7. Note: people dealing with UK placenames already know why it cannot say that Blyth is a city: in the UK it is simply not one. For others, this is well explained at City status in the United Kingdom.

Finally, I am sorry if this is all a bit of an FAQ and/or sounds gormless but it's one of those wikipedia-classic moments where it is probably nice and obvious as long as you already know it ... I would really appreciate your help here. Thanks and best wishes to all, DBaK (talk) 14:09, 10 January 2022 (UTC)

I'm finding it difficult to cope with the flood of replies. Ermmm ... not sure what to try next. It remains wrong; I remain unable to fix it without assistance. Any help please? Thanks DBaK (talk) 15:57, 6 March 2022 (UTC)

A single reply has flooded in ... The infobox only has largest_city (there is no largest_town) and the label is thus fixed. This is not clear because the documentation is out of date. I have remove Blyth from the Northumberland infobox — GhostInTheMachine ^{talk to me} 18:38, 6 March 2022 (UTC)

Thanks so much, GhostInTheMachine, for the flooded reply. I really appreciate it. Thanks also for zapping Blyth out of the Northumberland infobox, where it was, of course, wrong or at least wrongish or labelistically wrong. I really hate to be nitpicky, but I was wondering if it is not possible to sort out the infobox to cope better with this situation? Please? Blyth, bless it, really is (it says here) the largest settlement in the county (who knew?), and if it is necessary to list this for counties where their largest settlement is a city then perhaps we should also be able to where it is a town, which in the UK is I guess (without doing a check) moderately likely.

I am thinking of other places in infoboxes where you can specify the label for a parameter ... as warned above I am rubbish at this but I am pretty sure I have seen it happen in, for example, schools, where I think either you can simply choose whether to say Principal or Headteacher, or maybe you get to specify which label to use for a parameter so in effect you are saying yes, this is a "principal" but in this case it is to be labelled "headteacher" or whatever and then it displays it correctly, vis-a-vis local usage, for Mr Tick or whomever. (Presumably Mr Checkmark in AmE ... meh, less funny.)

Is this possible, one way or the other? Should I make a formal request for it like these smart people have elsewhere on this Talk page? Or what? I don't want to be naggy and gripey (well I do a bit, but hey) but if it is not too painful to fix, it would be great, please, if we did – it would be marvellous if it worked in more localities and didn't look like a slightly sad WP:ENGVAR-ish issue. Please advise, thanks and best wishes DBaK (talk) 18:44, 7 March 2022 (UTC)

All things can be done ... The "cheapest" solution would be to add the missing largest_town parameter, so that either could be used. I assume somebody will then use both, but that would not be harmful or even wrong. The second way would be to change the Largest City label to be Largest settlement, but I am sure that would upset many people. The third option is, as you say above, to add a way to alter the label from Largest city to Largest hovel or whatever. That is potentially more troublesome, as somebody is bound to change the label to something truly undesirable. My vote is "just" for the first way. We can request the change across at {{Infobox English county}} and it should be fairly straightforward to do (although I suspect it may take ages for people to agree to do it), or I could just do it — GhostInTheMachine ^{talk to me} 19:15, 7 March 2022 (UTC)

Thank you very much GhostInTheMachine for explaining that. I follow your logic completely and I do see the pitfalls with options 2 and 3. Is it cheeky, then, for me to just say yes please, do Just Do It for Option 1, "The Cheapo"? There hasn't exactly been heated debate over this yet and I think the number of editors interested in or affected by the change might be quite low, but I do feel it would be very useful to some county articles. I'm sure that if anyone had a strong objection and a coherent argument against, we would hear it soon enough, yesno? (And if it all were to go horribly wrong I could visit you in gaol bringing the traditional cake-with-a-file-in-it ...) Thanks and best wishes DBaK (talk) 20:14, 8 March 2022 (UTC)

Sorted. The sandbox version now accepts both city and town. It displays the city if both should get set. See the test page. If that seems OK, I will copy the sandbox version to the live one in a couple of days — GhostInTheMachine ^{talk to me} 17:31, 18 March 2022 (UTC)

Y Live — GhostInTheMachine ^{talk to me} 17:23, 23 March 2022 (UTC)

V v kuhl, thanks! DBaK (talk) 19:11, 23 March 2022 (UTC)

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

I request that someone alter labels 73 and 91 so that they are both identical to labels 82, 84 and 89.

At the moment, all of these labels are for the rank of the article's subject in relation to a particular parameter (eg, for label 73, the relevant parameter is the area of the human settlement). Each label, when displayed in the infobox, is displayed directly under the ranked parameter, eg, label 73 is displayed directly underneath the "area" parameter.

For that reason, there is no need for any of these labels to say anything other than  • Rank, which is the present text for labels 82, 84 and 89. However, label 73 presently says "Area rank" and therefore omits the bullet and includes the superfluous word "Area", and label 91 displays " • Density rank", which includes the bullet but says "Density rank" when it should say simply "Rank".

If you want to see an example of how strange label 73 looks when it is displayed in its present form in combination with label 82, 84 and/or 89, you might want to look at Baucau Municipality, which displays both label 73 and label 89. The latter label is bulleted, does not include any superfluous word, and therefore fits in with the displayed labels surrounding it; the former label does not fit in. Bahnfrend (talk) 10:21, 28 February 2022 (UTC)

• Support - as long as it is sufficiently clear what the rank is referring to. Would it possible to indent it so that it appears subordinate to the area/density/total field? — Martin (MSGJ · talk) 12:42, 28 February 2022 (UTC)

Apologies, Martin, I didn't see your comment and question in time, so  done. I did indent the density rank more than had been suggested. See Baucau Municipality. P.I. Ellsworth - ed. ^put'r there 12:58, 28 February 2022 (UTC)

@Paine Ellsworth: sorry to be a nuisance, but since you made the alteration, three of the "rank" labels have been single indented, and the density "rank" label, uniquely, has been double indented. That makes the density "rank" label look strange and anomalous, not only when it is the only "rank" label displayed in the whole infobox, but also, and to an even greater extent, when one or more of the other "rank" labels is displayed (as in the present form of, eg, Baucau Municipality and Western Australia). To eliminate this anomaly, I request that the double intent of the density "rank" label be converted to a single indent - I do not believe that there is any advantage in double indenting any of the "rank" labels, as they are displayed only when the other label to which the "rank" label refers is displayed, and then only immediately under the other label that is so ranked, with the consequence that there can be no confusion as to which other label the "rank" label refers. Bahnfrend (talk) 08:35, 23 March 2022 (UTC)

Understand, however since the density rank is subordinate to the density, it was recommended above by Martin (MSGJ) to indent it more than other ranks so it actually appears to be subordinate to the density. It would be good if Martin could give an opinion on this before another edit is made. It's especially important because this ibox is used on well over half-a-million pages. P.I. Ellsworth - ed. ^put'r there 09:42, 23 March 2022 (UTC)

Perhaps it should also be considered that I double-indented the Density rank before I read that Martin had asked for it to be that way. So sorry, however it was and is my opinion that the rank should continue to be subordinate to the Density by retaining its present indented state. P.I. Ellsworth - ed. ^put'r there 11:43, 26 March 2022 (UTC)

The Elevation portion of this template does not convert metric measurements to English measurements correctly. For example, in the Ain el Safssaf infobox, which uses the Settlement template, it shows Lowest elevation 1,000 m (3,000 ft). The correct conversion, using the Convert template is 1,000 m (3,300 ft). Would someone familiar with the Settlement template's code, and able to edit it, please correct this. Thanks. Truthanado (talk) 15:22, 2 May 2022 (UTC)

This appears to be implemented by {{Infobox settlement/lengthdisp}}, not by the rounding system in {{convert}}. {{Convinfobox}} does the correct rounding, but does not obey the unit choice and order guideline, which {{Infobox settlement/lengthdisp}} does. I suspect we'll need to combine {{Convinfobox}} and {{Infobox settlement/lengthdisp}} somehow, perhaps by converting to Lua. It's a mess. — hike395 (talk) 00:51, 3 May 2022 (UTC)

Hello, I recently got in an argument [[3]] with someone over my edits to Port Jervis, New York, Newburgh, New York, Deerpark, New York, and Kingston, New York. In those edits (which are now reverted) I added the road signs for the major highways into the infoboxes. I was told by the user that this was not the purpose of the infobox. I did not question them and reverted the edits. Later, I was looking at random articles and stumbled across the page for Detroit and saw it had the same edit that I had made. I am now unsure if this is allowed and would like to know. I would love to re-add my edits back but, I would like to know if this type of edit can be used. — Preceding unsigned comment added by Monkeylol (talk • contribs) 15:18, 10 May 2022 (UTC)

I agree with Magnolia677: the infobox should be as condensed as possible, and adding rows of highway shields, transit icons, and airport names is wholly unnecessary. Major highways can easily be mentioned in the lead with better context (e.g. where they actually go), while transit and airport information belongs primarily in the body's Transportation section. Note that our FAs and GAs of U.S. cities generally don't have those icons in the infobox. Perhaps a formal RfC and cleanup is needed, since these have kept spreading for so long. SounderBruce 19:07, 10 May 2022 (UTC)

Why do this template have a "sizedefault=250px" for images? I suggest to remove it. Default image size is 220px (WP:IMGSIZE). Christian75 (talk) 06:42, 18 May 2022 (UTC)

Disagree. 250px looks good on most screens and harmonizes with maps and other images (COA, flag, logo). Besides, making it smaller will either create needless (and ugly) margins beside the image or wrap the text in the infobox (making it needlessly longer). -- P 1 9 9  ✉ 15:36, 18 May 2022 (UTC)

I raised this issue about Infobox building and was pointed to a bullet at the end of MOS:IMGSIZE. My correspondent at that talk page, Ɱ, has added this preference to multiple infoboxes, making pages display better on their screen but worse on mine; I didn't look to see if that editor applied the px sizing to this infobox, but the effect is the same. I try like hell to avoid MOS talk pages, so I didn't follow up to try to get the guideline changed, but someone reading this discussion may wish to do so. – Jonesey95 (talk) 20:33, 18 May 2022 (UTC)

Note that most of the info at WP:IMGSIZE applies to regular images within paragraphs, not to its use in infoboxes. There is however one applicable statement: "The lead image in an infobox should not impinge on the default size of the infobox." To me, that means that is best to have the image the same size as the infobox (which also looks best). -- P 1 9 9  ✉ 13:42, 19 May 2022 (UTC)

Thank you! That guidance reinforces that fixed px sizes are undesirable. That section refers to scaling, not to fixed pixel sizes. Using a fixed pixel size of 250px, as done in this template, violates that guidance for editors who choose thumb sizes of 120px, 150px, or 180px in their preferences. – Jonesey95 (talk) 14:18, 19 May 2022 (UTC)

LOL! My point is actually the opposite. The "guidance reinforces that fixed px sizes are undesirable" for images in prose/paragraphs. Again, the lead image in an infobox should not impinge (= have impact or encroach) on the default size of the infobox – hence it should be the same as the default size (which is 250px for this infobox). -- P 1 9 9  ✉ 18:21, 19 May 2022 (UTC)

This is why I stay away from MOS talk pages. Too many angels, not enough pins. – Jonesey95 (talk) 16:04, 20 May 2022 (UTC)

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

Per Wikipedia talk:Short description#Articles with long short description below 3000, merge the sandbox (diff). Qwerfjkltalk 15:18, 20 May 2022 (UTC)

I'm not sure this is needed. At the time of the request, there were only 14 articles in the "long short description" category that used Infobox settlement. I am fixing them by hand, finding parameter usage errors and long SDs in the SD template in each one. If I find a legitimate error, I'll be happy to implement this change. – Jonesey95 (talk) 16:13, 20 May 2022 (UTC)

This is not needed at this time, and could be counterproductive. There are zero articles in the category transcluding Infobox settlement. Having the articles in the category turned out to be a good way to find misused parameters, including |settlement_type= and the |subdivision...= parameters. – Jonesey95 (talk) 16:27, 20 May 2022 (UTC)

Just spotted that if the |image_skyline= is used with the {{Multiple image}} template the resultant display of the images is offset to the right rather than been centred. Anyone know why? As an example see Tees Valley. Keith D (talk) 11:17, 14 June 2022 (UTC)

@Keith D: The |align= parameter for {{Multiple image}} is "right" by default. Setting |align=center fixes the problem. Tees Valley is now fixed. — hike395 (talk) 15:18, 14 June 2022 (UTC)

@Hike395: Many thanks, I was looking at {{Infobox settlement}} for the parameter. Keith D (talk) 15:25, 14 June 2022 (UTC)

I've seen some discussions about how long the photo montages used in infoboxes are. The main reason for those discussions is the fact that some think that infoboxes with long photo montages become too long on mobile devices and that this makes the user have to scroll to reach the text of the article. However, this argument is not exactly valid as infoboxes are too long anyway, with or with no images regardless of how long the photo montage is. So, to solve these problems and avoid different consensus on using images or montages in each article, I suggest a way to standardize how settlement infoboxes are displayed on mobile devices. I propose that infoboxes can be collapsed or expanded on mobile devices (we'll only have to decide the standard behaviour), so the user can decide if they want to scroll and if the infobox information is relevant to them. I believe this can be easily done with CSS. 200.242.43.202 (talk) 14:38, 23 June 2022 (UTC)

Should something like

be done, per this VPT thread, to stop incorrect categories being applied? ― Qwerfjkltalk 20:47, 26 June 2022 (UTC)

Courtesy ping @Bearcat. ― Qwerfjkltalk 20:55, 26 June 2022 (UTC)

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

I've proposed adding additional parameters to the dimensions section, namely {{{coastline_km}}} and {{{coastline_mi}}}. Useful metric for coastal settlements. –Aidan721 (talk) 23:29, 27 June 2022 (UTC)

Let's get consensus for this. Can you point to half a dozen articles where there is reliably sourced information about the length of the coastline? Measuring coastline lengths is a notoriously tricky enterprise. – Jonesey95 (talk) 00:55, 28 June 2022 (UTC)

I don't think this is needed for this template, likely very few uses for it. It is more suitable for {{infobox islands}}, which already has it. If a settlement is coterminous with an island, you can either add coastline info in a geography section or add a separate Islands Infobox (see for example Cebu). -- P 1 9 9  ✉ 02:03, 28 June 2022 (UTC)

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

Could you add parameter for native official name? Description for regular native name parameter says it "will display under the name/official name." but it only displays under regular name. Piotr Bart (talk) 13:57, 20 July 2022 (UTC)

 Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. Don't understand, because the "native name" displays in the "above" section along with the common name, and gives the official native name(s) for the location. So please explain more fully what you think is needed (in "change X to Y" format). P.I. Ellsworth , ed. ^put'r there 16:27, 20 July 2022 (UTC)

Hi, I've just stumbled across this parameter in Huntington, West Virginia. It's obviously been superseded/replaced, so what is it's current parameter? Thank you X-750 _{Rust In Peace... Polaris} 11:20, 26 July 2022 (UTC)

That parameter has been discontinued and removed from the template (see Template talk:Infobox settlement/Archive 30#Purpose of area_magnitude= parameter?). You can just remove it from the articles that still have it. Thanks. -- P 1 9 9  ✉ 14:49, 26 July 2022 (UTC)

Please add this parameter as it is often needed. – Ilovemydoodle (talk) 00:46, 4 August 2022 (UTC)

"Coquitlam, British Columbia" is listed as an example for shield_link but it doesn't apply anymore, can that be removed please

i can't really suggest a different article in its place though

Sbznpoe (talk) 22:13, 12 August 2022 (UTC)

Please add leader_party1, leader_party2, leader_party3, etc. as it is often needed. – Ilovemydoodle (talk) 09:48, 17 August 2022 (UTC)

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

Automatically Determining Emblem Type Is it possible to add a feature that displays the correct emblem type based on the country where the settlement is, e.g. Seal in the United States, Coat of Arms in Europe, Emblem in Japan, etc? The country may be from the parameter or from Wikidata. Xeror (talk) 02:55, 26 September 2022 (UTC)

It's not always so simple - eg Great Seal of France vs National emblem of France. Nikkimaria (talk) 03:24, 26 September 2022 (UTC)

What about option to override for special cases? Xeror (talk) 19:42, 27 September 2022 (UTC)

Given the number of special cases and the amount of wrangling to set up rules, is it not simpler to just set manually? Nikkimaria (talk) 22:22, 27 September 2022 (UTC)

Given that there are hundreds or thousands of cities to be edited, there are a lot of manual labor in setting the type. This is particular the case for Japanese municipalities since there is no dedicated one for emblems. The default type for the blank emblem is actually "logo". An alternative is to set it automatic for countries without or with only a few special cases and opt out the default for countries with many special cases. I am not familiar with how many special cases in each country but for countries like the U.S, or Japan, there are only handful of cases if any. Xeror (talk) 03:21, 28 September 2022 (UTC)

I'm not sure that's the case. For example there is both Seal of New York (state) and Coat of arms of New York, Seal of Alabama and Coat of arms of Alabama, Seal of Connecticut and Coat of arms of Connecticut, ditto North Dakota and Pennsylvania and Rhode Island... I don't know how many exactly there are either, but it seems to be more than a handful. Nikkimaria (talk) 03:26, 28 September 2022 (UTC)

All the examples you gave were actually not special cases in this situation, since they all have seals that would be the default one for the United States. The second insignia can be other types, which may or may not have another default, depending on how beneficial it would be. The special cases are those with only coat of arms but no seal in the United States, for instance.

An alternative way to do it is to have one parameter that has a default but the other ones do not.

A third option would be splitting the current blank_emblem into emblem, logo and wordmark. And there is no default. Xeror (talk) 00:15, 29 September 2022 (UTC)

They would not be special cases iff the first insignia added was the seal; we don't have a way of ensuring that's the case. Splitting probably makes more sense, although more options would be needed. Nikkimaria (talk) 02:19, 29 September 2022 (UTC)

Nothing can be ensured 100% of the time. Even the template in the current state can be misused. If the template is well documented, the chance of such misuse can be greatly reduced.

Ideally the type can be automatically deduced from the file names. However, not all the files are named correctly, even though I have been trying to correct them.

Another future possibility would be to rely on Wikidata. However, the current way it is set up does not cover all the types. Xeror (talk) 03:49, 29 September 2022 (UTC)

 Not done for now: please establish a consensus for this alteration before using the {{edit template-protected}} template. – Jonesey95 (talk) 16:34, 26 September 2022 (UTC)