Template talk:Infobox settlement

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
WikiProject Geography (Rated Template-class)
WikiProject iconThis template is within the scope of WikiProject Geography, a collaborative effort to improve the coverage of geography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 Template  This template does not require a rating on the project's quality scale.
 
WikiProject Cities (Rated Template-class)
WikiProject iconThis template is within the scope of WikiProject Cities, a collaborative effort to improve the coverage of cities, towns and various other settlements on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 Template  This template does not require a rating on the project's quality scale.
 
WikiProject Infoboxes
This template is within the scope of WikiProject Infoboxes, a collaborative effort to improve the coverage of Infoboxes on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 

Template-protected edit request on 14 September 2018[edit]

Replace

{{Country abbreviation|{{{subdivision_name}}}|{{{subdivision_name1|{{{subdivision_name2|{{{subdivision_name3|}}}}}}}}} }}

with

{{ISO 3166 code|{{{subdivision_name}}}|{{{subdivision_name1|{{{subdivision_name2|{{{subdivision_name3|}}}}}}}}} }}

as it's 1) It's more complete then Template:Country abbreviation and 2) Template:Country abbreviation ends up using it if doesn't have the country and subdivision in the module (Module:Country extract). – BrandonXLF (t@lk) 19:15, 8 September 2018 (UTC)
Replace

 
|Coordinates{{#if:{{{coor_pinpoint|{{{coor_type|}}}}}}| ({{{coor_pinpoint|{{{coor_type|}}}}}})}}: {{#invoke:Coordinates|coordinsert|{{{coordinates|}}}|type:city{{#if:{{{population_total|}}}|{{#iferror:{{#expr:{{formatnum:{{{population_total}}}|R}}+1}}||({{formatnum:{{{population_total}}}|R}})}}}}|{{#if:{{{subdivision_name|}}}|region:{{Country abbreviation|{{{subdivision_name}}}|{{{subdivision_name1|{{{subdivision_name2|{{{subdivision_name3|}}}}}}}}} }} }} }}{{{coordinates_footnotes|}}} }}

With

|Coordinates{{#if:{{{coor_pinpoint|{{{coor_type|}}}}}}| ({{{coor_pinpoint|{{{coor_type|}}}}}})}}:{{#invoke:Coordinates|coordinsert|{{{coordinates|}}}|type:city{{#if:{{{population_total|}}}|{{#iferror:{{#expr:{{formatnum:{{{population_total}}}|R}}+1}}||({{formatnum:{{{population_total}}}|R}})}}}}|{{#if:{{{subdivision_name|}}}|{{#if:{{#invoke:Ustring|match|{{{coordinates|}}}|region:}}||{{#if:{{#invoke:ISO 3166|code|{{{subdivision_name}}}}}|region:{{delink|{{#if:{{#invoke:ISO 3166|code|{{{subdivision_name}}}|{{{subdivision_name1}}}|nocat=true}}|{{#invoke:ISO 3166|code|{{{subdivision_name}}}|{{{subdivision_name1}}}}}|{{#if:{{#invoke:ISO 3166|code|{{{subdivision_name}}}|{{{subdivision_name2}}}|nocat=true}}|{{#invoke:ISO 3166|code|{{{subdivision_name}}}|{{{subdivision_name2}}}}}|{{#if:{{#invoke:ISO 3166|code|{{{subdivision_name}}}|{{{subdivision_name3}}}|nocat=true}}|{{#invoke:ISO 3166|code|{{{subdivision_name}}}|{{{subdivision_name3}}}}}|{{#invoke:ISO 3166|code|{{{subdivision_name}}}}}}}}}}}}}}}}}}}}}{{{coordinates_footnotes|}}}}}

As

1) It allows the coordinate module to get the region parameter even when the first subdivision isn't recognized by ISO or even when all the subdivision aren't

An example can be seen at Template:Infobox settlement/testcases#Case 8: Toronto Were the first region isn't ISO so it uses the second region (Ontario) instead, whereas the live version doesn't make any region for the coordinates.

2) It prevent the code from running when the region is already specified to improve efficiency.

Adds {{#if:{{#invoke:Ustring|match|{{{coordinates|}}}|region:}}||''code''}}

3) It uses the module instead of templates to improve load time and efficiency.

{{Country abbreviation}} vs {{#invoke:ISO 3166|code}} (Template:Country abbreviation vs Module:ISO 3166)

You can see the test cases at Template:Infobox settlement/testcases and my edits at Template:Infobox settlement/sandbox and the differences between the live and sandbox version at diff. – BrandonXLF (t@lk) 21:43, 14 September 2018 (UTC)

Please link the templates so each person who views this doesn't need to hunt around. Is the proposed change in the sandbox? What tests have been performed? Johnuniq (talk) 00:35, 9 September 2018 (UTC)
@Johnuniq: I added a new link to make navigation easier, I show example in the sandbox, and I ran the test cases and they new edit passes, I should note that the current method may be broken when in some countries and sub-pages the current method relied on have been deleted, and more may be deleted soon, so we should transition to ISO 3166 templates (such as Template:ISO 3166 code as they are more reliable. – BrandonXLF (t@lk) 04:42, 9 September 2018 (UTC)
BrandonXLF would it be possible for Template:ISO 3166 code to try to parse more than one pair, using the first valid pair? for example, {{ISO 3166 code|{{{subdivision_name}}}|{{{subdivision_name1|}}}|{{{subdivision_name2|}}}|{{{subdivision_name3|}}}}}? I ask because, articles like Ahdid would be able to get the correct ISO code in that case. also, as far as I can tell, this region information is only used if the associated {{coord}} doesn't have region information. would it be possible to have the "coord insert" call the "ISO 3166 module" instead, but only when necessary? Frietjes (talk) 19:47, 10 September 2018 (UTC)
@Frietjes: Template:ISO 3166 code takes as many sub divisions as Template:Country abbreviation, for the rest I'll see what I can do. – BrandonXLF (t@lk) 19:51, 10 September 2018 (UTC)
@Frietjes: I made it so it always shows the region, if you want, I can make it so it only shows the region when It doesn't show the coordinates. Theres some good example at Template:Infobox_settlement/testcases. I also made it use the first valid pair and use Module:ISO 3166. All that changes are in the sandbox and the diff can be seen here. – BrandonXLF (t@lk) 00:48, 11 September 2018 (UTC)
User:BrandonXLF, there appears to be more in that diff. in any event, I still think that we should pass the country and subdivisions to "coordinsert" and have it call the various modules only if there is no region in the corresponding {{coord}}. Frietjes (talk) 15:28, 11 September 2018 (UTC)
@Frietjes: Coordinsert doesn't need that information, how is it now? It only shows the region information when there's no coordinates. I think it better to always show the region information, but this way is fine. – BrandonXLF (t@lk) 19:57, 11 September 2018 (UTC)

───────────────────────── User:BrandonXLF, let's start by looking at the call to coordinsert in this template: {{#invoke:Coordinates|coordinsert|{{{coordinates|}}}|type:city{{#if:{{{population_total|}}}|{{#iferror:{{#expr:{{formatnum:{{{population_total}}}|R}}+1}}||({{formatnum:{{{population_total}}}|R}})}}}}|{{#if:{{{subdivision_name|}}}|region:{{Country abbreviation|{{{subdivision_name}}}|{{{subdivision_name1|{{{subdivision_name2|{{{subdivision_name3|}}}}}}}}} }} }} }}. this passes (1) the coordinates template, (2) a type: value augmented with population information (3) region: information derived from {{country abbreviation}} using subdivision information. now, let's look at what coordinsert does with this information by inspecting Module:Coordinates. that module function appends this type: and region: values to the coord parameters, but only if they are not already specified. to see how this works, try the following examples to see what you get for output:

{{Infobox settlement
| name = Example 1
| subdivision_type        = [[Country]]
| subdivision_name        = [[Netherlands]]
| subdivision_type1       = [[Provinces of the Netherlands|Province]]
| subdivision_name1       = [[North Holland]]
| coordinates             = {{coord|52|22|N|4|54|E|region:NL_type:city}}
| population_total        = 851,573
}}
{{Infobox settlement
| name = Example 2
| subdivision_type        = [[Country]]
| subdivision_name        = [[Netherlands]]
| subdivision_type1       = [[Provinces of the Netherlands|Province]]
| subdivision_name1       = [[North Holland]]
| coordinates             = {{coord|52|22|N|4|54|E}}
| population_total        = 851,573
}}

in the first case, the coord URL has the parameters region:NL_type:city, but in the second case, the coord URL has the parameters type:city(851573)_region:NL-NH. so, in the first case we didn't need the information provided by {{country abbreviation}}, but we tried to calculate it anyway. to circumvent this inefficiency, we just need a way to call a "coordinsert" type function with country/subdivision information and have that the coordinsert call the {{country abbreviation}}. Frietjes (talk) 20:23, 11 September 2018 (UTC)

@Frietjes:How's that? It should only run when needed (when coordinates are specified and region: is not). – BrandonXLF (t@lk) 02:24, 12 September 2018 (UTC)
yes. Frietjes (talk) 12:16, 12 September 2018 (UTC)
@Frietjes: Just a little more work. – BrandonXLF (t@lk) 12:24, 12 September 2018 (UTC)
@Frietjes: How does it look now? I think it's good. – BrandonXLF (t@lk) 20:11, 14 September 2018 (UTC)
These edits can be seen at work in Case 8: Toronto where currently the region doesn't work but in the sandbox it uses the first ISO region Ontario. – BrandonXLF (t@lk) 20:23, 14 September 2018 (UTC)
since this feature is going to be used more than once, it would be better to put this directly into a "coordinsert" function, probably in Module:ISO 3166, since the "coordinsert" code is fairly small. Frietjes (talk) 14:06, 15 September 2018 (UTC)
@Frietjes: So add a function to Module:ISO 3166 that finds the first proper subdivision? – BrandonXLF (t@lk) 19:05, 15 September 2018 (UTC)
There is a fair amount of discussion about the proposed change. Just to keep TPER clean, I'm closing this, but feel free to a) continue the above discussion, and b) re-open the request if necessary. Primefac (talk) 20:49, 15 September 2018 (UTC)
The code is ready to be implemented. – BrandonXLF (t@lk) 02:22, 16 September 2018 (UTC)
the code in the sandbox is not the solution, eight calls to the same module means there should be a separate entry point into Module:ISO 3166 to do everything. also, Module:ISO 3166 uses "getArgs" which means it is processing all the args passed to infobox settlement, and not just the ones which are explicitly being passed. Frietjes (talk) 14:52, 16 September 2018 (UTC)
this change looks better to me, and appears to work as intended, but without multiple calls to the various modules and templates. comments? Frietjes (talk) 16:46, 16 September 2018 (UTC)
@Frietjes: It looks good, but I wonder if it belongs in Module:ISO 3166 maybe having it Module:Coordinates would be better? – BrandonXLF (t@lk) 19:15, 16 September 2018 (UTC)
Or rename the function to findcode as it could be used in situations were users don't know the proper subdivision name so they can but in a variety. – BrandonXLF (t@lk) 19:18, 16 September 2018 (UTC)
It looks good to me, and I think the placement in Module:ISO 3166 makes sense since it's calling the functions in Module:ISO 3166 multiple times. It looks like it only calls Module:Coordinates once at the end. Plastikspork ―Œ(talk) 00:24, 17 September 2018 (UTC)
@Plastikspork: But it doesn't have anything to do with ISO 3166. – BrandonXLF (t@lk) 12:23, 17 September 2018 (UTC)
it adds the ISO code for a region to the coordinates call. Frietjes (talk) 13:12, 17 September 2018 (UTC)
I have updated the main template; we can always move it to a different module if necessary. Frietjes (talk) 20:21, 18 September 2018 (UTC)

Proposed addition to Infobox settlement: telephone exchange[edit]

Infobox settlement already contains very useful parameters for a settlement's postal code(s) and area code(s). Another attribute that many settlements have is one or more telephone exchange numbers. It would be quite useful to add a parameter for the telephone exchange to this infobox.

An exchange is a quite reliable way to identify the location of a telephone landline, and the place of registration of a cell phone number.

In case you're not familiar with how telephone exchanges work in the U.S., here are two examples:

  • In the phone number (208) 879-5555, the three-digit exchange number 879 identifies the location as Challis, Idaho. It would be nice to be able to put the following in Challis' infobox:
| area_code = 208
| exchange = 879
Most Idaho exchanges can be found here: Area_codes_208_and_986#List_of_exchanges
  • In the phone number (605) 280-5555, the three-digit exchange number 280 identifies the location as Pierre, South Dakota. It would be nice to be able to put the following in Pierre's infobox:
| area_code = 605
| exchange = 224, 945, 280, 295, 222
South Dakota exchanges can be found here: Area_code_605

Implementing this addition[edit]

I don't know how to add an additional parameter to an infobox. Could someone assist me with this? GPS Pilot (talk) 19:41, 10 October 2018 (UTC)

First you would need to gain consensus. I doubt that will happen. The exchange is an archaic bit of information of little use in today's society. Phone numbers have been portable for several years now. I could move from Challis to Boise and retain the same phone number. Further, the exchange only applies to phone service from the franchised landline provider in the community. If you get phone service from an alternative phone provider, it will not have that exchange. Nor do the vast majority of cellphones. A phone number is 7 digits, not 4 + an exchange. That concept died a long time ago. Not to mention that this infobox is used in most settlement articles, and most settlements are not in the US. John from Idegon (talk) 20:06, 10 October 2018 (UTC)
Don't start a war. --Redrose64 🌹 (talk) 20:36, 10 October 2018 (UTC)
Nice, Redrose64. The Simpsons rule forever.
The exchange is an archaic bit of information of little use in today's society
Not correct. Every U.S. phone number, landline or cell phone, has an exchange as well as an area code. The exchange is no more archaic than the area code.
Even if it were true that cell phones don't use exchanges (it is not), please note that a 2017 Center for Disease Control National Health Information Survey found that 45.9% of American households still use a landline phone. Schools, businesses, libraries, police stations, etc. also will remain heavy users of landlines for the foreseeable future. So information about a settlement's landline exchange(s) will remain quite relevant for some time to come.
Phone numbers have been portable for several years now. I could move from Challis to Boise and retain the same phone number.
Correct, which is why I wrote that the exchange allows you to identify "the place of registration of a cell phone number."
the exchange only applies to phone service from the franchised landline provider in the community. If you get phone service from an alternative phone provider, it will not have that exchange. Nor do the vast majority of cellphones. A phone number is 7 digits, not 4 + an exchange. That concept died a long time ago.
That is not correct. I have multiple cell phone numbers, and in all of them, the exchange identifies the city in which I registered the cell phone. For example, I bought one phone near Milton, PA, and the exchange in its phone number is 412. If you go here, you can see that 412 is an exchange reserved by Sprint Spectrum L.P. for phones registered in or near Milton, PA. No landline has ever been assigned to exchange 412 in area code 570.
Many phone systems in the U.S. require you to dial 10 digits, even when calling within the same area code, and even where there is no area code overlay plan in place, because they do not consider the seven-digit number to a complete phone number. If you believe the exchange concept died a long time ago (in fact it has not died at all), then please make a correction to North_American_Numbering_Plan#Modern_plan, which says "for example, 234-235-5678 is a valid telephone number with area code 234, central office prefix (exchange) 235, and line number 5678."
this infobox is used in most settlement articles, and most settlements are not in the US.
Correct. That is why the infobox contains a parameter named "postal_code," not "zip_code". You don't seem to know much about telephone exchanges. Other countries use them too, but they are not always three digits as in the U.S. For example, I recently visited the small village of Taynuilt, Scotland, where the area code is 01866 and the exchange is 822.
Even if some of the points I've made were incorrect, which they are not, there would be no harm in adding an optional parameter, which no one is forced to use, to an infobox. Compare and contrast the usefulness of the proposed parameter with some of the parameters currently in Infobox settlement:
flag - Minimally useful, because most settlements do not have their own flag
anthem - Not useful; even fewer have their own anthem
established_title7 - This would be used for a settlement that has had six former names. I bet you can't name a single settlement that needs this parameter.
exchange - Extremely useful; every single community in the U.S. (and many other countries) has one or more telephone exchanges.
GPS Pilot (talk) 22:44, 10 October 2018 (UTC)

If land line ONLY, then yes/maybe. If cellphone, then no because there are numerous exchanges for cellphones. This is more useful for a smaller community, because large cities have a mountain of exchanges, and I don't want the infobox to be flooded with numerous exchanges. • SbmeirowTalk • 02:49, 11 October 2018 (UTC)

The term "exchange" dates back to the original direct dial telephone systems installed (in the US anyway) in the 50s and 60s, when a physical pair of wires ran from each customer's phone to a centrally located building, where they were connected to a gigantic mechanical switch (the exchange) which moved in sequence in response to the electric impulses generatated by the generator attached to the dial of the telephone to physically connect the two parties to the call. They were limited not by geographic boundaries, but by their 10,000 customer capacity. For smaller communities, many of the numbers were, and still are, outside the corporate boundries of the city. So, now, not every phone in the community has the same exchange (or even 15 exchanges. Every cell carrier is assigned a batch of exchanges for a given area code, so it's quite possible for even a small community to have many assigned exchanges), AND not every number in a given exchange is in a given community. How is this information relevant to a community? It's just a piece of marginally useful trivia that will end up being a maintenance nightmare. John from Idegon (talk) 04:13, 11 October 2018 (UTC)
My hometown has only one exchange, which has remained unchanged for over 50 years. That is hardly a "maintenance nightmare." On the other hand, my hometown (and thousands of other communities) have experienced a change of area code. I'm not going to resort to your kind of hyperbole and say that the area_code parameter is a maintenance nightmare, but it certainly demands much more maintenance than the proposed exchange parameter – which, I would remind everyone, would be entirely optional. An editor who is frightened that their settlement's exchange might change 20 years from now is not obligated to populate the proposed parameter. I plan to populate the parameter on pages I edit, but I won't take offense if it goes unpopulated in 99% of these infoboxes. A 1% usage rate would make it more popular than many of the existing parameters (see flag, anthem, and established_title7 above). I really don't understand why this very useful proposed parameter is meeting resistance, when nobody opposed the numerous completely useless parameters that are currently found in Infobox settlement.
The term "exchange" dates back to the original direct dial telephone systems installed (in the US anyway) in the 50s and 60s, when a physical pair of wires ran from each customer's phone to a centrally located building, where they were connected to a gigantic mechanical switch (the exchange) which moved in sequence in response to the electric impulses generatated by the generator attached to the dial of the telephone to physically connect the two parties to the call.
Correct. And in the 21st century, the term lives on, having acquired the additional meaning of a block of phone numbers allocated to cell phones that are registered in or near a particular community. Similarly, these days the term "mouse" can refer to something that contains a laser and a Bluetooth transmitter. The fact that the term dates back to a small rodent does not warrant the deletion of this article.
How is this information relevant to a community? It's just a piece of marginally useful trivia
Not correct. In the community where I grew up, the telephone exchange was an integral part of the community's identity (and remains so to this day). Now in my opinion, the fact that De Soto, Kansas is 1.2% covered with water is useless trivia – and apparently those who built the infobox agree, because they didn't make use of the area_water_percent parameter. But you don't see me speaking out against the area_water_percent parameter. Be a mensch.
now, not every phone in the community has the same exchange
Correct; as I pointed out in the above example, Pierre, SD has five exchanges. It's also true that in many communities, not every phone in the community has the same area code. And yet, I don't see anyone clamoring for abolishment of the area_code parameter. So what is your point?
large cities have a mountain of exchanges, and I don't want the infobox to be flooded with numerous exchanges
Not a problem, my friend. Exchanges 201 through 997 are assigned to Washington, DC. If you wanted to print pages 23-28 of a document, you wouldn't specify pages 23, 24, 25, 26, 27, 28 in the print dialog box; you would specify pages 23-28. Similarly, the Washington, DC exchanges can be concisely listed as 201-997.
GPS Pilot (talk) 05:32, 12 October 2018 (UTC)

Edit request to native_name[edit]

I'd like to extend the (approved) proposal to unbold |native_name= as done with {{Infobox country}} (see talk) to this template as well for consistency. Thayts ••• 19:27, 11 October 2018 (UTC)

 Done Primefac (talk) 14:39, 14 October 2018 (UTC)

Short description needs settlement_type canonicalized[edit]

At present, {{Infobox Italian comune}} sets settlement_type by default to {{lang|it|[[Comune]]}}, which gives a correct result in the infobox itself. However this results in two problems in the generation of the short description. The major problem is that the {{lang}} template hides the argument, so the short description of (say) Ostuni is "in Apulia, Italy". The second is that the wikilink would end up in the short description, where it doesn't belong. The same issue probably occurs in other customers of this template. Is it possible to canonicalize these bits of syntax out of the parameter when it is used to generate the default description? David Brooks (talk) 01:15, 24 October 2018 (UTC)

Update: I realize that one solution would be for the Italian comune infobox to construct an explicit short_description parameter. I can do that, but I think if the Infobox settlement template code can strip out the lang template (is that technically possible?), it would be a more robust solution, applicable to any other settlement infobox with similar coding. Can anyone comment on the feasibility? David Brooks (talk) 16:09, 26 October 2018 (UTC)
I think stripping out the lang template would be a bit difficult. Galobtter (pingó mió) 16:16, 26 October 2018 (UTC)

autolinking the subdivisions[edit]

So I recently made a change to the template that would {{autolink}} the subdivisions. JJMC89 reverted the change citing that it "will cause WP:OVERLINKing." However, upon reviewing the WP:MOSLINK documentation, I feel pretty confident that this falls under one of the exceptions. Per MOS:REPEATLINK Generally, a link should appear only once in an article, but if helpful for readers, a link may be repeated in infoboxes, tables, image captions, footnotes, hatnotes, and at the first occurrence after the lead. So, per BRD I'd like to discuss. Personally, I think this would be a helpful change. Frankly the more that is clickable in the infobox the better, but that is just my 2 cents. --Zackmann (Talk to me/What I been doing) 04:55, 30 October 2018 (UTC)

The revert wasn't about repeating links but linking locations that shouldn't be linked. WP:OVERLINK: the following are not usually linked: [...] The names of subjects with which most readers will be at least somewhat familiar—unless there is a contextually important reason to link: [...] locations (e.g., United States; New York City, or just New York if the city context is already clear; London, if the context rules out London, Ontario; Japan; Brazil; Southeast Asia) — JJMC89(T·C) 05:48, 30 October 2018 (UTC)
@JJMC89: ah gotcha! Thanks for the follow up and explanation. --Zackmann (Talk to me/What I been doing) 06:13, 30 October 2018 (UTC)
@Zackmann08: There's also the problem that autolinking could generate a link to a disambiguation page, and the page editor would not realize it and no one else could fix it. We discussed this at the Infobox mountain talk page. This is one example where the author of Geobox created a feature without discussing it with anyone, it turned out to be a bad idea, and no one could fix the original tangled Geobox code. Let's not maintain the bad old features of Geobox. —hike395 (talk) 09:12, 30 October 2018 (UTC)
@Hike395 and JJMC89: look at that... BRD is working as intended! :-) You both made excellent points that I had overlooked. Much appreciated! I now agree auto-linking is not the way to go. --Zackmann (Talk to me/What I been doing) 16:31, 30 October 2018 (UTC)

Add support for an embedded infobox[edit]

Can we add a param at the bottom such as {{{module}}} or {{{embed}}} that would allow for embedding another infobox into this one? I'm looking at French Quarter specifically at the moment... --Zackmann (Talk to me/What I been doing) 01:13, 31 October 2018 (UTC)

Zackmann08 the standard method that I have seen is to embed it in the |footnotes=. the main downside of embedding any infoboxes in this one is that this one uses the geography class, so you get some extra horizontal dividers in the child that you may not have expected. Frietjes (talk) 12:34, 31 October 2018 (UTC)
@Frietjes: gotcha. Thanks for the note! --Zackmann (Talk to me/What I been doing) 16:30, 31 October 2018 (UTC)

No defaults?[edit]

Sorry to keep bugging people! I'm doing a lot of conversions from {{Geobox}} to this template and keep noticing stuff. Per the threads above, I just want to make sure I'm not missing something before I make a change. So the note this time... I'm seeing a number of parameters that don't have a default for their label. For example, {{{postal_code}}} and {{{postal_code_type}}}. There is no default for {{{postal_code_type}}} in the template. So if you provide a postal_code but not a type the code isn't displayed at all. Obviously having the type is important, but I'm curious why there isn't a default? Same for {{{established_title}}} and {{{established_date}}}. --Zackmann (Talk to me/What I been doing) 22:50, 31 October 2018 (UTC)

TfD notice[edit]

Could someone revert the addition of the TfD notice [1]? The "merge" advertised is actually a proposal to deprecate {{Geobox}} in favour of this template and has absolutely no bearing on what happens to this template. We don't need an irrelevant TfD notices being plastered on top of almost half a million articles. – Uanfala (talk) 19:33, 3 November 2018 (UTC)

Well, that was fast! – Uanfala (talk) 19:35, 3 November 2018 (UTC)

Overriding short description in calling infobox and articles[edit]

Recalling my request above (#Short description needs settlement_type canonicalized) where the problem was a settlement_type that includes {{lang}}: I finessed the issue by adding to {{Infobox Italian comune}}:

| short_description       = {{{short_description|Comune in {{#if:{{{region|}}}|{{{region}}}, Italy|Italy}}}}}

(I realized afterwards I could have used an HTML space or nbsp entity to avoid repeating the word "Italy"). That works as far as it goes. I haven't documented the new parameter because I was trying to solve this problem: if an editor adds a local short description to the article using {{short description}} or SHORTDESC, it gets prepended to the generic one. I frankly can't quite follow the meanings of parameters like "none", "no", and "noreplace", but I can't find a way to make the generic description go away if an editor provides a local one. Of course, the editor will use the new template parameter if they notice it. Is there a more foolproof coding that would force the local description to replace the generic one, or is the template parameter the best way? I may be fussing over nothing: currently none of the 8,023 articles that use this template provides another SD. But I'd like to get it right before moving on the description, and changing the similar issues in {{Infobox frazione}} and others. David Brooks (talk) 19:13, 8 November 2018 (UTC)

Because the short description in {{Infobox settlement}} is passed the parameter "noreplace", any other short description is used as the actual description displayed instead of the automatic one generated by {{Infobox settlement}} or through {{Infobox Italian comune}}; however, the display through CSS will still show two descriptions (one can see the actual description used through User:Galobtter/Shortdesc helper :)). Galobtter (pingó mió) 19:28, 8 November 2018 (UTC)
@Galobtter: OK, I'll document that an editor can safely use either route. I'm unsure whether to mention the possibility of CSS confusion; few people will see it after all. And thanks for reminding me to import your script. David Brooks (talk) 21:33, 9 November 2018 (UTC)

Moving maps, flags, and seals further down[edit]

As part of the conversion of {{Geobox}} to {{Infobox settlement}}, pointed out that Geobox looks better than the current version of {{Infobox settlement}}, because it avoids bunching up all of the images at the top of the infobox. Geobox puts the maps at the bottom of the infobox.

I agree with Ɱ's assessment of the bunching issue. Too many visual elements together makes the infobox more difficult to interpret. We ran into this problem at {{Infobox mountain}}. In order to fix this issue, we put the photograph at the top of the infobox and the map in the middle; unless there only a map and no photo, in which case the map is at the top. Thanks to Frietjes, there is a simple trick to implement this.

I've created a new version of {{Infobox settlement}} in a sandbox. What I've done is order the images into three priorities:

  1. |image_skyline=, a photograph of the settlement
  2. |pushpin_map= or |image_map=, the map showing the location of the settlement
  3. |image_flag=, |image_seal=, |image_shield=, etc., small images related to the settlement

The highest priority image that exists is shown at the top of the infobox. The others are shown in the middle of the infobox, below the high-priority tabular data (such as country, population, etc.), but above the lower-priority data such as ZIP code, time zone, or website. In addition, data that is associated with each of these images (such as captions, coordinates, mottos, nicknames) are kept with the images (either top or middle).

To visualize the change, please look at the testcases: the current infobox is on the left, the proposed infobox is on the right. The sandbox version is tested and ready-to-go: I would like feedback and consensus on the change before making it live on WP.

For other editors:

  • Do you think we should unbunch the images in the infobox?
  • Does the order of elements in the proposed infobox look good to you?
  • Any other comments?

Pinging Zackmann08 and WOSlinker who were involved in the discussion at Talk:Briarcliff Manor, New York. —hike395 (talk) 21:50, 11 November 2018 (UTC)

Comments[edit]

keep as is First off, thanks for taking the time to put this comparison together and getting the thread started! Bravo. One thing I would suggest is that when we discuss this, don't think of it as "Geobox vs Infobox - which one is better". Think of it as "Can we improve the Infobox". I'm not accusing anyone of anything here. I'm just saying that there has been a lot of confrontation about which template is better. Let's make sure we set that aside and look at what improvements can be made to this template independent of the geobox.
My personal opinion is that the sandbox format actually looks worse than the way the template currently renders. I feel that the new format makes the Infobox more cumbersome to read and prefer having all the images in one place. That being said, I'm known to be persuaded to change my mind and am very curious to hear what others have to say on the matter. --Zackmann (Talk to me/What I been doing) 23:41, 11 November 2018 (UTC)
@Zackmann08: I only brought up {{Geobox}} to explain the motivation of the edit.
To me, the original purpose of the infobox is to display tabular data (population, area, etc.). Having a photograph, a map, a flag, and a symbol be at the top of the infobox pushes all of the tabular data far down the page, which defeats the purpose of the infobox. I like the compromise that we reached at {{Infobox mountain}}, where we selected one image to be at the top, then important tabular data, then more images. That's what I've tried to implement here. —hike395 (talk) 09:48, 12 November 2018 (UTC)
@Hike395: the comment about Geobox was NOT directed at you! That was honestly directed largely towards myself. There has been so much confrontation with that template that I didn't want the frustration there to spill over into what I feel is a necessary discussion about improvements to this template. I have a different take on how to structure the layout of this template, but am both willing and eager to have a constructive conversation about it. :-) --Zackmann (Talk to me/What I been doing) 18:52, 12 November 2018 (UTC)
  • Unbunch; the logic makes sense. It reads a lot better, looks a lot better, and has the more important facts first. I don't know why it's taken so long for this template to get this, but I believe many other infoboxes function this way, including all articles on rivers. If people don't like it displayed this way, we can make this the default and allow the other display option, or vice versa. It shouldn't really matter. ɱ (talk) · vbm · coi) 03:10, 13 November 2018 (UTC)
  • keep as is because according to In order to fix this issue, we put the photograph at the top of the infobox and the map in the middle; unless there only a map and no photo, in which case the map is at the top. the position of the map would depend on the existence of a photo. The order should always be the same. 77.13.146.241 (talk) 04:12, 18 February 2019 (UTC)

Another infobox within this infobox?[edit]

I was wondering if there is any way to put an infobox like {{Infobox Chinese}} inside {{Infobox settlement}} down near the bottom? I played around putting it in "blank_name_sec1"/"blank_info_sec1" but the formatting is off. Are there technical or other reasons this should not be done? An example where both templates are in use that might look better combined is here. —  AjaxSmack  02:55, 12 November 2018 (UTC)

@AjaxSmack: can you provide some source code for what you are trying to do? Happy to help. --Zackmann (Talk to me/What I been doing) 07:26, 12 November 2018 (UTC)
the supported method is using the transcription parameters, which I agree is sub-optional, since it requires exactly typing out all the labels. the embedding method shown here, is better, but has some spurious horizontal lines. I believe we can improve the format of the embedding method. let me see what we can do. Frietjes (talk) 14:21, 12 November 2018 (UTC)
this works as well. some spurious horizontal lines which could be removed by adding |rowclassN=mergedrow to {{Infobox Chinese/Chinese}}, but I don't think you can remove all of them without changes to this template. Frietjes (talk) 14:48, 12 November 2018 (UTC)
Thanks for your help. Your second iteration (with placement at the bottom of the infobox) looks best. Where would I add |rowclassN=mergedrow to {{Infobox Chinese/Chinese}} and what syntax would I use in the embedded template?  AjaxSmack  01:29, 13 November 2018 (UTC)
AjaxSmack, you would need to add |rowclass2=mergedtoprow for the first row after the header, |rowclass3=mergedrow for the second row, |rowclass4=mergedrow for the third row, etc.. very tedious. it's possible we could put |classN=maptable in a cell in this template or maybe to the first data cell in {{Infobox Chinese}}. by my reading of MediaWiki:Common.css, this would remove the horizontal borders, but possibly not all of them. will require some testing. Frietjes (talk) 13:31, 13 November 2018 (UTC)

Discussion of motto parameter changes in sandbox[edit]

I see that a new parameter called |motto_single= has been added in the sandbox, to indicate whether the settlement's motto/mottoes should be displayed with the heading "Motto" or "Motto(s)". There are a number of problems with this approach:

1. It has been our experience over at {{Infobox school}} and {{Infobox UK school}} that editors do not understand the nuances of how to use |motto_single= (or in the school infoboxes' case, |motto_pl=). They put all sorts of text in that parameter, and they don't get what they intend. I strongly recommend the use of |mottoes= instead. See the Infobox school label code for how it works. Editors are much more likely to get the results they want with a more obvious parameter name.

2. If you want a plural of "motto", the word is "mottoes", as far as I know. Certainly not "motto(s)".

Just trying to avoid having a mess a few years down the road. – Jonesey95 (talk) 05:56, 15 November 2018 (UTC)

@Jonesey95: this was something that required to be added to the template before he would allow it to be used on Briarcliff Manor, New York. That is why it was added. --Zackmann (Talk to me/What I been doing) 06:03, 15 November 2018 (UTC)
@Jonesey95: also it wasn't just on the sandbox but was added to the main template. I just reverted it. --Zackmann (Talk to me/What I been doing) 06:05, 15 November 2018 (UTC)
"Mottos" is correct. Nikkimaria (talk) 23:55, 15 November 2018 (UTC)
English is hard. Sometimes it's dumb too. --Izno (talk) 00:20, 16 November 2018 (UTC)
Either "Mottoes" or "Mottos" is fine with me, but "Motto(s)" is not correct when a plural has been explicitly requested. – Jonesey95 (talk) 05:21, 16 November 2018 (UTC)

─────── I agree with Jonesey95's point that we should choose the label depending on whether |nickname= or |nicknames= is supplied. However, the current situation is a mess. Parameters like |nickname= or |motto= are used on thousands of pages. Editors have already supplied comma-separated lists to these parameters. Zackmann08 has offered to run a bot over all of these pages to do an automatic conversion. However, an automated conversion is not going to be easy. It's tough to automatically distinguish between a name with a comma in it ("Mack, the Knife") from a comma-separated list (Mack, Joe, The Knife).

Take a look at the sandbox and testcases for a partial solution. I've enabled both |nickname= and |nicknames=. If |nickname= has a comma in it, I use the current ambiguous label "Nickname(s):". If it doesn't have a comma in it, we can be reasonably sure it is not a list, so I use "Nickname:". If an editor decides to use |nicknames=, I use "Nicknames:".

I've done this for all parameters that previously had "(s)" in their labels: |nicknames=, |mottoes=, |population_demonyms=, |area_codes=.

Feedback welcome before I promote to the main template. Pinging Frietjes, hike395 (talk) 13:48, 16 November 2018 (UTC)

hike395, I appreciate the hard work on {{detect singular}}, but I would rather do something less complicated. I would suggest that we just make |nickname= → Nickname: and |nicknames= → Nicknames, and use the {{detect singular}} for generating entries in a tracking category. this would also allow us to expand the tracking for lists (e.g., {{ubl}}, {{plainlist}}, {{hlist}}, {{flatlist}}), as well as <br />. I don't think it's the end of the world if a list of nicknames is labelled as Nickname: so long as there is a path to fix it. Frietjes (talk) 14:01, 16 November 2018 (UTC)
We can use both "Nickname(s)" and a tracking category, going back and fixing articles that are tracked. It's not really any more or less difficult than the current proposal. The nice thing about using "Nickname(s)" is:
  • It's the current behavior, so we are making the smallest change.
  • It's not incorrect.
hike395 (talk) 15:37, 16 November 2018 (UTC)
Point of clarification, I have offered to write a bot and file a WP:BRFA. Just want to be clear that I'm not just going to unleash a bot a my own free will. :-) --Zackmann (Talk to me/What I been doing) 17:20, 16 November 2018 (UTC)
I just updated {{Detect singular}} to detect list templates and br, and also updated the infobox to use tracking categories, per Frietjes. Any other comments? —hike395 (talk) 06:26, 18 November 2018 (UTC)
Deploying this brand new template ({{detect singular}}) in an infobox that is transcluded hundreds of thousands of times is not a good idea until extensive testing has been done. Like Frietjes, I think that if detect singular is used in production, it should be used only to generate a hidden tracking category, not to render the infobox.
I appreciate all of the attempts at tricky parsing, because I too am a geek, but infoboxes in articles are typically edited by editors, not by programmers, and editors do not think like programmers. Just give editors two parameters to choose from: |nickname= → Nickname and |nicknames= → Nicknames. They will be much more likely to do the right thing. – Jonesey95 (talk) 19:33, 18 November 2018 (UTC)
I could not possibly have said this any better than Jonesey95. I agree with 100% of what you said. I'm a geek too!!! :-p Hike395 great work but not sure it is the best approach to the problem. --Zackmann (Talk to me/What I been doing) 19:47, 18 November 2018 (UTC)

──────────── @Jonesey95, Frietjes, Zackmann08, and : To make it clear: if we have |nickname= produce "Nickname:", hundreds or thousands of infoboxes will look strange (i.e., have a singular label with a list of items) until we clean them up. Is that worse than using {{Detect singular}} to leave some of them in the current state of producing "Nickname(s):" ? I claim it is worse. But everyone else seems to feel otherwise.

I will defer to the opinion of the other editors and not have {{Detect singular}} produce visible markup, but I think it will make the encyclopedia worse. I'm now reluctant to make this change at all. —hike395 (talk) 20:42, 18 November 2018 (UTC)

Later: I have a better idea that will not make things worse:

  1. For now, have |nickname= continue to generate "Nickname(s):"
  2. Use {{Detect singular}} find lists when |nickname= is used via a tracking category.
  3. Convert all appropriate articles in the tracking category to use |nicknames= to produce "Nicknames:", using AWB because of possible false positives.
  4. After conversion, finally have |nickname= generate "Nickname:"

This ensures that we never display confusing labels, never use {{Detect singular}} to generate visible markup, and eventually attain "Nickname" vs. "Nicknames" consistency.

Are other editors fine with this? I will change the sandbox version and {{Detect singular}} to match this plan. —hike395 (talk) 20:48, 18 November 2018 (UTC)

That looks like it might work. In step 3, "convert all" should say "convert all appropriate", since there will be false positives. – Jonesey95 (talk) 21:05, 18 November 2018 (UTC)
Yes, thanks. Changed step 3 to make it clear that we have to use semi-automatic editing (which will take some time). —hike395 (talk) 21:26, 18 November 2018 (UTC)
that works for me. Frietjes (talk) 19:28, 19 November 2018 (UTC)

Help![edit]

@Frietjes, Jonesey95, and Zackmann08: After about a week, the tracking categories discussed above have about 6,000 articles in them (perhaps with some duplicates). This will be about 20 hours of work with AWB. I'm slowly chipping away at it, but I'm not making much progress. It can't be fully automated, I think. Any/all help is welcome! —hike395 (talk) 19:33, 23 November 2018 (UTC)

I don't see a way to remove a false positive from a category, which will mean that I, or other editors, will keep looking at the same articles repeatedly. – Jonesey95 (talk) 20:18, 23 November 2018 (UTC)
@Jonesey95: Yes, that is true. Once we decide that a category is "finished", we can change the label from "Nickname(s)" to "Nickname", hope that editors do the right thing, and remove the tracking. Or were you worried about more than one editor performing the mass edits? In the latter case, we can just agree to divide up the categories. —hike395 (talk) 21:19, 23 November 2018 (UTC)
@Hike395: going to be honest, I'm DEEP in the throws of building {{Infobox chemical}}. Can this wait? Obviously we all know WP:NORUSH, but is there any reason you'd like to be done sooner rather than later? If you don't mind putting this on hold I'd be more than happy to dive in on it in a week or 2? --Zackmann (Talk to me/What I been doing) 21:03, 23 November 2018 (UTC)
@Zackmann08: Yes, it can wait. I probably will only be able to do a small fraction in the next 2 weeks. —hike395 (talk) 21:19, 23 November 2018 (UTC)

Explanation needed for Category:Infobox settlement pages with bad settlement type[edit]

Can someone please explain, either here or at Category:Infobox settlement pages with bad settlement type, how pages get into that category and how to fix them? The code that applies the category is challenging to interpret. Thanks in advance. – Jonesey95 (talk) 22:41, 27 November 2018 (UTC)

Jonesey95, looks to me that it is triggered when the settlement type has the name of the country or one of the subdivisions in it. so, for example, Ábrego says "Municipality of Colombia" when it should say "Municipality"? probably related to forming a sensible short description without redundant words. but, someone else probably knows better. Frietjes (talk) 23:27, 27 November 2018 (UTC)

Span tags changed to div tags to fix Linter errors[edit]

After a bunch of testing in the sandbox, I have changed some of this template's <span>...</span> tags to <div>...</div> tags in order to fix Linter div-span-flip errors (a div tag inside of a span tag, which is invalid HTML).

See Test case 10 for a comparison of the live template with the sandbox; the sandbox currently contains the previous version of the live template.

As far as I can tell from my testing, the infobox should look the same in all articles before and after this change. That said, WP editors are endlessly creative in their use of template parameters, and with 490,000 transclusions, there are bound to be a few unexpected side effects. Please post here if you notice anything unusual or bad happening after this change, along with a link to an affected page. Thanks! – Jonesey95 (talk) 06:48, 28 November 2018 (UTC)

Help![edit]

Hi can anybody spare a bit of time and have a look at the use of this template at swwiki? See here sw:Kigezo:Infobox_settlement. We tried to translate it and something now is wrong with the pushpin map, i guess. We have similar problems from time to time. We do not have anybody who really can handle template script and either try to play around and it luckily fits, or one of us asks someone at enwiki to help us.. And then you guys here at enwiki change a template that we copied ages ago and after a while we notice it does not look any more like it should... But here I guess it is just a mistake in our translation canges. Appreciate it very much if someone tries! Kipala (talk) 21:13, 3 December 2018 (UTC)

I'm looking at sw:Mombasa and sw:Dar es Salaam and sw:Nairobi, and the pushpin maps look fine. Can you link to an article where it is not working properly?
This may be of interest: In 2017, en.WP discontinued the use of individual latitude and longitude parameters, using the {{coord}} template instead. We had to migrate a long list of templates in order to make this happen. You can see a summary of the project at Wikipedia:Coordinates in infoboxes. – Jonesey95 (talk) 22:09, 3 December 2018 (UTC)
Kipala, looking at enWP shows how to not do it. Look at frWP, which uses Wikidata much more. I think caWP too. enWP is not a modern model. 78.55.100.38 (talk) 03:19, 7 December 2018 (UTC)

IB mapframe field[edit]

Would it be possible to add a field for {{Infobox mapframe}} (just like we have one for {{coord}})? The area_km2 parameter of that template could be linked to settlement's area_total_km2 so that the OSM map would automatically use the correct zoom level.--eh bien mon prince (talk) 02:25, 5 December 2018 (UTC)

It is possible, but it must be done carefully. We don't want to display two maps, and there may need to be a discussion about whether a mapframe map should be implemented in an opt-in (i.e. you have to add a parameter and its value to a template transclusion in each article) or opt-out (i.e. a map will appear by default unless someone disables it). There is also the question of default zoom levels. See Infobox museum for an example of how it was done in a way that seemed to make most people happy. – Jonesey95 (talk) 14:06, 4 February 2019 (UTC)

Inappropriate documentation part[edit]

Section Template:Infobox_settlement/doc#Redirects_and_calls is not helpful as documentation, and so beter be removed. -DePiep (talk) 20:35, 4 February 2019 (UTC)

Information about redirects and calls exists since 2009 and has been deemed appropriate and helpful. 78.55.20.3 (talk) 00:29, 5 February 2019 (UTC)
'Since 2009' does not make this section less useless. "Deemed appropriate": where was that stated? -~~
This is an explicit support. -DePiep (talk) 08:03, 5 February 2019 (UTC)
Yes, it explicitly supports retaining the "Redirects and calls" section. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:29, 5 February 2019 (UTC)
You deleted stuff, which is a confirmation (although without waiting for consensus here, or even contributing here). -DePiep (talk) 15:58, 5 February 2019 (UTC)
BTW, what does it mean when you say: "This is not a page" in [2]? And why do you take the privilege of editing while the section is contested right here? [3] -DePiep (talk) 15:58, 5 February 2019 (UTC)

There is consensus to remove [4], DePiep removed it, IP did, Andy did. I renamed the section because the Calls part comes first in the text and is more important than the Redirects part. 77.13.148.190 (talk) 17:12, 5 February 2019 (UTC)

Please remove the merge warning[edit]

Please remove the merge warning JUNK that is show up at the top of a mountain of community articles: "The template Infobox settlement is being considered for merging". At this exact moment, 3 identical warnings are showing up above the infobox of THOUSANDS of community articles. • SbmeirowTalk • 23:30, 6 February 2019 (UTC)

Thanks. • SbmeirowTalk • 01:42, 7 February 2019 (UTC)

Template-protected edit request on 7 February 2019[edit]

Could someone please noinclude the whole of the series of tfm notices? There's no need to show this message on the almost half a million articles that transclude this template every time someone proposes to merge away some obscure related infobox. The tfm message takes up valuable screen space and it also often crops up in the little snippets of an article's text that appear in the search results, crowding out the actually relevant bits of the article's text. – Uanfala (talk) 02:30, 7 February 2019 (UTC) – Uanfala (talk) 02:30, 7 February 2019 (UTC)

 Done -- /Alex/21 02:49, 7 February 2019 (UTC)
Thanks!!! • SbmeirowTalk • 05:21, 7 February 2019 (UTC)

Idea: dynamically fetch the population[edit]

Hi, recently I discovered that some wrappers for this infobox template like Template:Infobox_Swiss_town or Infobox German location are using a central storage for the yearly changed population numbers, which I find quite cool. I think it would be great to add such a storage and dynamically access via some ID to this fundamental template as well. --tokes 18:10, 10 February 2019 (UTC) — Preceding unsigned comment added by Tokes (talkcontribs)

Category:Wikipedia page with obscure country or subdivision and this template[edit]

Is the template code working correctly? There are over 20k articles listed at Category:Wikipedia page with obscure country or subdivision, from spot checking articles, most seem to be calling this template (or one of its wrappers). Since the category's documentation says: These pages have a call to {{#invoke:ISO 3166}} which either the country, subdivision or both are not recognized. - the following code must be the one which tags the articles:

{{#invoke:ISO 3166 |geocoordinsert |1={{{coordinates|}}} |country={{{subdivision_name|}}} |subdivision1={{{subdivision_name1|}}} |subdivision2={{{subdivision_name2|}}} |subdivision3={{{subdivision_name3|}}} |type=city{{#if:{{{population_total|}}} |{{#iferror:{{#expr:{{formatnum:{{{population_total}}}|R}}+1}}| |({{formatnum:{{{population_total}}}|R}}) }} }} }}

Is the template code ok, is the editor usage wrong? 20k is way too high for such a thing. --Gonnym (talk) 23:47, 10 February 2019 (UTC)

@Jonesey95 and Hike395: any thoughts? --Zackmann (Talk to me/What I been doing) 00:12, 11 February 2019 (UTC)
As Gonnym says above, these errors are arising from the geocoordinsert function in Module:ISO 3166. That function was created by Frietjes on Sep 12, 2018. Unfortunately, there is no documentation or testcases for that function (that I can find), so I'm not sure what the correct behavior should be. In general, |subdivision_name= or |subdivision_name1= for this template can be arbitrary wikicode (see, e.g., User:Hike395/testISO, extracted from Abakan, which is placed into the "obscure subdivision" tracking category).
Hopefully Frietjes can explain the intent of the function, hopefully fixing this template, documenting the function, or providing test cases? Happy to do the work if it is clear what to do. —hike395 (talk) 02:37, 11 February 2019 (UTC)
It looks like BrandonXLF added these categories to Module:ISO 3166. That editor was making many sloppy and hasty edits to templates during that time period, and it looks like edits to that module may need to be reviewed to see if they make sense.
Also of note: the category appears to be applied when no country or subdivision is specified. See User:Jonesey95/sandbox3 for an example. I think that we need to (1) refine the test to limit its application to article space, (2) rename and/or split the categories to a more accurate description (having "Wikipedia page" in a category name is not helpful, since all categories apply to pages on Wikipedia), (3) possibly refine the code to accept a wider variety of inputs, and/or (4) completely rethink and rewrite the error check, since it is probably fundamentally flawed. (Also, if we keep this test, it should be documented well. I am happy to do that once someone explains what the test is doing and why.) – Jonesey95 (talk) 08:23, 11 February 2019 (UTC)
The point of the function is to convert the incoming parameters to the correct ISO 3166 region code to send to Module:Coordinates.
If both |subdivison1= and |subdivison2= are invalid, it will return Category:Wikipedia page with obscure subdivision
If |country= is invalid, it will return Category:Wikipedia page with obscure country
BrandonXLF (t@lk) 13:39, 11 February 2019 (UTC)

────────── @Gonnym, Frietjes, Jonesey95, and BrandonXLF: I think I see what's going on. Module:ISO 3166 is magic code that attempts to map backwards from country/subdivision strings to ISO 3166. There seems to be some Lua code for stripping wikilink markup. There is no code for stripping suffixes (such as references), which caused an error for Abakan.

First-level (country) region codes for geohack are moderately useful for providing mapping links specific for that country. Second-level (province) region codes are not used by geohack AFAICT. The geocoordinsert function seems to be providing a "best effort" at providing first and second level region codes. There are about 20K settlement articles where the second one fails, filling a tracking category.

Because it's a "best effort", and not critical functionality, and because editors are allowed to enter arbitrary wikicode, I think filling a tracking category is overly alarming. If I understand my Lua correctly, setting "nocat=true" in the function call suppresses such tracking. I added this to {{Infobox settlement}}. The tracking categories should empty out over the next few days.

If other editors disagree, or if I misunderstood the Lua and "nocat=true" does nothing or breaks something, please let me know and we can revert. Thanks! —hike395 (talk) 16:40, 11 February 2019 (UTC)

I would think editors would want to fix articles like Abbot Springs, Alabama, which list no country or subdivisions? however, the old code was able to deal with flagged entries like Abbott, Nebraska. it's the new code by BrandonXLF that's far less robust. Frietjes (talk) 17:08, 11 February 2019 (UTC)
@Hike395: The categories are hidden, so they shouldn't affect readers, the can only be helpful. @Frietjes: I can try to modify the code to remove more stuff. BrandonXLF (t@lk) 17:17, 11 February 2019 (UTC)
I agree that there should be nothing wrong with adding tracking categories when things go wrong, so long as there in interest in fixing the problems. the fact that these tracking categories have stayed so full for so long indicates that the people who are have the will and knowledge to fix the problem aren't checking the categories. Frietjes (talk) 17:21, 11 February 2019 (UTC)
I agree with Frietjes that a missing country in a settlement article should probably generate a hidden tracking category, but not any of the categories named above. Something like "Category:Pages using infobox settlement with missing country" would probably be appropriate. – Jonesey95 (talk) 18:45, 11 February 2019 (UTC)
@Jonesey95: It would have to be "Category:Pages with invalid ISO 3166 countries" and "Category:Pages with invalid ISO 3166 subdivisions" BrandonXLF (t@lk) 20:49, 11 February 2019 (UTC)

──────────── Two things to note:

  1. My fix to the template didn't work, because args.nocat is used in the geocoordinsert() function, then seems to be thrown away when luacode() function is called (if I'm interpreting Lua correctly --- p.luacode({country, subdivision, nocat = 'true'}) at line 252 means set nocat to true, right?). Can we fix this?
  2. The problem with the current tracking categories is that the editors who placed the infoboxes are doing nothing wrong, and the code is functioning as intended. There's nothing to fix, so why are we tracking it? If we want to check for empty countries in this infobox, why can't we just put tracking code at the bottom of this template?

Thanks! —hike395 (talk) 04:18, 12 February 2019 (UTC)

I think that's exactly what we should do (track at the bottom of the template). And to BrandonXLF, I don't think it's a good idea to use the same category for missing countries that we use for invalid countries. – Jonesey95 (talk) 05:56, 12 February 2019 (UTC)
@Jonesey95: I meant to put missing, my bad. BrandonXLF (t@lk) 06:00, 12 February 2019 (UTC)

Please add field to append population change[edit]

Population change over the previous period is a useful fact. Please include this field. Ythlev (talk) 15:34, 11 February 2019 (UTC)