Template talk:Infobox settlement

Edit request 4 May 2026

Description of suggested change: Add |motto_translation= as in Template:Infobox school to hold motto translations, to prevent the use of <br/> for inaccessible lists (see MOS:NOBR). The Diff is taken from A Coruña.

Diff:

−

| motto = {{lang|gl|A Coruña, a cidade onde ninguén é forasteiro}} <br />(A Coruña, the city where nobody is an outsider){{force singular}}

+

| motto = {{lang|gl|A Coruña, a cidade onde ninguén é forasteiro}}| motto_translation = A Coruña, the city where nobody is an outsider

Snowman304|talk 00:28, 4 May 2026 (UTC)

 Not done for now: please establish a consensus for this alteration before posting an edit request. Zackmann (^{Talk to me}/_{What I been doing}) 02:15, 4 May 2026 (UTC)

Oppose - Makes since for a school where mottos are usually in Latin. This is not the case with settlements. Zackmann (^{Talk to me}/_{What I been doing}) 02:17, 4 May 2026 (UTC)

I think this is perfectly reasonable to be honest. Given the massive amount of settlements / cities which aren't in English-speaking countries, or even English-speaking settlements which use mottos in Latin or another language, I don't see the harm in having a separate parameter for the translation when one is needed. It allows us to ensure consistent formatting and cleans it up overall. Turnagra (talk) 03:59, 24 May 2026 (UTC)

RFC: Should we deprecate and remove the use of custom parameters

Should we deprecate and remove the use of some or all custom parameters in Infobox settlement? Zackmann (^{Talk to me}/_{What I been doing}) 06:05, 21 May 2026 (UTC)

Background

I have recently noticed that the custom parameters in this Infobox are rife with misuse. There are tens of thousands of uses where the data provided does not conform to MOS:INFOBOXPURPOSE and I think the time has come to take a good look at these parameters and discuss whether they are still helpful to have. This infobox (which I believe is the most used one on the English Wikipedia), is huge and many pages that use it are suffering from overload of too much data.

I will quote 2 lines from MOS:INFOBOXPURPOSE:

• The purpose of an infobox is to summarize, but not supplant, the key facts that appear in an article.
• The less information that an infobox contains, the more effectively it serves its purpose, allowing readers to identify key facts at a glance.

The plethora of values that we currently allow in the infobox (there are over 450 parameters accepted by this template before you even factor in the numerous mapframe parameters) allows for way too much information to be crammed into this Infobox directly violating MOS:INFOBOXPURPOSE.

Examples

Here are a few of the thousands of examples I have come across (I am permalinking these in case things change during the RFC):

• Srinagar where the |blank1_info_sec2= series of params are used to describe the average climate of the City (including winter/summer temps and average rainfall). This despite the presence of {{Weather box}} in the article.
• Aizumi, Tokushima where |blank_name_sec1= is used to give the street address of city hall.
• Argay, Portland, Oregon where the |demographics1_info1= series of params are used to give miscellaneous stats about how many people rent vs own a home in the neighborhood.
• Noveleta where such values as the major energy provider, climate, major religions and feast day are provided.
• Arita, Saga where a phone number and address (of what??) are provided.

The proposal

What I am proposing is deprecating and working towards removing all of these blank parameters that allow for ANY label/data combination to be supplied at the individual transclusion level. This would obviously be a slow process, but I think it is at least worth exploring.

If there are commonly used labels that we do not want to loose, those labels should be added to the template with their own parameter. For example, I know that a lot of settlement infoboxes have the GDP listed in one of these custom fields. IF consensus is that GDP conforms to MOS:INFOBOXPURPOSE then this template should have a |gdp= so that it can be set.

• another example is HDI

Again the end goal I am trying to achieve is to eliminate the ability to blanket set any label you want in the infobox and instead limit it only to those that conform to existing policy and MOS.

For reference this table shows the stats of the relevant parameters as of May 1, 2026.

Discussion

1. Should any of these parameters be slowly removed?
2. Should any new parameters be added in their place (such as |gdp= for GDP or |hdi= for Human Development Index)?

Please discuss below. -- Zackmann (^{Talk to me}/_{What I been doing}) 19:37, 20 May 2026 (UTC)

• Support removal of blank parameters. The infobox is much too large and these fields are abused to add information which should not be in the infobox.
• Oppose the addition of any additional fields, including GDP and HDI. These fields rapidly go out of date, sub-national GDP is usually only available in the local currency thus making comparison impossible, and there is no standardised manner of calculating sub-national GDP, again making the figures useless for comparison. Likewise, HDI is calculated in an ad-hoc way at a sub-national level. Dgp4004 (talk) 19:57, 20 May 2026 (UTC)
• @Zackmann08: what is your brief and neutral statement? At almost 8,000 bytes, the statement above (from the {{rfc}} tag to the next timestamp) is far too long for Legobot (talk · contribs) to handle, and so it is not being shown correctly at Wikipedia:Requests for comment/Wikipedia technical issues and templates. It also contains a table, which is forbidden by WP:RFCST. --Redrose64 🌹 (talk) 21:34, 20 May 2026 (UTC)

  @Redrose64: my apologies. Was trying to gain attention for the discussion as I want to ensure a broad discussion but neglected to thoroughly read the RFC guidelines. I have removed the RFC tags and will simply make this a regular discussion. --Zackmann (^{Talk to me}/_{What I been doing}) 22:05, 20 May 2026 (UTC)

• Comment: Note that in thousands of articles on US settlements the |blank_name=, |blank_info=, |blank_name1=, and |blank_info1= fields are used to supply the FIPS codes and GNIS IDs of the places. (See Winfield, Missouri for a random example.) This seems useful information, so I would oppose just removing the parameters. If a bot could replace these with |fips= and |gnis= parameters, it might be OK, but in globally used infoboxes I generally don't like parameters that apply only to particular countries or areas. Deor (talk) 21:57, 20 May 2026 (UTC)

  @Deor: 100% valid point there... My question would be, are the FIPS and GNIS IDs for a place worthy of including in the Infobox? Not saying they cannot be mentioned in an article, but are such (IMHO) obscure data points inline with MOS:INFOBOXPURPOSE? I don't see what possible use knowing these values are except to clutter an Infobox? Zackmann (^{Talk to me}/_{What I been doing}) 22:09, 20 May 2026 (UTC)

  I guess it depends on what information folks think an infobox should contain. I'm not sure that the postal codes and telephone area codes of places are really necessary, but they are usually included, in dedicated parameters, in the infoboxes (and only there). I agree that your examples above are problematic and that most of the information you point out should already be in the article prose or should be moved there, but I'm not sure that such abuse is extensive enough to warrant the removal of all the "blank" parameters. (And, frankly, I think the FIPS and GNIS codes, like geographic coordinates, are more appropriate in infoboxes than they would be in article text—things that should given somewhere in an article but are hard to work into the prose.) Deor (talk) 22:42, 20 May 2026 (UTC)

  There are already four fields made available for various codes:

  • code1_name
  • code1_info
  • code2_name
  • code2_info
  • geocode
  • iso_code

  If anybody ever finds themselves using blank fields for codes then they're including too many codes. Dgp4004 (talk) 00:00, 21 May 2026 (UTC)

  That is an excellent point. @Deor: could that be a good compromise here? Keep the fips and gnis by using the code params above? Zackmann (^{Talk to me}/_{What I been doing}) 00:01, 21 May 2026 (UTC)

  Well, the changes you made in Winfield, Missouri to use the "code" parameters certainly work; but if it's decided that such changes are to be made globally, can a bot be programmed (and approved) to accurately identify such cases and change the "blank" parameters to "code" parameters? The documentation for this infobox would also need to be changed to clearly indicate the sorts of info the "code" parameters are to be used for. (Both examples in the "Examples" section use "blank" parameters for FIPS and GNIS.) And what about any other ways the "blank" parameters may be being used throughout WP—for legitimate purposes, rather than for the odd purposes in your examples above? Deor (talk) 11:07, 21 May 2026 (UTC)

  GNIS and FIPS codes seem like completely unencyclopaedic information that will never exist in the body. They can go at the bottom of the article in the authority control section like other codes/links to external databases/resources if they are useful in that sense. Traumnovelle (talk) 23:05, 21 May 2026 (UTC)

• I don't know whether the deprecation of custom parameters to address misuse of them is the best solution. I agree all the examples go against the infobox purpose and that settlement infoboxes often have unnecessary information that bloats the infobox, but I think editing articles so that the infoboxes only cover important information may be a better solution here. Traumnovelle (talk) 23:28, 21 May 2026 (UTC)

  @Traumnovelle: I guess my question is would eliminating these custom parameters help achieve the goal that you identified: editing articles so that the infoboxes only cover important information? Zackmann (^{Talk to me}/_{What I been doing}) 23:39, 21 May 2026 (UTC)

  It'd address that but would it also not remove legitimate uses of the parameter? Like if the issue is the misuse of custom parameters, but we still have some custom parameters left would the same not just occur with those ones? Traumnovelle (talk) 01:57, 22 May 2026 (UTC)

  In the end my suggestion is to ultimately remove ALL custom parameters. But at the the very least we can start by cutting down on the misuse.... Zackmann (^{Talk to me}/_{What I been doing}) 02:54, 22 May 2026 (UTC)

  Oh I see. I'd like to hear if anyone can provide a convincing argument as to why custom parameters should be kept before I agree to removal but I am leaning towards removal of it currently. Traumnovelle (talk) 03:37, 22 May 2026 (UTC)

  Given you would be editing the pages to remove the parameter if it was removed from the template would it not just be as equally feasible to review the parameters as they are used currently and remove inappropriate usages? Traumnovelle (talk) 03:39, 29 May 2026 (UTC)

  @Traumnovelle: the difference is that a bot can automatically run and removal all uses with very little manual input required. Reviewing the parameters would require manually checking over a half million pages which is simply not possible. Zackmann (^{Talk to me}/_{What I been doing}) 04:36, 29 May 2026 (UTC)

  Is it not possible to run some sort of script to show which pages use it, or is it used by over half a million pages? Traumnovelle (talk) 04:38, 29 May 2026 (UTC)

  What you are looking for is the Parameter Report that comes out the first week of every month: Here is the one for Infobox Settlement. You can drill down into that and see what is being used. It also has the summarized counts of each parameter showing that you would have to manually check at least 106,000 pages (assuming 100% overlap of parameters). Bottom line, there is no practical way to scan for all possible misuses, particularly when they will just keep coming back. A perpetual game of whack a mole...

  Again this is why I am proposing that if there are proper uses of these (for example GDP) then we should create a parameter |gdp= instead of allowing for the blank parameters. That way we would only allow the agreed upon valid uses and not have open season for anything and everything. Zackmann (^{Talk to me}/_{What I been doing}) 04:45, 29 May 2026 (UTC)

  What about when it's a proper use, but it's localised? For example, most New Zealand towns will use the blank parameter to include the local Iwi (eg. the articles for Christchurch or Rotorua)), but obviously that only applies to New Zealand settlements. You could maybe do a local indigenous parameter with a separate tag for the label (eg. specifying "iwi") but otherwise you're not going to get much use. Turnagra (talk) 05:11, 29 May 2026 (UTC)

  My stance on this is very simple and that is that that the examples you provided are not proper use. The Infobox is meant to be a quick glance summary of important information that should be comparable from one page to the next that is using the same infobox. So whether I am looking at New York City, Moscow, New Dehli or Christchurch, the information displayed should be same in terms of the labels (population, area, time zone, government leaders, etc.). Obviously the values are different for each but listing the Iwi for just places in New Zealand would, to me, violate MOS:INFOBOXPURPOSE. The Infobox on Christchurch (for example) is MASSIVE and has much to much information in it. Zackmann (^{Talk to me}/_{What I been doing}) 05:22, 29 May 2026 (UTC)

  So yeah I think that's a fundamental difference of opinion that I don't think can be reconciled easily. I agree that the infobox of Christchurch is too big, but I don't think the iwi line (which is absolutely key information in an NZ context) is the issue. I think it's other areas which have their own tags already (eg. local government wards and communities, postcodes) and blaming it on the blank tag is borderline misleading. I completely disagree that the information should be the same in every single settlement infobox, as different things will be relevant in different areas (see my example further down on temperature), and we shouldn't be trying to force standardisation just for the sake of standardisation. Turnagra (talk) 05:37, 29 May 2026 (UTC)

  But couldn't that be resolved at a lower level, by creating a sub-template or something like that? It'd be a lot of otherwise unnecessary work, but... if it's something that many NZ articles use... JordyGrey _talk🧸 12:11, 13 June 2026 (UTC)

• Support removal of blanks and oppose additions, per Dgp. Nikkimaria (talk) 02:56, 22 May 2026 (UTC)
• Oppose removal of blank_name, blank1_name, blank_info, blank1_info because 10s of thousands of articles use them for FIPS & GNIS. Support thinning down of never used fields and maybe rarely used fields. • Sbmeirow • Talk • 06:56, 22 May 2026 (UTC)

  Please see my earlier comment. There are specific fields available for codes, including:

  • code1_name
  • code1_info
  • code2_name
  • code2_info
  • geocode
  • iso_code

  A bot can be programmed to move these over.

  Dgp4004 (talk) 07:17, 22 May 2026 (UTC)

• Comment - a bot should be used to scan all articles that have the "Infobox settlement" template, then count the number of times each field is used and has data on the right side of the equals sign. Such results could be used to make better decisions, instead of making bumbling guesses of which fields to delete!! • Sbmeirow • Talk • 06:56, 22 May 2026 (UTC)

  @Sbmeirow: I would encourage you to read the entire RFC as this data you requested already exists... here thanks to the Template param report that runs every month... Zackmann (^{Talk to me}/_{What I been doing}) 16:48, 22 May 2026 (UTC)

• Alternative: The issue for me isn't that the parameters are custom and thus possibly gratuitous, it's that gratuitous facts shouldn't be included. But the determination of what is gratuitous, trivial or inapplicable may require discussion and consensus. I would favour a process of triage where commonly used custom tags are expected to be discussed collectively, with several possible outcomes, such as: keep custom parameter/convert to named parameter/delete without replacement/delete with consensus to deprecate. The fact that custom parameters exist means that someone who uses them is effectively proposing a topic for discussion in that manner, while still having the freedom to try it and see how it works out. The negative consequences of these edits are quite low, and I think it is better that they be allowed to at least initially, exist boldly, instead of being preemptively prohibited. (The net result is that there probably would be a slow removal trend, and there would probably be some new parameter replacement.) TheFeds 20:48, 23 May 2026 (UTC)
• Support removal and think a wider discussion should take place about removing more contentious parameters Wikipedia:Infobox too large. We also have to make sure that list defining junk like | near doesn't ends up being used more widely. Moxy🍁 02:36, 24 May 2026 (UTC)

  As this is the mostly widely used Infobox on en.wiki by transclusion count, my hope is that this may serve as a watershed moment/precedent for trimming down these unneeded parameters that have no business being in the infobox. Particularly when templates like {{Adjacent communities}} & {{weather box}} exist to put some of this very information in the body of the article! Zackmann (^{Talk to me}/_{What I been doing}) 02:41, 24 May 2026 (UTC)

  Agree ...parameters like " maxtemp " and " rainfall " simply add non-contextual data.... Ethnicity and religion always contentious. Moxy🍁 02:53, 24 May 2026 (UTC)

  As mentioned below, it somewhat feels like you're trying to have it both ways here. I don't understand how you can say on one hand that infoboxes should summarize, but not supplant, the key facts that appear in an article, and then on the other say that it shouldn't be in the infobox because it's in the body. To be clear, I'm not categorically saying that those specific examples should be in the infobox per se (I haven't had a chance to consider them properly yet), but rather that we shouldn't be jumping to remove something from the infobox just because it's already in the body. Turnagra (talk) 03:55, 24 May 2026 (UTC)

  Turnagra Thanks for the question. I think this comes down to the term Key Facts. Let me expand on this by focusing on the weather parameters. I guess my perspective is that if the weather data is covered in detail in the body of the article (as with Srinagar's use of {{weather box}}) why does any of this data belong in the Infobox? And where do we draw the line? In that example, we have Avg. summer temperature and Avg. winter temperature along with a nondescript Precipitation. I see a number of issues here....

  1. With the precipitation value, is this the record? The average? The total for last year? What is last year? How current is this?
  2. If we are displaying these values, why not display the Record high or the Avg high summer temperature?
  3. The data in the Infobox is totally unsourced (unlike that in the {{weatherbox}}) and is actually wrong assuming we take the sourced data in the weather box as correct

  When we have these blank parameters in the Infobox, it opens the floodgates for inserting any value into the Infobox. This brings me back to point #2 of my question that started this whole thing. IF the Avg. summer temperature is deemed by consensus to belong in the Infobox, then shouldn't we create a |avg_summer_temp= so that we have a dedicated param for that and we don't get people using a blank param to put in the phone number of city hall or the major energy provider?

  You said I don't understand how you can say on one hand that infoboxes should summarize, but not supplant, the key facts that appear in an article, and then on the other say that it shouldn't be in the infobox because it's in the body (bold added to show text you quoted). I guess to summarize my response to this totally valid question is that I just have a different interpretation of the term key facts.

  For a settlement the population, location, elevation, etc. are key facts. Something as complex as the weather of a location cannot (IMHO) be summarized in a way that can be considered a key fact. Zackmann (^{Talk to me}/_{What I been doing}) 04:16, 24 May 2026 (UTC)

  Cheers for the elaboration. I think there's a few things here, but overall it comes back to my main point below - we shouldn't be removing these parameters without a clearer picture of exactly how they're being used. The bulk of your reply talks specifically to the weather point, which I think speaks to how different places won't necessarily have the same key facts. I think there are absolutely cases where something like temperature for example could be notable - take Coober Pedy, where people literally live underground because of the heat, or Yakutsk, where the high is less than -20 degrees celsius in winter. Both of these places mention the temperature in the lede, and there would be a solid case to have it in the infobox as a key fact about the place, compared to somewhere like London or Miami. But that's just one example, and setting that aside to talk to some of your more general points:

  • The data in the Infobox is totally unsourced - that's a frequent issue in infoboxes, and isn't unique to the tags in question. I think it's a bit of a red herring here and is perhaps a separate issue. I'd almost be keen to see infoboxes take a view similar to the lede, where citations aren't necessary in the infobox so long as the same content is cited in the body of the article (which would help ensure the infobox matches the body)
  • When we have these blank parameters in the Infobox, it opens the floodgates for inserting any value into the Infobox - I don't think this is a slippery slope, and I think it's something that could be addressed with guidance around when that tag should be used. Specify that they should only be used where there is key information about the settlement that can be displayed through the infobox or whatever so that it's clearer for people.
  • IF the Avg. summer temperature is deemed by consensus to belong in the Infobox, then shouldn't we create a |avg_summer_temp= so that we have a dedicated param for that - This is exactly why I'm saying we need to know more about how the tag is being used before we remove it. If half of all usage is to display the same sort of data, then maybe we should consider adding that as its own tag and swapping the existing forms over to that?

  If we know more about how the tags are being used, I think that will allow us to have a much more informed discussion about whether they should stay and whether there are grounds to keep anything. But having said that, my gut is that the variation between what would be a key fact for places means a degree of flexibility will always be useful. Turnagra (talk) 10:20, 24 May 2026 (UTC)

• Oppose: Despite this being reasonably targeted in terms of the actual request, the scope of usage makes it feel like a WP:TRAINWRECK situation to me. I don't think we can categorically say these parameters should be removed without a clearer understanding of exactly how it's being used across the board, and whether the use cases suggest that other core parameters should be added, whether there's need for blank parameters still, or whether misuse is the default. There are certainly some examples of misuse (like the phone number you cited), but there will undoubtedly be cases where its use is valuable. (As an aside, I'm not sure that I agree with citing Srinagar as an example of misuse, given including that content alongside weatherbox seems to fully align with MOS:INFOBOXPURPOSE as you cited it - but that's not a huge deal in the discussion at hand). Turnagra (talk) 03:51, 24 May 2026 (UTC)
• Oppose - I can sympathise with the reasoning behind this proposal but, regardless, I don't think this is the way to go. If there's a strange custom parameter, shouldn't the solution be to remove it rather than to forbid custom parameters entirely? Isn't the whole point of wikis to make bad edits easy to correct, rather than hard to make? The world is just too diverse to broadly declare that no individual settlements would ever benefit from unique parameters. I understand that there is a lot of misuse, but I think the only justification for removal is if the overwhelming number of deployments are cases of such misuse. Otherwise, we're just needlessly preventing the improvement of articles for the sake of vandalism prevention. Loytra^✨ 03:33, 29 May 2026 (UTC)
• Oppose, per @Loytra and @Turnagra. While cutting down bloat is a noble goal, using Odin's axe to do so without consideration of what is being axed is not a good way to do it. Plus, due to the nature of the parameter itself, it means that these were added manually by humans (rather than bots mass-importing data from wikidata or something). Good-faith edits by humans shouldn't be mass-deleted by bots. Further, reasonable minds will disagree on what is "important" and what isn't, and I too strongly disagree that the exact same types of info will be relevant in all corners of the earth. ~2026-32109-96 (talk) 21:19, 29 May 2026 (UTC)
• Support, due to the examples provided by Zackmann and on the basis that these are bloating the infoboxes. However, i would want a human to look over the use of the parameters to identify any potential widespread uses. JordyGrey _talk🧸 12:28, 13 June 2026 (UTC)

  I've never done this before and I think my response might be indented incorrectly? Sorry about that. JordyGrey _talk🧸 12:30, 13 June 2026 (UTC)

Deprecated parameter cleanup

I am proposing a cleanup of the conflicting parameters of this Infobox. To be clear, this will not change the display on any transclusions. What I am suggesting is reducing technical debt and reducing errors caused by conflicting parameters. The replacements I am proposing are the folliowing:

Deprecate/Remove	Replace with
|blank_name=	|blank_name_sec1=
|blank_info=	|blank_info_sec1=
|blank1_name=	|blank1_name_sec1=
|blank1_info=	|blank1_info_sec1=
....	....
|blank7_name=	|blank7_name_sec1=
|blank7_info=	|blank7_info_sec1=
|type=	|settlement_type=
|imagesize=	|image_size=
|alt=	|image_alt=
|caption=	|image_caption=

I am also proposing changing the code so that BOTH sets of the parameters below work. There is no need to have them conflict as they currently do. We can easily add another row.

Currently conflict
|utc_offset1=	|utc_offset=
|timezone1=	|timezone=
|utc_offset1_DST=	|utc_offset_DST=
|timezone1_DST=	|timezone_DST=

Finally, I am wondering if we should take this opportunity to deprecate and change |image_skyline= to just |image=? This will required over a half million edits by a bot, but might be worth doing as the use of |image_skyline= does not always fit.

For those familiar with my cleanups of other Infoboxes, this is NOT one that will be proceeding until a very clear WP:CONSENSUS is reached as I realize this will affect over a half million pages. Please chime in on any thoughts below. Zackmann (^{Talk to me}/_{What I been doing}) 21:16, 10 June 2026 (UTC)

Support. These seem very sensible measures to me. Dgp4004 (talk) 00:19, 11 June 2026 (UTC)

Unless I misunderstand, it appears that there are currently two separate parameters called |blank_name_sec1= and |blank1_name_sec1=, where the first parameter is essentially "|blank0_name_sec1=". If true, making a change is an opportunity to fix this unintuitive programming scheme. I probably misunderstand. Also, the word "name" in these parameters should probably be "label" to match the terminology used in infoboxes. Am I totally off-base here? – Jonesey95 (talk) 14:35, 11 June 2026 (UTC)

@Jonesey95: 100% agree to your second point that name should be changed to label and I will update that pending the outcome of this tangent. As for the first point, this is all over the map... I think we should probably follow the convention laid out by subdivision_name, subdivision_name1, etc where we start with an implied "0", then go to 1, 2, etc. We gotta come up with a better naming convention though. I've spent the last 5 minutes trying to write this post and cannot, for the life of me, come up with better parameter names. I agree that we should drop name in favor of label AND drop info in favor of data, but how to name the parameters to make clear there are still 2 sections here? I'm at a loss... Looking at lines 916-978 of the code. --Zackmann (^{Talk to me}/_{What I been doing}) 15:52, 11 June 2026 (UTC)

So setting lets ignore (for a moment) the |blank#_name= and |blank#_info= params. We know we are getting rid of those... The question is what to make the new param names. A few ideas:

Current pattern (where # is nil-7)	Option A	Option B
|blank#_name_sec1=	|blank#_label_sec1=	|blank#_label1=
|blank#_name_sec2=	|blank#_label_sec2=	|blank#_label2=
|blank#_info_sec1=	|blank#_data_sec1=	|blank#_data1=
|blank#_info_sec2=	|blank#_data_sec2=	|blank#_data2=

Either of these look appealing? --Zackmann (^{Talk to me}/_{What I been doing}) 18:24, 11 June 2026 (UTC)

@Jonesey95: do either of the above options look appealing? Zackmann (^{Talk to me}/_{What I been doing}) 20:40, 16 June 2026 (UTC)

Appealing is not the word I would use. At this point, I would first try to describe in real words what these parameter names are supposed to represent, and build parameter names from there. The fact that there are two numbers in each parameter name is not something that normal humans should be expected to understand. Equally confusing is the use of the string "blank" in both the parameter names and the documentation headers for those parameter names. Things that are "blank" are usually empty, void, not present, but these things appear to cause words to display. It makes no sense to me. – Jonesey95 (talk) 00:41, 17 June 2026 (UTC)

@Jonesey95: Well I've got no comeback to that because I really can't argue with any of what you've just said. The other patterns I've seen on other Infoboxes are |free_label1=/|free_data2= and |custom_label1=/|custom_data1=. We could try one of those? What makes the implementation in this Infobox unique is the way they are split into two sections so how to do that without having 2 numbers? For the record, per the above RFC, I'm still in favor of completely removing these parameters, but absent WP:CONSENSUS for that, we definitely have to improve them. Zackmann (^{Talk to me}/_{What I been doing}) 00:54, 17 June 2026 (UTC)

Am I right in understanding that this is because the blanks have been set up to have potentially two separate sections? If so, this may not be an appealing option given your desire to cut down the number of parameters, but what about a separate thing along the lines of |blank#_section=, that would default to section 1 but could be set to section 2 if desired? This way, rather than having two instances of |blank1_label= (as in, |blank1_label_sec1= and |blank1_label_sec2=), you'd have |blank1_label= default to section 1 and then just have |blank2_label= with an additional |blank2_section= set to 2. Turnagra (talk) 06:36, 17 June 2026 (UTC)

You can check and see what the actual usage these parameters have (via or someway else), and maybe there is a missing parameter that should be added. Other than that, I think the word "custom" better identifies something that is changeable, rather than "blank". Gonnym (talk) 08:08, 17 June 2026 (UTC)

I agree that "custom" appears to fit the purpose much better than "blank". If that's the only change that is made, it's probably an improvement. – Jonesey95 (talk) 14:15, 17 June 2026 (UTC)

@Jonesey95 and Gonnym: Ok how about giving this a try?

Current pattern (where # is nil-7)	New Pattern	Example
|blank#_name_sec1=	|custom_label#_sec1=	|custom_label_sec1=, |custom_label1_sec1=, |custom_label2_sec1=, |custom_label3_sec1=...
|blank#_name_sec2=	|custom_label#_sec2=	|custom_label_sec2=, |custom_label1_sec2=, |custom_label2_sec2=, |custom_label3_sec2=...
|blank#_info_sec1=	|custom_data#_sec1=	|custom_data_sec1=, |custom_data1_sec1=, |custom_data2_sec1=, |custom_data3_sec1=...
|blank#_info_sec2=	|custom_data#_sec2=	|custom_data_sec2=, |custom_data1_sec2=, |custom_data2_sec2=, |custom_data3_sec2=...

This gets rid of the use of blank, uses label/data instead of the odd name/info and still makes clear which one goes in section 1 and which is for section 2. --Zackmann (^{Talk to me}/_{What I been doing}) 21:30, 17 June 2026 (UTC)

Support Something to consider is that there are quite a few templates that use this template as its base. Because of this, there may be dozens of child templates that need changes and associated bot runs. As always, happy to offer PhuzBot wherever necessary.

As for the actual changes to the parameters themselves, I don't have a strong position on exactly what to name the parameters right now. phuzion (talk) 20:02, 11 June 2026 (UTC)

@Zackmann08 remind me, aren't the blank fields used for mapping params in wrapper templates? What will be the net effect of the change on those. Regs, The Equalizer (talk) 11:56, 14 June 2026 (UTC)

@The Equalizer: to be clear, we are not loosing any of the blank fields. Just renaming them so that they follow a more logical pattern and don't conflict. Any wrapper templates using the current pattern will be addressed as well to use whatever the new decided on pattern is. TLDR no loss of information on any pages, including those using wrapper templates. Zackmann (^{Talk to me}/_{What I been doing}) 16:10, 14 June 2026 (UTC)

Timezones

Might be worth looking at the time zone parameters... There are 30 of them and I don't entirely understand how they all work (note there isn't much documentation for them).

Timezone parameters

Params	Notes
|timezone_link=
|timezone=-|timezone5=
|timezone_DST=-|timezone5_DST=
|timezone1_location=-|timezone5_location=	NO |timezone_location= exists
|utc_offset=-|utc_offset5=
|utc_offset_DST=-|utc_offset5_DST=

This area could also use some refactoring... --Zackmann (^{Talk to me}/_{What I been doing}) 05:02, 18 June 2026 (UTC)

These seem to be for very large places that span multiple timezones. See Far Eastern Federal District. Gonnym (talk) 06:00, 18 June 2026 (UTC)