Template talk:Infobox settlement/Archive 30

Archive 25

←

Archive 28

Archive 29

Archive 30

Archive 31

Archive 32

Archive 33

Add parameter official language

From my talk:

Hey- I wanted to ask if you could help me find someone interested in a small coding problem. The infobox Template:Infobox U.S. state has a parameter for the official language of a state. Alaska and Hawaii (and maybe South Dakota?) have more than one official language. However, there is no option to write "Official Languages" in the infobox. The result is that the twenty something official languages of Alaska are referred to as a singular (see Alaska). I think the option to make 'Language' a plural should be incorporated into the infobox. How can I get my idea in the queue for consideration? Thanks for any guidance. Geographyinitiative (talk) 20:30, 22 September 2020 (UTC)

There is no parameter "official language", but it would be nice to have, as in some countries some subdivisions have it. If it is added it should also be added with the option to have more than one. TerraCyprus (talk) 21:13, 22 September 2020 (UTC)

CLARIFICATION What I'm trying to say is that Hawaii and Alaska have more than one official language, but the infobox label is still "official language". There should be a way to add the 's' so that we aren't saying English and Hawaiian are the official language of Hawaii, but are instead saying English and Hawaiian are the official languages of Hawaii. It's particularly messed-up with respect to Alaska, where like twenty languages are listed in the infobox but it still says "official language". It is truly a pitiful display. See also "Official_Languages"_Parameter Geographyinitiative (talk) 19:27, 23 September 2020 (UTC)

As stated above, there is no |official_language= in this template. You'll need to have {{Infobox U.S. state}} updated. Primefac (talk) 23:38, 23 September 2020 (UTC)

... or have it implemented here instead of doing it there and maybe in 25 other wrappers and then still not having it for ~500000 articles that use IS directly. TerraCyprus (talk) 09:17, 24 September 2020 (UTC)

True, and I have no issue with adding such a parameter, but it should be discussed first (since clearly it's not used by non-wrappered template usage). Primefac (talk) 14:48, 24 September 2020 (UTC)

non-wrapped usages maybe have it in blank_field.

How to add it:

• which section
• which name, maybe "lang_official" to allow for lang_xyz
• what other lang_xyz could there be? most spoken. Also in some countries there are different statuses "national language", "regional language"
• maybe for more flexibility just lang_type lang_info and lang1_type lang1info ?

TerraCyprus (talk) 15:03, 24 September 2020 (UTC)

Just as a point of interest, {{infobox country}} uses |official_languages=, and I don't really see a need to deviate from that. Primefac (talk) 15:10, 24 September 2020 (UTC)

The needs have been presented above. TerraCyprus (talk) 18:56, 24 September 2020 (UTC)

{{Infobox UK country}} has

| languages_type = 
| languages = 
| languages2_type = 
| languages2 = 
| languages2_sub = 

maybe better than hardcoding "official". There are several statuses languages can have. TerraCyprus (talk) 00:23, 7 October 2020 (UTC)

Template-protected edit request 2020-10-06

please disable display of |image= to reduce likelihood of new occurrences as e.g. at this Brazilian place.

Category:Pages using infobox settlement with the image parameter with the exception of an archive page is empty. TerraCyprus (talk) 16:36, 6 October 2020 (UTC)

Cf. Template_talk:Infobox_settlement/Archive_25#Images_not_displaying there are about 65 articles that use |image= - that was in 2016. Yesterday 3400 used it, I took me several hours to clean it up using AWB, transferring the value either to image_skyline or image_map. TerraCyprus (talk) 18:06, 6 October 2020 (UTC)

This is  Done, per the December 2016 discussion and this follow-up request. I have, to the best of my ability, removed |image= from the code that rendered it, and from the parameter check, without breaking anything (I hope). Any use of |image= should display a red error message in preview and put the article in the usual unknown parameter tracking category. This template has a ton of transclusions and appears in a lot of wrappers, however, so I won't be surprised if there are problems somewhere. Editors are welcome to revert my changes while fixing any problems I have failed to anticipate. – Jonesey95 (talk) 20:33, 6 October 2020 (UTC)

I'm not a huge fan of this, nearly all infoboxes are consistent with |image = . Why should this infobox be any different? ɱ (talk) 21:53, 6 October 2020 (UTC)

User:Ɱ, one reason could be, that there are several |image_something parameters, to have one |image is a bit weird then. {{Infobox person}} only allows for one image. Last but not least, this edit request was mainly about avoiding |image and |image_skyline at the same time. Now it is consistent at least within this infobox. TerraCyprus (talk) 00:14, 7 October 2020 (UTC)

@TerraCyprus: Your clean up the other day has caused about a thousand errors over at Category:Pages using duplicate arguments in template calls. AWB was replacing image with image_skyline, the problem is it was doing it in articles that already had an image_skyline field (Example article diff) and so this has now filled up the duplicate arguments category. Can you have a look at cleaning it up please? Thanks. - X201 (talk) 15:14, 7 October 2020 (UTC)

Plastikspork, would it be possible for SporkBot to sweep through these pages and fix as many as possible? Some of them probably won't meet the bot's criteria, but a lot of them are probably fixable. – Jonesey95 (talk) 15:42, 7 October 2020 (UTC)

Some of them probably won't meet the bot's criteria; then the bot shouldn't be used. Primefac (talk) 20:20, 7 October 2020 (UTC)

Right. The bot will skip those that it should not edit. It's a smart bot task that has been operating to fix duplicate parameter errors for many years. – Jonesey95 (talk) 21:13, 7 October 2020 (UTC)

And the duplicates of |image_skyline= that should be deleted are probably all empty. TerraCyprus (talk) 22:31, 7 October 2020 (UTC)

Sorry, misunderstood the statement. Struck. Primefac (talk) 23:11, 7 October 2020 (UTC)

Jonesey95, X201 thank you. Bot would be nice. Tried with AWB, but doesn't work Wikipedia talk:AutoWikiBrowser/Regular expression#Removing a specific empty parameter. Sorry for causing this problem, I relied on the problem is/was that if both |image_skyline= and |image= are used then |image= is ignored. at the moment, that category tracks all uses of |image= but sorts the real problem pages with a ! sort key (for example, Chas Ghodegaon is currently sorted under !). I fixed those under "!" manually before starting the AWB editing. TerraCyprus (talk) 15:47, 7 October 2020 (UTC)

Make country reference in wrapper names consistent

1. Category:Data templates by country uses nouns, e.g. {{Data Australia}}, {{Data Brazil}}, {{Data France}}
2. Category:Country data templates by country uses nouns, e.g. {{Country data Australia}}, {{Country data Brazil}}, {{Country data France}}
3. Category:Template:Metadata Population uses noun and ISO code: {{Austria metadata Wikidata}}, Metadata Population BE, Population Cape Verde, DE metadata Wikidata, Israel populations
4. Category:Europe country and territory topics templates and those for other continents use nouns, e.g. {{Australia topics}}, {{Brazil topics}}, {{France topics}}
5. Category:Templates calling Infobox settlement uses nouns and adjectives

I suggest to use noun for the wrappers in Category:Templates calling Infobox settlement. TerraCyprus (talk) 17:33, 22 September 2020 (UTC)

@Andrybak: you are involved with template categories. What do you think about the proposal to use nouns when referring to countries in Category:Templates calling Infobox settlement? TerraCyprus (talk) 21:58, 22 September 2020 (UTC)

TerraCyprus, as far as I know, out of templates you've listed at least two groups—country data templates and topics templates—use nouns for technical reasons. —⁠andrybak (talk) 22:26, 22 September 2020 (UTC)

So far the following infobox templates have been moved:

• {{Infobox Albanian settlement}} to {{Infobox Albania place}}
• {{Infobox Cape Verde settlement}} to {{Infobox Cape Verde place}}
• {{Infobox French subdivision}} to {{Infobox French place}}
• {{Infobox German location}} to {{Infobox German place}}
• {{Infobox Greek Dimos}} to {{Infobox Greek place}}
• {{Infobox Portuguese subdivision}} to {{Infobox Portugal place}}
• {{Infobox Romanian subdivision}} to {{Infobox Romania place}}

Some of these are meant for specific types of administrative divisions, some are general for all kinds of settlements and administrative units in a country. I don't think it's bad that these infobox templates were moved, but I think it's not a big improvement either. The template names should be clear to people who want to use the templates, they don't have to be grammatically correct (or extremely consistent). Regardless of what names are chosen, there is quite some cleaning up to do, for instance template documentation and dead links from maintenance categories, and ideally also the template transclusions from articles should be updated. If I have to choose between noun and adjective, I prefer adjective, which looks more natural (a Greek place vs. a Greece place). Markussep ^Talk 14:58, 23 September 2020 (UTC)

A lot of those wrappers don't seem to be particularly useful, if IS were to handle such cases better. One of the biggest things they do is have preset leader names. I don't really see a reason why IS can't auto-determine the governmental field names based on country / type of settlement params automatically. Improves maintenance, and means editors don't need to hunt which is the 'appropriate infobox' to use, and what param naming scheme it uses. ProcrastinatingReader (talk) 16:44, 23 September 2020 (UTC)

To me as a frequent editor of articles about places in Europe these wrappers are very useful: they provide uniformity for articles about places in specific countries, automated content (recent population figures, links to higher administrative divisions etc.) and country-specific maintenance tools. Markussep ^Talk 06:52, 24 September 2020 (UTC)

@ProcrastinatingReader and Markussep: not sure why Markussep specifically listed these in this section, since only four use noun, and one of these, Cape Verde, had noun since inception. The seven listed by Markussep and mostly created by him are multi-type wrappers, the only ones for IS. I unified them under the name "place" following the longstanding names for {{Infobox Australian place}} (since 2007) and {{Infobox UK place}} (since 2007). In this section started by me, I don't want to discuss whether they should exist or not (disclosure: while in general I support using only IS, I would currently not support replacing high usage wrappers such as Germany place and France commune). Question: could you agree on using nouns for the wrappers in Category:Templates calling Infobox settlement as done for Cape Verde and New Zealand for a long time, following how it is done in the four other categories listed in my opening message? To editor Markussep: If I have to choose between noun and adjective, I prefer adjective, which looks more natural (a Greek place vs. a Greece place). - You didn't do that for Cape Verde. And "Greek place" could also refer to a Greek place in Cyprus. TerraCyprus (talk) 09:01, 24 September 2020 (UTC)

That's just a problem of the English language, that "Greek" can both refer to the country and to the ethnicity or language. Same for German and French, which are also spoken in other countries. How would you call a place in Greece, if not "Greek place"? I think as long as the documentation is clear about what to use the template for, the exact name is not so important. It would be rather silly to use Infobox French commune for places in Quebec, for instance. And for me the names don't have to be consistent. Markussep ^Talk 09:56, 24 September 2020 (UTC)

To editor Markussep: that for you "the names don't have to be consistent" is evident from looking at the history of the names for current multi-type wrappers now unified as X place:

1. 12:00, 28 December 2006‎ 52 Pickup created Infobox German Location
2. 01:18, 10 January 2007‎ El Greco created Infobox Greek Dimos
3. 13:15, 17 March 2014‎ Markussep created Infobox Cape Verde settlement
4. 15:56, 18 December 2014‎ Markussep created Infobox Albanian settlement
5. 18:31, 27 August 2019‎ Markussep moved Infobox Municipality PT to Infobox Portuguese subdivision
6. 18:49, 15 September 2019‎ Markussep created Infobox French subdivision
7. 15:01, 9 February 2020‎ Markussep created Infobox Romanian subdivision

Since this is English Wikipedia things that are "just a problem of the English language" had been deemed in need to be solved for clarity and consistency with respect to country-referents by using the noun. Still active Wikipedia:Category names#Categories by country, discussion in 2005 Wikipedia:Categories for deletion/Category:By country mentioned problems of adjectival forms. Wikipedia:Naming conventions (geographic names)#Region-specific guidance. TerraCyprus (talk) 10:48, 24 September 2020 (UTC)

I guess we disagree on the importance of consistency of template naming (the discussions/guidelines you quote don't seem to apply to templates). How about "Infobox place in X"? That would be nicely in line with the subcategories of Category:Populated places by country. Markussep ^Talk 11:51, 24 September 2020 (UTC)

To editor Markussep: I found no guideline adressing that topic. "subcategories of Category:Populated places by country" refers to categories, for that there is Wikipedia:Category names#Categories by country, it shows "in X" and "of X". Apart from that, that is an extra word. In the template namespace, there is:

1. "X Countryname" Category:Data templates by country: {{Data Australia}}, {{Data Brazil}}, {{Data France}}
2. "X Countryname" Category:Country data templates by country: {{Country data Australia}}, {{Country data Brazil}}, {{Country data France}}
3. "Countryname X" Category:Template:Metadata Population: {{Austria metadata Wikidata}}
4. "Countryname X" Category:Europe country and territory topics templates: {{Australia topics}}, {{Brazil topics}}, {{France topics}}

No "of", no "in". You created "Infobox Cape Verde settlement", we could just go with that choice of order and choice to use noun.

Currently there are 25 in Category:Templates calling Infobox settlement, just switching from adjective to noun would require 10 moves. Converting to "in" would require 25 moves. TerraCyprus (talk) 14:56, 24 September 2020 (UTC)

I still think "Infobox Greece place" and "Infobox Germany place" look silly, but I can live with it, as long as their functionality is kept. You may want to notify the affected WikiProjects (France, Germany, Albania, Romania, Greece etc.) about this plan. Markussep ^Talk 07:12, 25 September 2020 (UTC)

More silly than 13:15, 17 March 2014‎ Markussep created Infobox Cape Verde settlement ? Did you want to notify "affected WikiProjects" about your plans to create new Infobox settlement wrappers and merge others? TerraCyprus (talk) 17:22, 7 October 2020 (UTC)

That was 6 years ago, I changed my mind. And actually I did notify affected Wikiprojects, see Wikipedia_talk:WikiProject_France/Archive_6#Infoboxes_for_subdivisions and Wikipedia_talk:WikiProject_Cape_Verde/Archive_1#Infobox_template. Markussep ^Talk 06:58, 8 October 2020 (UTC)

Mapframe

Following the RfC, which found larger consensus to enable mapframes on infoboxes, I raise the matter of opt-in mapframes in this infobox. This infobox would need to decide on the position of the map. I think it should go at the top, where the pushpin map is currently. Second, I note we support two maps (one image, one pushpin), de facto used one for location within state, pushpin for location within country. How do we want to work with this? ProcrastinatingReader (talk) 16:57, 19 September 2020 (UTC)

ProcrastinatingReader, thanks for the initiative. Up to date maps is fine. "de facto used one for location within state, pushpin for location within country" - pushpin maps have a switch option, some boxes have several pushpin maps enabled. TerraCyprus (talk) 18:40, 22 September 2020 (UTC)

ProcrastinatingReader, how would opt-in be made? 500000+ articles use IS directly. TerraCyprus (talk) 22:01, 22 September 2020 (UTC)

Opt-in means the local article has to enable mapframes (using |mapframe=yes). The current sandbox implementation is opt in. By default, nothing will change on those articles if the change is synced. ProcrastinatingReader (talk) 23:48, 22 September 2020 (UTC)

ProcrastinatingReader opt-in based on types could be another opten. Less work in articles. One could start with everything that has iso_code and no wrapper, because for where wrappers still exist, people could prefer to assert control. In Asia it is Russia in Africa Cape Verde, Americas: Canada and US, Europe: no idea. TerraCyprus (talk) 01:16, 23 September 2020 (UTC)

We should not add it as a default. Many infoboxes already have 2 or more maps. IMO, having 3 maps for a location is overkill (not to mention that it makes infoboxes cumbersomely large). If mapframe is used it should replace the pushpin map because it has the same capability to show location within context. -- P 1 9 9  ✉ 13:07, 23 September 2020 (UTC)

@P199 and ProcrastinatingReader: how about enabling it everywhere - for extant entities -, where no pushpin or other map exists? That's brings the biggest benefit to the readers. TerraCyprus (talk) 09:14, 24 September 2020 (UTC)

I agree with that. -- P 1 9 9  ✉ 14:35, 24 September 2020 (UTC)

To editor ProcrastinatingReader: We can later look for more options to add, but this could be a nice starter. I suggest a tracking category, maybe just start with tracking of "extant but no map" to see what articles are potentially affected. TerraCyprus (talk) 15:07, 24 September 2020 (UTC)

I wouldn't implement this personally, and do oppose it for the time being. We have over 500k articles here. RfC found no consensus to enable by default, and whilst I guess local consensus can override a global no consensus, we should take note of the concerns raised there of widespread problematic maps on articles. I think for the time being opt-in is best, and go from there.

Pinging Evad37 for implementation thoughts. The mapping in this infobox seems more complicated, often with multiple maps. See San Francisco or Los Angeles for example - we've got pushpin maps, multiple image maps with different zooms, etc. Not sure what the best mapframe implementation would be here, and how far it should go. It would also need a safeguard for it to not be possible to cause 'conflicting maps' or overlaps with pushpins etc. ProcrastinatingReader (talk) 16:17, 24 September 2020 (UTC)

To editor ProcrastinatingReader: how is it less problematic if problematic maps are enabled on a by article basis? And why would you start with problematic cases where other maps exist, instead of focussing on where no map on extant entities exists, as P199 and me agreed on? Can you give at least one example for widespread problematic maps on articles that falls into IS usage on an extant entity without any other map? FTR: I oppose per-article enabling via yet another parameter. TerraCyprus (talk) 18:59, 24 September 2020 (UTC)

See discussion at Wikipedia:Requests_for_comment/Mapframe_maps_in_infoboxes#Q2._Display ProcrastinatingReader (talk) 20:03, 24 September 2020 (UTC)

To editor ProcrastinatingReader: the string "problem" does not exist in that section. TerraCyprus (talk) 22:51, 24 September 2020 (UTC)

To editor ProcrastinatingReader: and details comming re "widespread problematic maps on articles"? TerraCyprus (talk) 15:52, 25 September 2020 (UTC)

I oppose automatic map enabling unless there is some type of reasonable logic involved to determine if it should be enabled or not. Maps can cause layout issues, especially in tiny community articles where the infobox can overwhelm the article and cause layout issues! • Sbmeirow • Talk • 22:37, 24 September 2020 (UTC)

That logic was provided above, enable for extant places if no other map exists. Maps can cause layout issues, especially in tiny community articles where the infobox can overwhelm the article and cause layout issues! - Can you give an example? TerraCyprus (talk) 22:51, 24 September 2020 (UTC)

1) The reason for my statement is that years ago someone added pushpin maps (either manually or robot) to ten's of thousands of community articles in USA. Depending on the size of the articles and content in the articles, it either caused little or no problems for some articles (not my concern), or it caused a layout mess for other articles. 2) In Kansas, there are over 600 incorporated city articles, which all had two maps, thus the 3rd pushpin map caused numerous layout issues for articles with photos and tables along the right side, also it caused undue weight on the size of the inbox because there were too darn many maps. I ended up removing all pushpin maps from incorporated city articles in Kansas, which took a long time to do. 3) On the otherhand, in Kansas there are hundreds of unincorporated community and ghost town articles too, which either had no maps or one map prior to the pushpin map additions, thus in this case pushpin maps benefited all of these articles, and mostly helped articles that already had a county map, thus in the end I kept all pushpin maps for unincorporated communities and ghost towns. 4) At this point in time, the only community articles in Kansas that don't have a map are the stubs or short articles for unincorporated communities or ghost towns that don't have an inbobox yet, and overtime that number shrinks as I get around to adding an infobox to those. 5) Don't get me wrong, I like the idea of improved maps, and it would have been a killer idea 10 to 15 years ago before lots of maps were added to infoboxes, but now we need to STOP before FORCING a 3rd map into articles that already have two or more maps. 6) Over time, I may want to convert maps in Kansas articles over to a new map concept, but I sure the heck don't want to have to make a decision about it now or within the next 30 days either. • Sbmeirow • Talk • 17:11, 25 September 2020 (UTC)

Just to alert y'all, we have more options than you might know, shown to the side/below here. --ɱ (talk) 22:52, 24 September 2020 (UTC)

Ɱ, yeah, I think something interesting can be done with mapframes to replace all of the pushpins and images, probably. Some experimentation would be nice to see how well we can implement it. Input from Evad would be nice also. @TC, 'problem' isn't there, but read the discussion, I was not quoting the term problematic, I was describing my interpretation of the objections. ProcrastinatingReader (talk) 23:02, 24 September 2020 (UTC)

Infobox settlement/Archive 30
Interactive maps of Boston (can customize to country-state-city levels as well)

Infobox settlement/Archive 30
Interactive maps of Columbus

I suggest to start with a simple pin, no switcher. TerraCyprus (talk) 22:55, 24 September 2020 (UTC)

It is certainly technically possible, quite easy infact, to have mapframe default to on only if there are no other maps already being shown, and off otherwise - Module:Infobox mapframe lets templates pass in a value for on by default, which can be sonething like onByDefault={{#if:{{{someParam|}}}{{{otherParam|}}}||yes}} (so if either of those params are used in the article, the mapframe is off by default) - Evad37 [talk] 07:18, 25 September 2020 (UTC)
Ping me again if there were any other implementation issues to discuss, or if you want help adding it to the template/sandbox - Evad37 [talk] 12:40, 25 September 2020 (UTC)

Evad37, personally the main detail I wish to discuss is how much to implement mapframes. This particularly: The mapping in this infobox seems more complicated, often with multiple maps. See San Francisco or Los Angeles for example - we've got pushpin maps, multiple image maps with different zooms, etc. Not sure what the best mapframe implementation would be here, and how far it should go. + the two examples on the right hand side (multiple zooms - usually this would be done with picture maps not the pushpin). ProcrastinatingReader (talk) 14:12, 25 September 2020 (UTC)

I'm confused, wouldn't we just want the basic mapframe point map like other articles, set standard? And then editors of big cities like SF and LA can optionally abandon their less-detailed and more-spacious image/pushpin combos in favor of a preferred high-detail and compact map combos I featured? ɱ (talk) 14:22, 25 September 2020 (UTC)

I'm not sure. From an end-user perspective (of an editor on an article) I don't think they should have to write the |image_map= stuff your example has (that should be hidden in IS), as it's a bit too technical, and it also makes it easier for a future change to IS on specific functionality (e.g. if we wanted to change the icon, or hide some detail) to apply the change globally. We need to give simple params for editors on articles to enable it. I thought the whole image maps / pushpins case deserved some thought, but I'm not familiar enough with mapframes to know if it needs some special thought or if closer to a standard implementation will work here. ProcrastinatingReader (talk) 14:32, 25 September 2020 (UTC)

Shouldn't the standard mapframe implementation be used, per Q1 of the RFC... ...standard parameters for displaying mapframe maps (i.e. use of Module:Infobox mapframe) be added to the infoboxes.... That already allows for multiple maps via a switcher. Which in an article could be as simple as adding |mapframe=yes|mapframe-switcher=zooms (or =auto, or =geomasks with a list of wikidata Q-numbers in the |mapframe-geomask= parameter). "Side-by-side" or "picture-in-picture" (smaller mapframe overlaying a corner of a larger mapframe) are interesting ideas, but should be developed as part of Module:Infobox mapframe, or maybe even Module:Mapframe, so that other infoboxes or articles can benefit from their development. - Evad37 [talk] 14:56, 25 September 2020 (UTC)

RfC mapframe - create tracking category for extant places that have no other map

I suggest to create a tracking category for articles about places that

1. use {{Infobox settlement}}
2. and currently have no map in that Infobox, biggest benefit to readers, and minimal layout issues
3. and are extant, (i.e. exclude former places), since mapframe maps are current and not historic

Then we could look at the tracking category and have a more informed and efficient discussion. It is only about filling a tracking category, not about how the map could be designed. Users kept on claiming layout issues and concerns raised [...] of widespread problematic maps on articles etc. but no one pointed to a problem for any article about an extant place that has no infobox map. TerraCyprus (talk) 23:08, 24 September 2020 (UTC)

1. Support TerraCyprus (talk) 23:09, 24 September 2020 (UTC)
2. Support if tracking considers pushpins as maps too. • Sbmeirow • Talk • 16:23, 25 September 2020 (UTC)
   • @Sbmeirow: of course! TerraCyprus (talk) 01:27, 26 September 2020 (UTC)

RfC clarification discussion

• I don't see how having such a tracking category would address the concerns from the above discussion. They seem to mainly be about adding yet another map to articles which already have multiple maps - either by being on by default despite the presence of the other maps (which isn't actually being proposed), or by editors manually adding them without thinking about how the article will look with so many maps in the infobox. - Evad37 [talk] 23:57, 25 September 2020 (UTC)

  @Evad37: it addresses that there was a question: "how about enabling it everywhere - for extant entities -, where no pushpin or other map exists? That's brings the biggest benefit to the readers. TerraCyprus (talk) 09:14, 24 September 2020 (UTC)" and to which a user replied do oppose it for the time being [...] we should take note of the concerns raised there of widespread problematic maps on articles. - but after requests for what kind of problems that are etc. no such "widespread problematic maps" were presented. The idea is to start with the easy stuff which brings the biggest benefit. Step 1, find articles about extant places that use IS and have no map. Do you support finding them by creating a tracking category? I don't even know how much there are. TerraCyprus (talk) 01:40, 26 September 2020 (UTC)

complete 30 day RfC

• Why has a complete 30 day RfC been started?? We're workig on this through our normal template process, above... Nobody is going to throw things into a live template with 500k usages when we haven't put any thought into them yet, so it's not going to happen in a day. WP:RFCBEFORE. There's no need for an RfC for a tracking category either, any TE/admin can add one. ProcrastinatingReader (talk) 10:42, 25 September 2020 (UTC)

Why has a complete 30 day RfC been started + WP:RFCBEFORE : No WP:RFC has been started. "any TE/admin can add one" : then do it. Endless talking no results. TerraCyprus (talk) 13:35, 25 September 2020 (UTC)

Changing/adding headings now kinda makes the context of my comments confusing. If you want to sandbox your changes to tracking categories someone can look at implementing it, otherwise I'm not entirely sure what you're looking to track currently. ProcrastinatingReader (talk) 14:26, 25 September 2020 (UTC)

reverted change of heading. If you want to sandbox your changes to tracking categories someone can look at implementing it: I don't want until there is support for it. Have other things to do than to create code and code not adopted because tracking not wanted and the sandbox currently isn't synced [1]. otherwise I'm not entirely sure what you're looking to track currently - has been explained above in English, no code needed. TerraCyprus (talk) 15:38, 25 September 2020 (UTC)

Ping re tracking category

@ProcrastinatingReader, Evad37, P199, Ɱ, and Sbmeirow: can you state above if you support adding a tracking category first so that we better know which articles would potentially get a map? I have no idea how many, from which countries etc. TerraCyprus (talk) 14:00, 25 September 2020 (UTC)

After much ado about nothing, I've made a tracking category. Happy waiting for it to fill. --Izno (talk) 02:43, 26 September 2020 (UTC)

Izno, great, thank you!! Little improvement Canton of Benfeld has "disbanded = 2015", that is in Template:Infobox French place and goes to | extinct_date = {{{disbanded|}}} . Can you include a check for that to be empty? TerraCyprus (talk) 01:52, 27 September 2020 (UTC)

Or maybe better create an extra tracking for extinct/former ... then users can use Wikipedia:Category intersection to combine whatever they are interested in. TerraCyprus (talk) 01:55, 27 September 2020 (UTC)

I did not see consensus for this opinion that former areas should not be tracked as such. Please feel free to gain it from among those of you here. --Izno (talk) 13:29, 27 September 2020 (UTC)

Izno, can you create tracking for extinct/former? @ProcrastinatingReader: I think mapframe should not be used on historic items, as the maps from mapframe are current maps. TerraCyprus (talk) 22:44, 7 October 2020 (UTC)

Izno, Whitemarsh Township, Montgomery County, Pennsylvania uses | image_map1 = File:Whitemarsh Township Montgomery County.png , so image_map1 should be added. TerraCyprus (talk) 02:05, 27 September 2020 (UTC)

The documentation says image_map1: A secondary map image. The field image_map must be filled in first. Either this is untrue and the documentation must be updated, or these pages are in error. --Izno (talk) 13:29, 27 September 2020 (UTC)

Izno, the article I mentioned clearly shows an image. "must" in the documentation is not defined, at least for image_map1 to appear, it isn't required. If you don't want to add it, could you create another tracking category, image_map1 filled, but image_map not? So one can better analyse which and how many pages are affected. Maybe there is a reason, e.g. certain type of entities have a certain type of map allways _map1, irrespective of _map. TerraCyprus (talk) 15:36, 27 September 2020 (UTC)

Is the documentation wrong? If so, you should update it. If not, should the template be updated to require users to add one before the other? I have no issue with updating the one tracking category if the template documentation is incorrect, but we should fix the template if otherwise... --Izno (talk) 16:18, 27 September 2020 (UTC)

Izno, incorrect or not, to see how many pages are affected by _map1 exists and _map not, one needs a tracking category. TerraCyprus (talk) 16:23, 27 September 2020 (UTC)

Okay, I'll accept that. --Izno (talk) 16:58, 27 September 2020 (UTC)

Tracking maps in wrong parameter

Izno, is there a way to check for SVG or map in |image = ? E.g. Hali Ela Polling Division

 |image = Hali_Ela_Polling_Division_Sri_Lanka.svg

Probably in Commons maps are in c:Category:Maps, the one above wasn't in Commons, but now is [2] I don't know how to find if a file is in a certain Commons category. But the file extension could be detectable here in enwiki. Tracking category for ".svg" in |image = ? There still can be PNG, JPG maps, and there can be non-map SVG (what could they depict?), but such a tracking would be a start for more clean-up. TerraCyprus (talk) 15:54, 28 September 2020 (UTC)

I think that's slightly out of the scope of this discussion, and I'm not particularly certain what the gain is there to tracking the file type. Besides that, it's a bit beyond my skill. (And no, you can't see what categories a file is in on a foreign wiki.) --Izno (talk) 16:09, 28 September 2020 (UTC)

Izno, why is it out of scope to find maps displayed by Infobox settlement if the topic is about displaying mapframe-maps and some users wanting not to have too many maps? Re And no, you can't see what categories a file is in on a foreign wiki. - what is "foreign"? At least for Commons I can see the categories, they are displayed on Commons at the bottom of each page. TerraCyprus (talk) 16:31, 28 September 2020 (UTC)

The basic gist is that templates cannot know things about other wikis. (Some exceptions apply.) Even if the HTML displays here, that does not mean you can do anything with that data in its current form.

out of scope to find maps displayed by Infobox settlement if the topic is about displaying mapframe-maps and some users wanting not to have too many maps Because tracking the kinds of images which fill the map parameters doesn't do that from what I can see? Maybe it does, but you have not made a case for it. (Even from a quality perspective; someone could want/have a land-map displayed for which a JPG is probably a better solution than a PNG or SVG.) --Izno (talk) 17:04, 28 September 2020 (UTC)

Because tracking the kinds of images which fill the map parameters doesn't do that from what I can see? Why do you reply to my question with another question. Please explain why it would be out of scope to find maps in |image = . TerraCyprus (talk) 17:52, 28 September 2020 (UTC)

The question mark there is to express a tentative thought, not to ask a question; it's really Because tracking the kinds of images which fill the map parameters doesn't do that (I think). That said, now I realize you're asking about |image=, but I do not think finding SVGs there will be any more help either. You're just as likely to bump into a coat of arms or logo there. --Izno (talk) 18:42, 28 September 2020 (UTC)

Izno, COA would be misplaced too. |image= normally contains photographs. I don't know what else. But for COA, flag and map there are dedicated |image_something . I don't know what SVG could be in |image= in the Infobox settlement and not be misplaced. TerraCyprus (talk) 13:11, 29 September 2020 (UTC)

We do already have a category that tracks |image='s use, for what I assume is either the use case of deprecation and removal, or for the case of finding issues like that one. (It is not obvious to me which that is; the originating discussion is not clear.) I would support deprecation of the parameter entirely, but I have not researched and at least one comment there alludes to systemic use elsewhere. --Izno (talk) 14:20, 29 September 2020 (UTC)

Izno, the problem is/was that if both |image_skyline= and |image= are used then |image= is ignored. at the moment, that category tracks all uses of |image= but sorts the real problem pages with a ! sort key (for example, Chas Ghodegaon is currently sorted under !). I really don't care concerning deprecation, but at the very least, we should probably show a warning/error when both |image_skyline= and |image= are used at the same time). Frietjes (talk) 14:26, 29 September 2020 (UTC)

BTW.: Avatoru has only one parameter at all, image_skyline, formerly image. TerraCyprus (talk) 22:11, 5 October 2020 (UTC)

@Izno and Frietjes: I converted ~2000 image= to either image_skyline= or image_map=. 1400 left in Category:Pages using infobox settlement with the image parameter. I support removal of |image= . TerraCyprus (talk) 01:41, 6 October 2020 (UTC)

@Izno: - all fixed. You can disable |image= now. TerraCyprus (talk) 06:49, 6 October 2020 (UTC)

@Izno: now |image= is gone and what I wished to have for that parameter I now wish to have for |image_skyline=, e.g. Abington (ward) had a PNG [3], so check for PNG and SVG would be good. TerraCyprus (talk) 22:53, 7 October 2020 (UTC)

You are free to code that or find someone who can, and probably also establish consensus that such a category is necessary. --Izno (talk) 16:17, 8 October 2020 (UTC)

Tracking coordinates exist but not in infobox

Achaya District has coords but outside infobox. @Evad37, ProcrastinatingReader, and Izno: would be good to clean this, not? But inside IS template one cannot check for coordinates in other template, or can one? I have never seen it, but maybe MediaWiki can do it? In cases like that the coordinates maybe always exist in Wikidata, d:Q3823859 (Achaya District) has coordinates, so maybe it is not so important to find these cases. TerraCyprus (talk) 23:05, 7 October 2020 (UTC)

The infobox could add a tracking category for any uses without coordinates, and/or for any uses without coordinates and without wikidata coordinates. You could then use WP:PetScan to find the intersection of pages in that category and pages using the {{coord}} template. - Evad37 [talk] 23:18, 7 October 2020 (UTC)

See Template talk:Infobox bridge for an example of how we did this for a different infobox. This one got a little complicated because Wikidata was involved, but Evad37's idea is basically what I used. – Jonesey95 (talk) 00:13, 8 October 2020 (UTC)

@TerraCyprus:  Done as Category:Pages using infobox settlement with no coordinates - Evad37 [talk] 01:41, 11 October 2020 (UTC)

"Template:Romanian counties infobox" listed at Redirects for discussion

A discussion is taking place to address the redirect Template:Romanian counties infobox. The discussion will occur at Wikipedia:Redirects for discussion/Log/2020 October 28#Template:Romanian counties infobox until a consensus is reached, and readers of this page are welcome to contribute to the discussion. TerraCyprus (talk) 02:12, 28 October 2020 (UTC)

Wrong values in ISO 3166 code

Grue, Norway displays "NO-3417", but ISO 3166-2:NO doesn't support that. TerraCyprus (talk) 03:26, 28 October 2020 (UTC)

Proposal for Adding a Parameter (area_footnotes)

Infobox settlement has a parameter called area_footnotes that makes the website look professional by putting the source for a land area figure above the number. I propose that this parameter be added to Infobox political division. Geographyinitiative (talk) 15:56, 7 November 2020 (UTC)

Infobox settlement clean up in articles

There is a proposal at Wikipedia:Village pump (proposals)#Cosmetic Bot Day (CBD) that if approved could allow automated clean up of code. What could be done related to Infobox settlement?

• General fixes applied to any infobox
  • removal of unsupported empty parameters
  • alignment of parameter, space in front and filling with spaces so all = are in a column
  • sorting of parameters
  • replacing
• Specific to this infobox
  • coord? Sometimes they are given in decimal form, sometimes in degrees and minutes
  • Country : | subdivision_type = [[Countries of the world|Country]] and | subdivision_name = {{flag icon|Poland}} [[Poland]] ... sometimes Country is not linked, sometimes there are no flags, sometimes "{{POL}}" is used.

More ideas? TerraCyprus (talk) 18:59, 27 October 2020 (UTC)

I oppose the notion that decimal/dms formatting of coordinates is something that needs to be regularized. Deor (talk) 19:25, 27 October 2020 (UTC)

Just as a note, the changes you mention in "Specific to this infobox" are not cosmetic and would be acceptable for changing via the normal routes. Primefac (talk) 19:26, 27 October 2020 (UTC)

...if there were consensus for the desired outcome, which at this point there does not appear to be. Nikkimaria (talk) 21:02, 27 October 2020 (UTC)

True, but I guess my point is that if there were a consensus about the standard layout of those parameters, it would not require this "get out of jail free" exception proposed by the CBD. Primefac (talk) 21:05, 27 October 2020 (UTC)

In 2020 redirects are still being added to articles, e.g. infobox municipality [4]. Another editor may not be aware that this is a redirect to Infobox settlement and they could use any parameter of that template. TerraCyprus (talk) 03:28, 30 October 2020 (UTC)

Not really sure what you mean, any parameter of that template; if it's a redirect then it can only use the IB settelement params (improper uses will trigger the unknown param cat). Primefac (talk) 17:44, 1 November 2020 (UTC)

If an editor edits in source code mode then they see "Infobox municipality" - it is not transparent that it is a redirect to IB settelement and that all params work as in IB settelement. So, it is source code which is bad for editing. IIRC ProcrastinatingReader, who is involved with place infoboxes, mentioned bad code in infoboxes as a reason to support "Cosmetic Bot Day". This is a variation, bad infobox code in the template name itself. TerraCyprus (talk) 18:28, 2 November 2020 (UTC)

Quite a lot of us stated bad infobox syntax, especially types which doesn't quite rise to CB-exempt edits, as a good reason for CBD. But bad infobox syntax is a pretty big range of issues, each of which would have to be determined on its own merit and gauging of consensus per-BRFA should CBD pass. The one about removing {{Infobox municipality}} can already be done I think; if you take it to RfD for deletion and it passes, a bot would have to implement that outcome. (technical note: I don't know if we have a "implementing RfDs general approval" bot, but it's probably not much of a distinction from implementing TfDs.) ProcrastinatingReader (talk) 18:48, 2 November 2020 (UTC)

Correct regarding RFD, not sure about the bot though; I feel like XFDC would give the option of removing the redirect but not changing it. Primefac (talk) 15:12, 4 November 2020 (UTC)

RfD regulars tend to keep almost anything. I would just start a discussion here and see you can get consensus for a bot to convert redirects. --Gonnym (talk) 15:32, 4 November 2020 (UTC)

May be got the wrong end of the stick here but it is best not to convert the redirects as you can look at all articles that use the redirect as a set and make appropriate article changes as you know that they are relevant. Rather than having {{infobox settlement}} and not having anything easy to identify the set of articles related to municipalities. Keith D (talk) 21:22, 4 November 2020 (UTC)

It's a dangerous assumption to make, thinking that all municipalities are using {{Infobox municipality}} rather than {{Infobox settlement}} directly. It also would exclude per-country IS municipality wrappers. I feel like, if anything, avoiding the misunderstanding is an argument for deletion not retention. ProcrastinatingReader (talk) 13:17, 5 November 2020 (UTC)

re:TerraCyprus, I'm still not sure what you mean. If I'm editing in source, and I see {{infobox municipality and go "gee, I wonder which params work for that" and type in "Template:infobox municipality" into the URL, it will be redirected to "Template:Infobox settlement" with a helpful note saying I was redirected there. It is very transparent that it's a redirect. "Source code is bad" is a weird way to try and get things changed. Primefac (talk) 15:06, 4 November 2020 (UTC)

Waste of time to go "gee, I wonder which params work for that" and type in "Template:infobox municipality" into the URL. And I don't know what is type in "Template:infobox municipality" into the URL - the address bar of the current browser tab? What if that doesn't exist? Would it preserve other changes in the article? ... TerraCyprus (talk) 04:26, 8 November 2020 (UTC)

STRONGLY OPPOSE any agressive reformatting efforts, though minor cleanup and fixes are fine. • Sbmeirow • Talk • 22:13, 5 November 2020 (UTC)

• General fixes applied to any infobox (AGREE)
• removal of unsupported empty parameters (AGREE if you mean remove "dead" parameters that aren't currently in the template)
• alignment of parameter, space in front (DON'T AGREE - we don't need a darn space in front of a field/parameter name, knock it off)
• alignment of parameter, filling with spaces so all = are in a column (NO & YES - HECK NO if the inbox is already aligned but the bot wants to realign to a new alignment, YES if a majority of fields don't currently have any alignment)
• sorting of parameters (HELL NO if you mean moving rows of text around to put it in some other order)
• coord? Sometimes they are given in decimal form, sometimes in degrees and minutes (WHICH ARE YOU PICKING???) - (AGREE only if Degrees and Minutes) which are best for USA communities, because it's the same as data that comes from GNIS database.
• Country (AGREE as long as NOT adding automatically flags in USA)
• OTHER - (Don't remove wiki comments)
• OTHER - (Don't remove white lines)

@Sbmeirow: Quibble: The GNIS database gives geographic coordinates in both decimal and d/m/s form, so there's no reason to use it as justification for preferring d/m/s. Deor (talk) 22:35, 5 November 2020 (UTC)

@Sbmeirow: HELL NO - please see WP:ILIKE. TerraCyprus (talk) 01:34, 8 November 2020 (UTC)

ok, replace with STRONGLY NO, or what ever is politically correct to mean the same. • Sbmeirow • Talk • 01:56, 8 November 2020 (UTC)

@Sbmeirow: WP:ILIKE doesn't mention what ever is politically correct to mean the same. TerraCyprus (talk) 02:05, 8 November 2020 (UTC)

ILIKE links into an essay named Wikipedia:Arguments to avoid in deletion discussions, but the current discussion isn't about deleting articles. This discussion is about what an automated cleanup BOT does to numerous articles. When bots/tools work perfectly I don't have any complaints about them, but unfortunately all bots/tools aren't always 100% perfect. If a bot/tool only causes issues with a few articles, then it's not a big deal, because the total amount of time to fix it is small, but if a bot/tool causes minor issues on hundreds or thoundsands of articles, then the total amount of time to cleanup can be quite a large amount of wasted time by editors like me! • Sbmeirow • Talk • 03:19, 8 November 2020 (UTC)

@Sbmeirow: do you oppose parameter sorting because bots may introduce errors? TerraCyprus (talk) 03:24, 8 November 2020 (UTC)

@TerraCyprus: thanks for asking! To give you a better response, I need to understand what you exactly mean by "parameter sorting": 1) does "parameter" mean the the item on the left side of the "=" in the following link? 2) does "sort" mean alphabetical sort from "A" to "Z", or does it mean re-ordering into some pre-determined order? • Sbmeirow • Talk • 04:08, 8 November 2020 (UTC)

@Sbmeirow: thank you for asking! With parameter I mean the part left of "=", but when sorting is done, of course the values right of "=" will be moved too. Not A-Z, but pre-determined order. Sometimes I found a parameter in a very unusual place, it can also lead to having a parameter twice, e.g. one expects something_y at the upper part after something_x and there it isn't, so one manually inserts something_y. But it could exist 'hidden' or 'burried' further down after somethingelse_.... The coordinates are usually further up, but sometimes I found them near the bottom. For predetermined one could use the order in the actual code or in the template documentation. Probably both should be the same. TerraCyprus (talk) 04:19, 8 November 2020 (UTC)

@TerraCyprus: Though I mainly edit Kansas community articles, I have edited small quantities in other states too, thus I have recognized a big different across many states. The infobox is well maintained in some states, while some states it's a big mess. I have been cleaning up Kansas articles over the past decade.... I reordeded all sections into their proper order as well as remove vandalism, then I did 1 or 2 passes of reordering the infobox and removing uncommon parameters, and currently I'm about 1/2 to 2/3 of the way into a final cleanup pass of the infobox and minor cleanup of the article since the last time pass. Dodge City, Kansas is an example of how I reformatted the infobox of city articles in Kansas. Thus, I prefer major reformatting of infoboxes be considered on a state by state basis. After this comment, I won't be able to respond until mid to late Sunday. • Sbmeirow • Talk • 08:04, 8 November 2020 (UTC)

@Sbmeirow: Why should places in Kansas be treated differently from places in other U.S.(?) states and why should there be any special treatment of U.S.(?) places at all? Re I did 1 or 2 passes of reordering the infobox and removing uncommon parameters, and currently I'm about 1/2 to 2/3 of the way into a final cleanup pass of the infobox which was part of your work over the past decade - did you notice that my proposal means that it could be done by a bot and that it could be done in a day, not only for Kansas, not only for the U.S. but for all instances where Infobox settlement is used in articles? TerraCyprus (talk) 00:17, 10 November 2020 (UTC)

Oppose, because too few people will have the power to reformat inboxes without the community as a whole having a say on how they should look. I'm sure numerous editors don't even those this is being proposed! Bots need to stick cleaning up the small stuff. • Sbmeirow • Talk • 05:33, 10 November 2020 (UTC)

That is the same text that you posted one minute earlier in discussion about a different topic [5], it may fit there, but it - starting with Oppose - doesn't fit as a response to my questions which started with "Which" and "Did you". TerraCyprus (talk) 00:02, 11 November 2020 (UTC)

Changes in /sandbox

I've updated the sandbox with the following changes:

1. Removed the |embed= parameter. From the above discussion, only 5 articles used it out of the over 500k transclusions of this template. All 5 were incorrect usages of this template which I've removed. Even if they were valid, the fact that less than only 0.001% used it means it isn't helpful. This is clear case of where not every template needs to be able to be embeded.
2. Changed the way we handle |native_lang= values.
   1. |native_lang= now uses {{Lang}} to validate the |native_name_lang= and if it isn't invalid, uses it without a language code (can also be changed to use it with the code, which would then place it in an error category, which can then be fixed). Additional gain from this is that the page would now be categorized in the correct Category:Articles containing non-English-language text category.
   2. The /doc supports additional native languages so I've added |native_lang2= and |native_lang3=, along with their lang parameters.
3. Separated the |other_name= subheader from |native_lang=.

I tested the changes and didn't see any bugs, but if you can, test and let me know. If no issues then I'll sync to live. --Gonnym (talk) 09:03, 1 October 2020 (UTC)

The test case for Herāt contains an extra solid line above the native_name, and the Briarcliff test case contains a line above the other_name. The native_name is also rendered much smaller in the sandbox (see Sequim, Washington test case), and the bold formatting for other_name has been removed. These seem like unintended changes. – Jonesey95 (talk) 13:30, 1 October 2020 (UTC)

Thanks for testing. I'll take a look at what you found now. --Gonnym (talk) 13:34, 1 October 2020 (UTC)

The extra solid line is because I split the |native_lang= from the |above= and moved it into |subheader1= and the size of text is a result of it being a lower-class header. |other_name= was moved to |subheader2= so the extra solid line is also from this. I've removed the above lines (borders) and bolded the other_name. Not sure to what size to make the native_name bigger, so let me know. While I don't mind this, as a personal taste, I found the borders nicer here as it did make the distinction between the sections, which these 3 different titles are. --Gonnym (talk) 13:45, 1 October 2020 (UTC)

Native names typically do not use borders, so I don't think they should use them here. I have made the native name bigger, though not quite as large as the official name. I don't love the large amount of space between the headers, although the live version's headers are jammed too close together for my taste. How do we end up with a reasonable but not too large amount of white space between lines?

A clarifying question: If these changes have consensus, is it your intent to copy only the header/subheader changes from the sandbox? There are a bunch of other changes and regressions in the sandbox that should not be applied to the live template. – Jonesey95 (talk) 15:31, 1 October 2020 (UTC)8

I'll try and play with line-height or negative margins to see if I can make the rows closer. My intention is only for what I wrote above, which includes the top part of the template and the unknown parameter section. --Gonnym (talk) 15:43, 1 October 2020 (UTC)

@Jonesey95: I've reduced the size between the sections with padding-top and padding-bottom but in my opinion it looks too small. If it's too small that's actually good as I don't think I can make it smaller but making it bigger is possible. --Gonnym (talk) 13:00, 2 October 2020 (UTC)

The native names and the other name are still too close together, but a little padding should make them work. I have added some non-Roman-script names to the first two test cases, since they sometimes overlap with Roman-script languages. – Jonesey95 (talk) 15:59, 2 October 2020 (UTC)

Added more padding. I think this is the best* it can get without using the actual row heights a table data cell should (which is ideally the optimal). --Gonnym (talk) 16:50, 2 October 2020 (UTC)

Gonnym, re |native_lang= at Template:Infobox settlement/doc I cannot find any occurrence of that string. TerraCyprus (talk) 18:11, 6 October 2020 (UTC)

My mistake, |native_name= and |native_name_lang=. --Gonnym (talk) 18:20, 6 October 2020 (UTC)

please add the native_name23 parameters from the sandbox so bi- and trilingual places can be better covered. TerraCyprus (talk) 00:18, 7 October 2020 (UTC)

The line spacing has still not been fixed in the sandbox. We need more space between lines for the native names. See the test cases, where some non-Roman characters are overlapping from line to line (at least on my screen). – Jonesey95 (talk) 01:51, 7 October 2020 (UTC)

As I said, more spacing between the lines is the original version, which uses default padding between lines, as it should. --Gonnym (talk) 09:19, 7 October 2020 (UTC)

@Jonesey95 and Gonnym: how is it possible to get more parameters for native_name? TerraCyprus (talk) 00:12, 11 November 2020 (UTC)

If we switch to using non-hacking methods and proper table usage, then it shouldn't be a problem adding as many as wanted. In that I mean, switch to using a subheader# per language, which would give each language in its own row. See Template:Infobox settlement/sandbox2 and Template:Infobox settlement/testcases4.

Template-protected edit request 2020-11-12

The place name etymology is currently separated from the place name(s), see an example at Bilohirsk (Crimea). Fix this by moving the etymology upwards.

<!-- ***Etymology*** -->
| rowclass20 = mergedtoprow
|  data20 = {{#if:{{{etymology|}}}|Etymology: {{{etymology}}} }}

renumber to 18 and move to the end of the section ** names, type, and transliterations ** after the section ***Transliteration language 2***, so the new code is

| rowclass17 = mergedbottomrow
| label17 =  • {{{translit_lang2_type6}}}
| data17 = {{#if:{{{translit_lang2|}}}|{{#if:{{{translit_lang2_type6|}}}|{{{translit_lang2_info6|}}}}}}}

<!-- ***Etymology*** -->
| rowclass18 = mergedtoprow
|  data18 = {{#if:{{{etymology|}}}|Etymology: {{{etymology}}} }}
<!-- end ** names, type, and transliterations ** -->

<!-- ***Skyline Image*** -->
| rowclass19 = mergedtoprow
<!--| rowcellstyle19 = padding:0.7em 0.8em-->
| data19 = {{#if:{{{image_skyline|}}}|<!--

...

<!-- ***Flag, Seal, Shield and Coat of arms*** -->
| rowclass20 = mergedtoprow
| class20 = maptable
|  data20 = {{#if:{{{image_flag|}}}{{{image_seal|}}}{{{image_shield|}}}{{{image_blank_emblem|}}}{{both|{{{pushpin_map_narrow|}}}|{{{pushpin_map|}}}}}

TerraCyprus (talk) 02:23, 12 November 2020 (UTC)

Please first establish consensus for this proposed change. Nikkimaria (talk) 02:27, 12 November 2020 (UTC)

@Mzajac, ProcrastinatingReader, and Gonnym: an editor requested establishing consensus for this change to happen and you three took part in the discussion section above named "Name labels needed". ProcrastinatingReader there wrote some of these (like other name) could be pushed down into the regular fields, but I would favor to have all name related stuff together, since the fields depend on each other. If one has several names, then etymologies of these names can vary. Also transliterations depend on the names itself. Please have a look at Bilohirsk (Crimea), where several official and native names and one etymology exists - the one for Crimean Tatar is not in the infobox. TerraCyprus (talk) 02:59, 12 November 2020 (UTC)

That article is certainly a mess, but the proposed change wouldn't fix it. Nikkimaria (talk) 03:03, 12 November 2020 (UTC)

Insulting contributors to that article would fix what? Anyway, the proposed change is about {{Infobox settlement}}, if you want to contribute to the article please do so or use it's talk page. TerraCyprus (talk) 03:15, 12 November 2020 (UTC)

I agree moving all of the naming stuff together is probably an improvement, but there are other related problems. It would be nice to see a mock-up of the proposed version. Shouldn’t etymology be associated with or integrated into the native_name field? Otherwise, the native names have to repeated in the etymology, just adding to the excessive clutter (see, e.g., Bilohirsk (Crimea)). —Michael Z. 04:11, 12 November 2020 (UTC)

@Mzajac: agreed, I see my request as a first step. Added an image to image_skyline at Bilohirsk (Crimea) to show more of the possible distance. If etymology is moved upward one could also create label18 instead of the current "Etymology:". One more step to get labels as you proposed in the other section, if this one would use proper label technology. TerraCyprus (talk) 04:27, 12 November 2020 (UTC)

Please use the sandbox and the testcases page to show what the proposed change would look like. – Jonesey95 (talk) 06:14, 12 November 2020 (UTC)

Template-protected edit request 2020-11-12b

Technical request to fix section naming in the code, no change in articles. This will better align with Template:Infobox settlement#Parameter names and descriptions where a section "Name and transliteration" exists that includes all these parameters.

Extended content

<!--** names, type, and transliterations ** --> is misplaced some names are before it. Move the comment up, directly before the line | abovestyle = font-size:1.25em; white-space:nowrap So the new code is <!--** names, type, and transliterations ** --> | abovestyle = font-size:1.25em; white-space:nowrap | {{#ifeq:{{yesno|{{{embed|}}}}}|yes|title|above}} = {{#ifeq:{{yesno|{{{embed|}}}}}|yes| |<div style="display:inline" class="fn org">{{if empty|{{{name|}}}|{{{official_name|}}}|{{PAGENAMEBASE}}}}</div> }}{{#if:{{{native_name|}}}|<br /><div class="nickname" style="font-weight:normal;display:inline;" {{#if:{{{native_name_lang|}}}|lang="{{{native_name_lang}}}"}}>{{{native_name}}}</div>}}{{#if:{{{other_name|}}}|<br /><div class="nickname" style="font-size:78%;display:inline;">{{{other_name}}}</div>}} | subheaderstyle = background-color:#cddeff; font-weight:bold;

TerraCyprus (talk) 03:26, 12 November 2020 (UTC)

So what does this change? Oh, I see. —Michael Z. 04:15, 12 November 2020 (UTC)

sandbox [6] TerraCyprus (talk) 11:40, 13 November 2020 (UTC)

To editor TerraCyprus:  done, and thank you very much! P.I. Ellsworth  ed. ^put'r there 15:48, 13 November 2020 (UTC)

Why was (s) removed from "Area code(s)"?

Buaidh, why did you make this change to remove "(s)" from "Area code(s)"? Category:Pages using infobox settlement with possible area code list still has over 4,000 articles in it, including pages like Aldrich, Alabama, which lists two area codes. Unless you have a good explanation, please revert until the category has been reviewed. – Jonesey95 (talk) 05:27, 28 November 2020 (UTC)

And now the label has been changed again, but it is still worse than before at Aldrich, Alabama, and presumably at a few thousand more articles. – Jonesey95 (talk) 14:17, 28 November 2020 (UTC)

I'm not sure what you think my change (your "changed again" text) did, but it simply removed an unnecessary #if statement. I won't necessarily contest the first edit, but my (second) edit was perfectly reasonable. I would say, though, that if people are mis-using |area_code= either not knowing that |area_codes= exists, or just not caring, that maybe we should deprecate the latter and revert to the "Area code(s)" label previously used. Primefac (talk) 14:23, 28 November 2020 (UTC) and as a very minor point, I've changed Aldrich to show the correct label

I have restored the original code. We need it until the category is cleared. Once it is cleared, we can have one label for |area_code= and one for |area_codes=. We are in a transition period right now. – Jonesey95 (talk) 19:00, 28 November 2020 (UTC)

Better usage of data templates (AKA cleaning up the crap)

Consensus seems to be that this template shouldn't be used as a metatemplate, but rather directly used for settlements, so I've wondered how to make this more friendly than Special:Diff/982659771 (to allow for cleaner/less confusing/less maintainable wikitext, and aid future merges). Related discussion: User_talk:ProcrastinatingReader#IB_settlement.

The point is that countries have country-specific features and data. This data should really not be repeated/exposed through articles (unless it's being overriden), eg the infobox value in Kotka is silly to me. Which leaves the better options of either using data templates (such as Template:Data Finland municipality), or using Wikidata - and consensus seems to be icky on Wikidata. I played around with a MVP of the data templates option in Module:Sandbox/ProcrastinatingReader/ib, but the less technical summary is that this change allows usage of data templates and cut down on infoboxes in articles as such: Special:Diff/992356198/992478194. Parameters can be manually specified to override the default data template values. It should also improve maintainability when new national yearly figures come around.

It's not polished yet, and only a proof of concept, but I wanted to get some thoughts. ProcrastinatingReader (talk) 13:46, 5 December 2020 (UTC) Edit: Worth adding, we can also change our approach to Wikidata and allow it to be used to fetch population/demographics/etc as a fallback. ProcrastinatingReader (talk) 14:05, 5 December 2020 (UTC)

I think if there are country- or region-specific values that would be the same across all of the pages that would use this template if it were a wrapper template (i.e. "Japan city", "Finnish municipality", etc), it should be stored in a single location so that it can all be updated and maintained locally. Primefac (talk) 13:53, 5 December 2020 (UTC)

native_name_2, etcetera

Currently, the template has

|native_name             = 
|native_name_lang        = <!-- ISO 639-1 code e.g. "fr" for French. If more than one, use {{lang}} instead -->

Would it make sense to add native_name_2, native_name_lang_2, and so on, making the template contents likely to be more structured, more predictable, potentially integrated with Wikidata, etc.

Are there instances where the use of {{lang}} is absolutely necessary? Could this usage be replaced and deprecated, or retained. —Michael Z. 16:10, 5 December 2020 (UTC)

Interesting question. I've thought about this for another template, too, a few months ago. I think, at least behind the scenes, this template should be using {{lang}} anyway, rather than manually constructing the markup. Whilst what you say felt like a good idea to me too, people often use language-specific templates (such as {{lang-fr}}), rather than filling in |native_name_lang=. This kind of usage does have an output difference. I've added to sandbox to demonstrate, see Template:Infobox_settlement/testcases#Case_19:_Nepali_native_name (first and second testcases). ProcrastinatingReader (talk) 16:23, 5 December 2020 (UTC)

Another use case might be where {{lang}} or {{transl}} is used to supply foreign-script name plus romanization. —Michael Z. 19:06, 5 December 2020 (UTC)

Purpose of area_magnitude= parameter?

In cleaning up pages with invalid inputs to formatnum (see Category:Pages with non-numeric formatnum arguments), I have come across pages using |area_magnitude= in this template. Examples are Cardiff and Washington, D.C. The parameter turns the settlement's area value into a link to Orders of magnitude (area), where there is a list of examples showing how big 10^n meters squared is. The links are all redirects, and they don't currently redirect to a useful section of the article.

I fail to see the utility of this parameter as currently configured, and it is not explained well in the documentation. If I were a reader, I would be confused as to why the linked phrase "54.2 sq mi" takes me to a page about SI units.

It is used in about 3,000 articles, according to the TemplateData monthly report. Can someone explain how this link is useful? I think we could get rid of it with no harm and a slight benefit in reduction of confusion. – Jonesey95 (talk) 00:32, 29 September 2020 (UTC)

Jonesey95, I support removal. If linking is desired it could be generated by the template, that could be implemented after a new discussion. As parameter it only leads to inconsistency: "3,000", per your claim, have it, and ~500,000 then don't. TerraCyprus (talk) 21:41, 5 October 2020 (UTC)

Agree with removal too. Unhelpful and unexplained link, especially now that all area orders of magnitude pages just redirect to the main page. -- P 1 9 9  ✉ 15:57, 11 November 2020 (UTC)

 Done. – Jonesey95 (talk) 23:31, 8 December 2020 (UTC)

Requesting addition of United Nation indices.

Hello, Martinez, Buenos Aires has a naked line that reads: "UN/LOCODE is ARMAR."

We are currently not systematically collecting these datums, I tried to silently add the parameter un_locode = ARMAR to the infobox, but the template complains that no such parameter exists, this is very useful to warn of spelling errors. The objective of the addition would be to simply add the parameter and not display it anywhere, such that we would be able to add the display code if enough users add it to settlements.

I believe this would be a pretty trivial and riskless change with some potential benefits. If someone with the knowledge and privileges to implement this change reads this, I would appreciate if you could implement it, I'd take the opportunity to revise the edit and start learning how templates work, in exchange I'm willing to seed the new parameter by cataloguing the cities listed in List_of_largest_cities#Common_city_definitions.

Thank you, Tomás --TZubiri (talk) 03:12, 12 December 2020 (UTC)

Name labels needed

This template has four fields for names, and each one may carry more than one name, in multiple languages, with romanized versions:

• name
• official_name
• native_name
• other_name

They get shown in the infobox, but no one knows what they are. For example, look at mish-mash of layouts in Ukrainian place articles, for example, Bilohirsk (Crimea) has four names in two fields, Ananyiv has four names in three different fields, Armiansk, Berdyansk, Bilyayivka, etcetera. Lots of names stuck in structured fields where they seemed to make sense to an editor, but the result conveys next to nothing.

At the very least, labels would let a reader understand which name is official, native, or whatever. Why no labels on these indistinguishable name* fields when the rest of the infobox makes it obvious that unlabelled data is useless? —Michael Z. 19:34, 5 November 2020 (UTC)

Those ones aren't really meant to have labels (similar params don't on other infoboxes either). When used totally properly, they usually don't need labels either, it looks good. The issue is more one of usage. Those labels are completely abused on many templates. Some of the examples you gave are abusing those params, repeating same info, using pretty much the same versions. What to do about issues like this I don't know. This infobox has so many issues it gives me a headache.

Like we do on the station infobox, some of these (like other name) could be pushed down into the regular fields, then it's not dominating at the top and misusage becomes more apparent. For native_name we could require native_name_lang, so we can force a display more like Armiansk. Then it's just a case of official_name which I don't think necessarily needs labelling. Tracking cats for more than 3 being used would likely spot many errors too. And with tracking data, we could get a better idea on how they're used, so we can have a more informed discussion on how we can reform these labels. ProcrastinatingReader (talk) 00:38, 10 November 2020 (UTC)

some of these (like other name) could be pushed down into the regular fields that would mean behavior different from the regular fields which are not splitt around to prevent them from being used too much. But one could move all names down one field and put the {{{settlement_type}}} in the first line. That would stop the weird separation of the name parameters from the transliteration parameters. TerraCyprus (talk) 01:41, 10 November 2020 (UTC)

| etymology, | nickname , | nicknames are already further down and after transliteration params. TerraCyprus (talk) 02:43, 10 November 2020 (UTC)

@Mzajac and ProcrastinatingReader: above I made an edit request related to this issue, native_name23 parameters from the sandbox so bi- and trilingual places can be better covered. TerraCyprus (talk) 00:18, 7 October 2020 (UTC) - still not enacted. TerraCyprus (talk) 00:09, 11 November 2020 (UTC)

ProcrastinatingReader, I have now checked the template documentation and adjusted the names in all of the above-linked articles as specified. It’s still useless and can’t possibly make any sense to anyone. Look at Ananyiv, for example. name is the article title. official_name is the official name in English, per the official romanization system. native_name is the name in the Ukrainian Cyrillic alphabet. The infobox has Ananyiv / Ананьїв / city / Ananiv at the top. No indication of which is which, or what these four lines represent. What is one to make of this without labels? Bilohirsk has three official names, one corresponding to the native name, but how is one to know what languages they are in, and why some appear twice? It is word salad, in nice neat boxes. —Michael Z. 03:15, 11 November 2020 (UTC)

@Mzajac and ProcrastinatingReader: updated [7] to better reflect the capabilities of the current template. Russian is native too, for Ukrainian I don't know. TerraCyprus (talk) 05:58, 11 November 2020 (UTC)

TerraCyprus, that’s not right because the template docs say official_name is the official name in English. (Also, Crimean Tatar and Ukrainian are official local languages under RF law. Also, you’ve entered an invalid language tag in native_name_lang; for multiples you have to insert {{lang}} for each.) —Michael Z. 14:42, 11 November 2020 (UTC)

@Mzajac: official_name in English ... that is weird. How could that be found if English is not an official language in that place? And what are the transliterations for then? TerraCyprus (talk) 03:05, 12 November 2020 (UTC)

Ukrainian place names have an official Latin-alphabet place name determined by the Ukrainian National System of romanization. As to Russian, I couldn’t determine which official Russian romanization is the right one for place names, but I think every single one renders this place as Belogorsk. Anyway, I’m not defending the guideline, just doing my best to follow it. —Michael Z. 03:57, 12 November 2020 (UTC)

Anyway, since this template is used on a half million pages, let’s follow its directions until we agree to change them. —Michael Z. 04:00, 12 November 2020 (UTC)

@Mzajac: Romanization doesn't make a name English. But probably UA gov is using it in English texts and so could be official and English, matching the doc. TerraCyprus (talk) 04:33, 12 November 2020 (UTC)

TerraCyprus, well, in this case it certainly makes it the official Latin-alphabet name and correct one to enter into official_name, but therefore also the default English name for nearly every place in Ukraine. These are the spellings approved by Ukrainian law, appearing on highway, transit, and street signs in Ukraine, entered into Ukraine’s authoritative geo-names database, and propagated from there to the UN, BGN/PCGN, IATA, Google maps, etcetera. Unless there’s a demonstrated more-popular traditional name, like Odessa, these are the names used in English and in Wikipedia (per WP:UAPLACE). —Michael Z. 17:08, 12 November 2020 (UTC)

I agree with the above sentiment. We expect regular readers to figure out what the various names represent with almost no context. I've also raised an issue a few sections above related to the how we handle the actual values. No matter what, the current method of handling these names is wrong both in style and in implementation. --Gonnym (talk) 06:05, 11 November 2020 (UTC)

@Mzajac and Gonnym: what do you think about having |name= first, as is done currently, but then have |settlement_type=. After that all the other names would be shown using labels. TerraCyprus (talk) 04:38, 12 November 2020 (UTC)

We should create a few style mockups to see what looks best. Looking at the current infobox, I think that maybe the best place to put these names is under the flag/seal section and above the Etymology section (which is strangely using a different label/value style than the rest of the infobox and just looks bad). --Gonnym (talk) 09:55, 12 November 2020 (UTC)

That might be a good approach. Isolates and emphasizes the article title/name value, and the infobox starts with what it’s called and what it is. —Michael Z. 00:05, 13 November 2020 (UTC)

@Mzajac, Gonnym, and ProcrastinatingReader: In sandbox names (except for top name), nicknames, transliteration, etymology in one infobox area and each with proper label [8] Bilohorsk added to Template:Infobox settlement/testcases. TerraCyprus (talk) 13:16, 13 November 2020 (UTC)

I think that is an improvement. Definitely much clearer what is what.

Just brainstorming, another approach that would also eliminate repetition and disjointedness might be ordered around languages or names rather than the subordinate data categories. I realize this might not be doable with the current data structure, but let’s consider a content organization like this, perhaps with accordion boxes to collapse/reveal details:

Names

• Ukrainian: Білогірськ (Bilohirsk) ▼

  Official in Ukraine and Russia

  Transcriptions: Bilohirsk (Ukrainian), Bilohirsʹk (ALA-LC, Scholarly), Bìlogìrsʹk (ISO 9)

  Etymology: “white mountains”

• Russian: Белогорск (Belogorsk) ▼

  Official in Russia

  Transcriptions: Belogorsk (ALA-LC, GOST, ISO 9, Scholarly)

  Etymology: “white mountains”

• Crimean Tatar: Karasubazar, Къарасувбазар (Kʺarasuvbazar) ▼

  Official in Russia

  Transcriptions: Kʺarasuvbazar (ALA-LC, GOST, ISO 9, Scholarly)

  Etymology: “bazaar on the Karasu River”

 —Michael Z. 16:13, 13 November 2020 (UTC)

@Mzajac: Request to apply the changes from the sandbox. TerraCyprus (talk) 22:52, 4 December 2020 (UTC)

Is there consensus for this? It seems like a regression to start using the word "Native" after it has been removed from many infoboxes. I can probably dig up the long conversation that led to the word "Native" being removed if someone does not have a link handy. – Jonesey95 (talk) 00:40, 5 December 2020 (UTC)

Native name discussions:

• VPP (November 2019)
• Infobox person (December 2019)

I think there were more. – Jonesey95 (talk) 00:53, 5 December 2020 (UTC)

The sandbox versions look good to me. Can we change the label “Native” to “Local”? I think that should be fine because the template docs define native name as “local name.” —Michael Z. 02:00, 5 December 2020 (UTC)

To be fair, the main argument in those discussions was due to BLP, and colonial issues as a sidenote. BLP doesn't really apply to places, as such, and we use |native_name= in various other infoboxes about things. It's meant to portray how the name is written in the native language. The local name (which sounds more like what it's colloquially referred to) may well be something else. ProcrastinatingReader (talk) 14:15, 5 December 2020 (UTC)

Well, “local name” can be interpreted as the local name or in the local language or dialect at any scale: local to North American English, local to francophone Quebec, local to the city of Montreal, local to the Outremont neighbourhood. It’s not identical, but I don’t see a conflict. Examples or counter-examples are welcome. “Native name” can mean any of these, but it can also be misinterpreted as Native = an outdated term for ”Aboriginal.” Yes, it is less urgent than in bios of living people, but yes it is also potentially misunderstood, potentially tone-deaf or mildly offensive. Or potentially very offensive in some context and to some persons we are unaware of—I’ll remind you we have a dozen articles about places called Pocahontas (disambiguation), all of which were inhabited by Indigenous peoples before receiving that name; the mind boggles.

We should consider changing it.

Since the template also collects native_name_lang, we could also make the label largely moot and even resolve the occasional problem of declaring which languages are judged “native” by making substituting the language name for the label. For example, Name: Iqaluit, Inuktitut: ᐃᖃᓗᐃᑦ, Other: Frobisher Bay. —Michael Z. 15:31, 5 December 2020 (UTC)

(Added the latter proposal as a sub-section below, since it is dependent on this change but optional.) —Michael Z. 16:39, 5 December 2020 (UTC)

Proposal: language name for “Native” label

Since the template collects both native_name (e.g. ᐃᖃᓗᐃᑦ) and native_name_lang (iu), it would improve the presentation and add information by changing Native ᐃᖃᓗᐃᑦ to Inuktitut ᐃᖃᓗᐃᑦ (example from Iqaluit, formerly Frobisher Bay). This incidentally moots any question of whether readers interpret native as meaning “local” or “Indigenous, Aboriginal, First Nations, Native American, Native Canadian,” etcetera.

Presumably the case where multiple languages are added with {{lang}} has no language code, and the default label can remain.

Is this technically possible? Is there any problem with existing data? —Michael Z. 15:54, 5 December 2020 (UTC)

This is a good idea! It somewhat ties in with what I discussed below regarding what language-specific lang templates do, eg {{lang-iu|ᐃᖃᓗᐃᑦ}} -> Inuktitut: ᐃᖃᓗᐃᑦ

I guess we just need a way to suck out the label-only from {{lang}} (haven't read docs, this is probably possible tho) ProcrastinatingReader (talk) 16:43, 5 December 2020 (UTC)

See module:Lang. —Michael Z. 17:15, 5 December 2020 (UTC)

And Module talk:Lang/testcases/ISO 639-1 name from tag. —Michael Z. 17:17, 5 December 2020 (UTC)

Neat. So something like {{#if:{{{native_name_lang|}}} | {{#invoke:Lang|name_from_tag|nocat=yes|{{{native_name_lang|}}}|link=yes}} }} ProcrastinatingReader (talk) 17:40, 5 December 2020 (UTC)

And something like else “Native”. —Michael Z. 18:55, 5 December 2020 (UTC)

Have added to sandbox & awaiting comments. There is a formatting bug (previewing Tokyo with sandbox v) with this change/TPER in general, though. I also think it's weird to move the data between images and map (slips past the eye), should be further down if going with this. However, I don't think the preview of Tokyo is better after vs before. Tricky issue, because when these params are used properly it looks good. So I'm not sure we should be removing that just because many don't use it properly. Just floating an idea, maybe only move it down if there's more than one being used? ProcrastinatingReader (talk) 19:21, 5 December 2020 (UTC)

Sorry, I can’t follow that. I don’t see Tokyo in the test cases, and I know what “previewing Tokyo with sandbox v” or “TPER in general” mean. —Michael Z. 18:00, 8 December 2020 (UTC)

Lazy writing, sorry. I mean go to the Tokyo article, and change the template call to /sandbox and preview it. (sandbox v being sandbox version; TPER in general meaning that Terra's request above is causing the break, not the native_name change itself, I think). ProcrastinatingReader (talk) 18:03, 8 December 2020 (UTC)

Got it. I guess sandbox has been reverted to live version since then? (Is there a way to call an old revision of a template?) —Michael Z. 19:06, 8 December 2020 (UTC)

Working for me now. Agreed, the layout is busy and confusing with the names between pictures. Moving up would associate names with the main name. Moving down would reinforce the table grid. Either an improvement on this. —Michael Z. 19:18, 8 December 2020 (UTC)

 Administrator note I have disabled the request as there doesn't seem to be consensus for any particular action at this point. Please reactivate if there is a clear request forthcoming — Martin (MSGJ · talk) 19:46, 12 December 2020 (UTC)