Wikipedia

Template talk:Infobox settlement/Archive 27

< Template talk:Infobox settlement
Latest comment: 5 years ago by Zache in topic Wrapper Templates/Guidelines
Archive 20←Archive 25Archive 26Archive 27Archive 28Archive 29Archive 30

Moving maps, flags, and seals further down

Latest comment: 5 years ago6 comments4 people in discussion

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

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)

"Municipality in Southeast, Brazil"

Latest comment: 5 years ago1 comment1 person in discussion

I think this template is responsible for this strange short description on Duque de Caxias, Rio de Janeiro. The problem is probably because the infobox has subdivision1: Region => Southeast and subdivision2: State => Rio de Janeiro. It would be better to change this somehow programmatically to either "Municipality in Southeast Brazil" or "Municipality in Rio de Janeiro, Brazil" (or "... Rio de Janeiro state, Brazil"). This seems to be a problem for most articles on Brazilian settlements with the infobox that I've checked. Daß Wölf 22:22, 3 March 2019 (UTC)

Requested move 28 February 2019

Latest comment: 5 years ago105 comments24 people in discussion
The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this section.

The result of the move request was: Not moved. Even many of those opposed acknowledge problems with the current title, but no alternative has generated enough support to warrant a move. The leading candidates appear to be {{Infobox populated area}} or {{Infobox locality}}, but interest petered almost a week ago. I suggest a proposal to move to specifically either one of those, or perhaps another particular choice, may have a better chance of success. I will just add that it's possible there is no good English term that means what is required here. (non-admin closure) В²C ☎ 19:32, 12 March 2019 (UTC)

Template:Infobox settlement → ? – See Template talk:Infobox settlement#Better name for the template {{3x|p}}ery (talk) 13:27, 28 February 2019 (UTC)

Pinging users who commented in recent TfDs about the name or using the name as an argument: @Tom (LT), Pigsonthewing, Gonnym, Knowledgekid87, Bokmanrocks01, DePiep, Dimadick, Carlossuarez46, Mardus, GN-z11, and Zackmann08: {{3x|p}}ery (talk) 13:34, 28 February 2019 (UTC)
  • Do not rename. 'settlement' is a very good generic term, and applies to everything that is not defined as a city, town, county, or some other established settlement structure. -Mardus /talk 14:29, 28 February 2019 (UTC)
Per User Gonnym, and per the authoritaive Merriam-Webster dictionary, which s/he cited:
occupation by settlers;
a place or region newly-settled,
and per infobox documentation:
It should be used to produce an Infobox for human settlements (cities, towns, villages, communities) as well as other administrative districts (for example, state-level settlements, if they lack their own infobox), counties, provinces, et cetera—in fact, any subdivision below the level of a country.
(some emphases mine) ^ This also includes states and provinces and same-level settlements.
Infoboxes for specific settlement types (cities, towns, etc) are used with certainty for settlements that are formally recognised as such, and/or which are incorporated (à la "This is a city", "this is a town", "province," etc.), whereas settlements not defined in any law books, historical settlements, or those without formal recognition are left as they are, and therefore, this template applies rather well.
In addition, the template applies for 'any subdivision below the level of a country,' for which any other template would not apply. For that same reason, there is {{Infobox civil conflict}}. -Mardus /talk 04:42, 1 March 2019 (UTC)
User:Mardus, there are territorial entities that contain no settlement: Total Exclusion Zone. And some with no officially populated settlement anymore: Chernobyl Exclusion Zone. And try to explain to a native speaker of English, that Texas can be called "settlement" by using English standard vocabulary. It may not work. 77.183.83.164 (talk) 20:41, 2 March 2019 (UTC)
Seconded. --Tom (LT) (talk) 23:20, 2 March 2019 (UTC)
There are places that are called 'settlement', so for that reason alone, this template does not require moving. Per comments below, the template has also been stable since 2007. And I hope, 77.183.83.164, that you are not an IP sockpuppet. -Mardus /talk 04:37, 3 March 2019 (UTC)
Yet despite these redirects and the template documentation, some editors are still opposing mergers on the ground that a "settlement" is not [whatever is being nominated]. Here are some of the opposing comments:
  • Several of these subdividions were subordinate state and provinces, while "settlements" is supposed to covers cities, towns, and villages [referring to Infobox former subdivision]
  • States are not settlements [referring to Infobox U.S. state]
  • Per definition, a settlement(human) is not a region (administrative unit). Whatever non-vetted wiki documentation may say: we cannot change RL concepts, so future editors will be confused ever [referring to various templates]
  • A (country) district is not a settlement [referring to Infobox district of Iraq]
  • If we were going by Merriam-Webster the term for settlement is as follows: a : occupation by settlers; b : a place or region newly settled; c : a small village; I don't see how a state fits this criteria [referring to Infobox U.S. state]
Which is why this discussion has started, to try and figure out if the name that is used is the best option. --Gonnym (talk) 15:09, 28 February 2019 (UTC)

This template is used to produce an Infobox for human settlements of any type below the level of a country. Examples of settlements for which this template should be used include, but are not limited to, cities, towns, villages, communities, counties, provinces, and administrative districts. For countries, {{Infobox country}} should be used.

Parameters are described in the table below. For questions, see the talk page. For a U.S. city guideline, see WP:USCITIES.

That does sound better. I would also specifically mention states as those are a major issue, so "counties, provinces, federal states, and administrative districts and divisions". I'm also in the opinion that the US city guideline part should not be here, as then you probably have a guideline for a lot of other places. --Gonnym (talk) 16:47, 28 February 2019 (UTC)
I also think that it should include the words "former" and "current" as that also came up a few times. So "This template is used to produce an Infobox for current and former human settlements" or something. --Gonnym (talk) 22:14, 1 March 2019 (UTC)
  • Do not rename the objections to settlement are just people being pedantic. It ain't broke so why are we trying to fix it. --Zackmann (Talk to me/What I been doing) 17:06, 28 February 2019 (UTC)
  • Rename. The main article Human settlement and the sub-article settlement hierarchy specifically cover Hamlets, Villages, Towns, Cities, and various concepts of the Metropolis. Anything else is entirely out of scope for a "settlement". Dimadick (talk) 00:44, 1 March 2019 (UTC)
  • Rename By definition.... things like states are not considered settlements. settlement vs state. - Knowledgekid87 (talk) 04:23, 1 March 2019 (UTC)
  • I don't see the point of !voting rename without a suggestion for a better name. Galobtter (pingó mió) 04:57, 1 March 2019 (UTC)
  • Oppose move until a proposal for the target page is available, a proposal that is an improvement. Also, the name of a template does not matter providing it is not meaningless or misleading. That means the template should not be "Infobox box" or "Infobox city". A generic word such as "settlement" is fine—the name of a template is not a precise definition of a term. Johnuniq (talk) 06:12, 1 March 2019 (UTC)
    • As I said previously, "settlement" is misleading to the point where it's not just about the definition. Have you reviewed all the redirects listed above to see if there's a name that fits? GN-z11 ☎ ★ 09:44, 1 March 2019 (UTC)
  • This template is confusingly named. "Settlement" is wrong. Yes, I am being pedantic. Yes, this is an encyclopedia so truth and reality as generally understood are quite important here. I don't see why just because things are a certain way now they can't change. I would support a move to {{Infobox populated area}} which most accurately describes what this template does.--Tom (LT) (talk) 06:21, 1 March 2019 (UTC)
  • How about "Infobox locality"? --Bsherr (talk) 16:30, 1 March 2019 (UTC)
  • Oppose No actual benefit; the template name does a sufficient job of conveying what you're supposed to do with it. If we move it to a different place, we might have a longer name (less convenient to use), and even if that doesn't happen, you've renamed something that's been stable since 2007; renaming a long-stable page can be confusing. If we'd always had this at "Infobox populated area", I would oppose moving to "Infobox settlement" for the same reason, since inertia shouldn't be disturbed for no real reason. Also, expanding the name from Infobox Onewordname to Infobox Two wordname makes it marginally less convenient to use, since if you want to highlight the whole title, you need more key presses every time (Ctrl+Shift+Right arrow+Right arrow) or need to be a little more careful with your mouse. Nyttend (talk) 17:29, 1 March 2019 (UTC)
    • I can definitely think of one actual benefit. Every time a template is proposed to be merged into Infobox settlement, a dozen ignorant people come forward to say, even when there is 100% overlap of parameters, "Keep because X isn't a settlement." TfD is clogged with this rubbish, and sometimes there are enough of them to drive consensus, even though the argument is nonsense. If the name better matched the purpose, we could avoid this. --Bsherr (talk) 21:17, 1 March 2019 (UTC)
      • @Bsherr: while I totally agree that these ignorant comments are rubbish, I don't think that means we should change things. I think it means we should call a spade a spade and acknowledge that these trolls are just being pedantic and not helping the discussion at all. --Zackmann (Talk to me/What I been doing) 21:22, 1 March 2019 (UTC)
        • I guess it depends on how you view the template name. These days, I tend to think of the template name as an extension of its documentation (a view that manifests in the effort to move maintenance templates to plainer and more meaningful names (and even from otherwise "stable" ones), for example). If the current name is confusing many users, and the evidence is very clear that it is, we ought to strongly consider whether a new name would avoid that confusion and if so, strongly consider a new name. --Bsherr (talk) 21:39, 1 March 2019 (UTC)
          • @Bsherr: I think almost everyone will agree that {{Infobox populated area}} is a totally sensible proposal to stop the "keep because that ain't a settlement" votes on TfD. There surely wouldn't be a "keep because that ain't a populated area" vote. Even though that's only the opinion of pedantic trolls that are not helping the discussion at all. GN-z11 ☎ ★ 22:07, 1 March 2019 (UTC)
          • @GN-z11: I'm not so sure. I tend to think, while we are considering new names, we should do our best to avoid issues we can anticipate. We want this template to cover ghost towns too, so I am sympathetic to the argument that "populated" is better, but still not the best. --Bsherr (talk) 22:19, 1 March 2019 (UTC)
            • @Bsherr: I have to concur with you on ghost towns, however names like {{Infobox former settlement}} redirect here, and anyway a place generally needs to be populated (settled) to be called a settlement, so I don't think there is any good solution to this problem. GN-z11 ☎ ★ 22:34, 1 March 2019 (UTC)
              • There are some possible solutions. I've suggested "locality" above. Just plain "area" might work too; that's a also a redirect right now. --Bsherr (talk) 23:11, 1 March 2019 (UTC)
                • It should also be noted that all these templates are placed under a "Place" section header at Wikipedia:List of infoboxes#Geography and place. --Gonnym (talk) 23:15, 1 March 2019 (UTC)
                  • The word "place" is, in my opinion, too broad. "Locality" is a decent alternative, though. GN-z11 ☎ ★ 09:39, 2 March 2019 (UTC)
                    • I would agree with {{Locality}} which does a better job than settlement (which also doesn't cover unpopulated or larger areas). Also although I have disagreed with several of these nominations @Bsherr and @Zackmann08 I don't think I am a "troll". I am an editor here who sees our primary purpose as an encyclopedia. Therefore it concerns me when we choose to use a confusing and misleading title for something, because it means in some small corner of the encyclopedia we're choosing to ignore some small truth (like, "settlement" is not a good term for areas that are not settlements). Being pedantic and accurate is part of our mission here. --Tom (LT) (talk) 23:20, 2 March 2019 (UTC)
                      • I don't think you're a troll, Tom, and I don't think Zack does either. I think that comment was in reference to folks who make the "Keep because X isn't a settlement" argument at TfD. I think we're in agreement at TfD, what, 90% of the time? And, as discussed above, I agree completely that we should rule out a given potential name if a better, more accurate, and less confusing alternative exists. And I'm happy to join the pedant club with you. --Bsherr (talk) 15:10, 3 March 2019 (UTC)
                        • I supported every one of the TfD, but I also feel that if the name is problematic and does not cover the entire subject AND there are better names available, then a name change should be a valid option. While I can't read Zack's mind, I'm pretty sure he did not mean you. --Gonnym (talk) 15:32, 3 March 2019 (UTC)
  • Oppose move per Nyttend. This is a solution in search of a problem. Deor (talk) 22:31, 1 March 2019 (UTC)
    • @Deor: I think we should start thinking of the future more than the past. The confusion the move would prevent far outweighs the confusion it'll cause, plus per Gonnym's comment above, this template itself has two words anyway ("infobox" "settlement"), so do many high-use templates. (also a reply to Nyttend). GN-z11 ☎ ★ 22:39, 1 March 2019 (UTC)
  • Oppose move. • Sbmeirow • Talk • 00:41, 2 March 2019 (UTC)
    • Though I use "settlement" for ghost towns, and I don't have any problems using it for that purpose, "populated area" would be even more confusing for ghost towns. If your solution is another weird alias, then it means you haven't solved this problem by moving to "populated area". • Sbmeirow • Talk • 04:08, 3 March 2019 (UTC)
    • "community" might be another choice, instead of "populated area". • Sbmeirow • Talk • 04:08, 3 March 2019 (UTC)
  • Support, the template is increasingly being used for non-settlements. More and more other templates are merged into this, and the name is plainly confusing now. Perhaps move to a more generic name with a bunch of redirects that look they make more sense? —Kusma (t·c) 09:49, 2 March 2019 (UTC)
  • Support I agree some move would be beneficial, I myself had wandered about this. Wikipedia:WikiProject UK geography/How to write about settlements#Infobox says to use {{Infobox UK place}} for settlements but {{Infobox settlement}} for cases where an administrative division is being referred to. Might something like {{Infobox place}} or {{Infobox administrative division}} (or similar) do? I also don't see Nyttend's point since the move will have no impact on readers or editors since unlike categories and category redirects a template works the same even if a redirect to it is transcluded. I would also recommend renaming Infobox UK place to something like Infobox UK settlement to make it clear that its mainly intended for settlements, rather than buildings, administrative divisions or natural features etc. Crouch, Swale (talk) 18:31, 2 March 2019 (UTC)

What are 'we' voting on? Renaming to some known name, or an unknown name that will be decided after this vote? Also, why is another name going to be magically better??? • Sbmeirow • Talk • 21:01, 2 March 2019 (UTC)

  • Do not rename. The name "settlement" is perfectly OK for an object that is a settlement. (And so for part of settlement, historical settlement, etc). Problem is usage creep, in that the {{Infobox settlement}} is used for objects that are not a settlement (but are a country or part thereof). -DePiep (talk) 12:52, 3 March 2019 (UTC)
    • I don't disagree with you about not renaming. If there is usage creep with regard to using the template for country-level areas, then that can be fixed in each individual article, instead of renaming the entire template that is useful as-is in many other articles. An original settlement is never a country in the first place, even if the territory is country-sized, and its society or form of government eventually attains the complexity of a country and/or state. -Mardus /talk 13:24, 3 March 2019 (UTC)
      • (By request, qouting what I posted elsewhere [1]): The objections are not re the name, the name is right. The objections are that the object settlement is not an object country. And so neither are "parts of settlement", "Historical settlement", ... The name "settlement" is perfectly OK for an object that is a settlement. -DePiep (talk) 13:37, 3 March 2019 (UTC)
        • @DePiep: The usage creep issue is because of the name. The template documentation: It should be used to produce an Infobox for human settlements (cities, towns, villages, communities) as well as other administrative districts, counties, provinces, et cetera—in fact, any subdivision below the level of a country, which clearly does not concur with the basic meaning of "settlement". GN-z11 ☎ ★ 14:19, 3 March 2019 (UTC)
          • Usage creep is promoted through documentation, bad. Documentation cannot change the meaning of the concept "settlement". -DePiep (talk) 14:28, 3 March 2019 (UTC)
            • So you are opposing a name change but also opposing documentation change - you do realize that regardless of your personal preference, this infobox will continue to be used for articles that aren't "settlements" per your usage (based on all previous TfD and the lack of any scope changing discussion raised on this talk page)? Instead of opposing all options, suggest a way forward or compromise so we can find a solution. --Gonnym (talk) 15:29, 3 March 2019 (UTC)
              • I am "opposing documentation change"? No I am not, how did I make that impression? The documentation is wrong, too (but improving that brought me in conflict with owners). I say that, whatever the cost, infoboxes pertaining to "settlement" and those to "country" (-concepts) should be separated (and so their documentation). Two concepts, two infoboxes. Not merge everything into one {{Infobox thing}}. I say this from information handling & presenting, not from some misguided datatechnical background 'they have the same parameters so they are same thing'. -DePiep (talk) 16:41, 3 March 2019 (UTC)
              • I add. Giving in to this semi-proposal (no alternative name has been mentioned btw, so now we have: "it's NOT a settlement, but we don't know what it is actually"—sigh), would mean that we do not have an "{{Infobox city}}" any more. It also says like: "we have been abusing 'settlement' for 'country' so widely and so long, we should make this formal now". -DePiep (talk) 16:50, 3 March 2019 (UTC)
                • I'm sorry if I understood you incorrectly, but you saying Usage creep is promoted through documentation, bad. Documentation cannot change the meaning of the concept "settlement" seemed to me that you meant that even if we change the documentation to support the bigger scope, this would still be bad documentation, which to me seemed like you are opposing changing it (to reflect actual usage, not to reflect what you prefer the actual usage to be). --Gonnym (talk) 16:55, 3 March 2019 (UTC)
                  • I get this, a misunderstanding. Well, I tried to say "[Infobox] settlement" is used wrongly for country objects. (That is: country-like parts etc. 'Settlement' means city, village, metropolitan area; 'country' is an organisational thing, like province, US-state). That is wrong usage, I call 'creep'. This usage has been promoted through the documentation, as you quoted. But I replied that such documentation may condone the usage but can not nullify the fact of misuse. Changing that documentation detail could be an side-outcome of this proposal.
                  • If this is cleared, can we go back to the issue: do not remove "{{Infobox city}}". -DePiep (talk) 17:10, 3 March 2019 (UTC)
    • Please provide evidence or the claim that "Infobox settlement is used for objects that are not a settlement (but are a country[...])". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:06, 3 March 2019 (UTC)
  • Comment - Out of curiousity, why do {{Infobox area}}, {{Infobox location}}, {{Infobox place}}, {{Infobox populated area}}, {{Infobox populated place}} redirect here? This is getting to be so broad we might as well merge {{Infobox country}} and {{Infobox planet}} next. - Knowledgekid87 (talk) 17:14, 3 March 2019 (UTC)
    • Because the Infobox is "for human settlements (cities, towns, villages, communities) as well as other administrative districts, counties, provinces, et cetera—in fact, any subdivision below the level of a country". Was that not already clear? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:02, 3 March 2019 (UTC)

Better name for the template

In so many recent TfD discussions, most of the opposing rationals were based only on the fact that the template is called "settlement". Is there a better name this template can use so these arguments stop being used? --Gonnym (talk) 11:39, 28 February 2019 (UTC)

You spelled 'rational' instead of 'rationale'. -Mardus /talk 05:06, 3 March 2019 (UTC)
The objections are not re the name, the name is right. The objections are that the object settlement is not an object country. And so neither are "parts of settlement", "Historical settlement", ... The name "settlement" is perfectly OK for an object that is a settlement. -DePiep (talk) 12:48, 3 March 2019 (UTC)
Care to move the part of the thread beginning with your reply further below, DePiep? -Mardus /talk 13:18, 3 March 2019 (UTC)
I thought this is the place where the "better name" is explored, it is a question mark in the Move proposal below! I will copy it into the discussion all right. -DePiep (talk) 13:37, 3 March 2019 (UTC)
The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

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

Latest comment: 5 years ago23 comments6 people in discussion

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)

Ok, so the count is down to around 8k. Can someone explain to me how to fix these? As an example, lets take it Aasa Buttar. It is placed in Category:Wikipedia page with obscure subdivision and has Punjab as |subdivision_name1= - how should it be formatted? --Gonnym (talk) 16:14, 8 March 2019 (UTC)

@Gonnym: I don't know why the count isn't close to 0 after a month. If you go to Aasa Buttar and look at its hidden categories, it is not in Category:Wikipedia page with obscure subdivision. When I test the geocoordinsert function for Aasa Buttar in my sandbox, it doesn't produce any errors. I think updating the category by Mediawiki is broken in some way. @Frietjes: do you have any good ideas? —hike395 (talk) 09:10, 12 March 2019 (UTC)
Later: WP:null edits fix this problem. —hike395 (talk) 09:15, 12 March 2019 (UTC)
Even later: WP:AWB performing null edits can fix the problem. But I don't want to spend 6 hours mindlessly mashing a green save button to finish fixing this. I fixed ~100 articles. —hike395 (talk) 09:50, 12 March 2019 (UTC)
hike395, you could try 'User:Frietjes/masspurge.js' which allows you to provide a list of pages to purge. Frietjes (talk) 13:37, 12 March 2019 (UTC)
The reason that the category still has members after a month is because of this bug: T132467. Barring manual or bot null edits, it can take months for articles to update their category membership after a transcluded module or template is changed. – Jonesey95 (talk) 15:16, 12 March 2019 (UTC)
It looks like almost all of the ones that are left in the category are being added by Template:Infobox station and Template:Infobox NRHP. – Jonesey95 (talk) 06:02, 13 March 2019 (UTC)
I left a note on {{Infobox station}} and placed {{Infobox NRHP}} at TfD for either merge or convert to wrapper of {{Infobox historical site}} (which does not have this issue). Just need now for Category:Wikipedia page with obscure country to get updated. --Gonnym (talk) 10:13, 13 March 2019 (UTC)
Another option is to remove the categorization code from the Module, since it has never worked as designed and the category names are not useful, as detailed above. – Jonesey95 (talk) 11:26, 13 March 2019 (UTC)

Glitch

Latest comment: 5 years ago12 comments5 people in discussion

I don't know what's been happening but recently if you go to, for example, the Dallas page, and others, you see the seal in the coat of arms area when there is no input for the coat of arms at the bottom. And on some pages, such as, Shreveport, Louisiana, you see two coats of arms. Whatever change happened needs to be reverted asap.--TheTexasNationalist99 (talk) 15:07, 14 March 2019 (UTC)

Thanks for finding these. Dallas has bad Wikidata; its seal was uploaded into the coat of arms field. I don't do Wikidata, but that's some GIGO that needs to be fixed.
Shreveport, Louisiana was using the wrong parameter for the coat of arms, so GIGO as well. I fixed it per this template's documentation. – Jonesey95 (talk) 15:37, 14 March 2019 (UTC)
Thanks a ton. Who does Wikidata? I need it fixed for multiple settlement articles.--TheTexasNationalist99 (talk) 16:02, 14 March 2019 (UTC)
TheTexasNationalist99, anyone can do Wikidata.... --Zackmann (Talk to me/What I been doing) 16:04, 14 March 2019 (UTC)
Someone might be able to run a Wikidata query to find items that use the same image for "coat of arms" and "seal", then remove the duplicate images. – Jonesey95 (talk) 18:05, 14 March 2019 (UTC)
It would still need to be resolved manually after finding duplicates as I have seen cases with both fields with a Seal image or with both having the COA. I have also seen the flag in these as well. I've been fixing a few of these, but I don't like editing Wikidata as I don't like not being able to add an edit summary to explain the reason, so then you sometimes get reverted and have to go explain on a talk page. KylieTastic (talk) 18:13, 14 March 2019 (UTC)
That's what I meant by "then remove the duplicate images". Someone would need to look at the results of the query, then visit each Wikidata item and remove the incorrect duplicate image (e.g. if a seal is being used for both "seal" and "coat of arms", you would remove the coat of arms image, as should be done for Dallas above). – Jonesey95 (talk) 18:20, 14 March 2019 (UTC)
I have fixed up the Dallas entry and added the actual COA as it was on commons. KylieTastic (talk) 18:22, 14 March 2019 (UTC)
Noting I reverted Template talk:Infobox settlement#Adding of wikidata above. Galobtter (pingó mió) 18:28, 14 March 2019 (UTC)
Galobtter, I don't really see why that revert was needed... This caused issues on 2 pages because they had poorly formatted wikidata. The only "issue" was that duplicate info showed up. It wasn't like it broke the page... TheTexasNationalist99 made a big deal of the pages being messed the heck up but really didn't go into any sort of detail. Seems to me you are reverting a helpful change because of a limited number of pages with minor issues that need to be fixed on a case by case basis. Zackmann (Talk to me/What I been doing) 18:34, 14 March 2019 (UTC)
Making no comment on if the revert was correct or not, I would point out the edit had affected dozens of articles not just 2. I fixed around 50 yesterday in WikiData (one got reverted back), and I saw lots more flagged up in Category:Articles with missing files today that I would have tried to fix tonight. I was mostly fixing issues with multiple images per field and no preferred, and also some with "No value" in that caused image errors. KylieTastic (talk) 18:42, 14 March 2019 (UTC)
I explained the revert at Template talk:Infobox settlement#Adding of wikidata. As KylieTastic notes above, it definitely affected more than 2 pages; when you are dealing with a template with 500000 transclusions, the number of broken pages could easily be quite high - more will show up as pages are refreshed by jobs in job queue. Galobtter (pingó mió) 18:50, 14 March 2019 (UTC)

Many articles show name, state but the example on this page shows...

Latest comment: 5 years ago2 comments2 people in discussion

In the parameter "name", the example here just only says "Chicago", not "Chicago, Illinois".
However, many articles using this infobox don't just have the city name or town name or settlement name, in that parameter.
Many articles instead add a comma and some other name, of the larger region where that settlement is located.
Should the name parameter say "Chicago" or "Chicago, Illinois"
I think the articles should follow this example on this article however, in reviewing, I find TOO many articles include "comma, larger region name" for the name parameter. So it caused me to doubt.
Please clarify, if it should say "Chicago" or "Chicago, Illinois" - "Ponce" or "Ponce, Puerto Rico". If it should include the comma with the larger region, then the example on this article should be updated to show just that. Thank you.--Level C (talk) 21:32, 14 March 2019 (UTC)

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

Template-protected edit request on 19 March 2019

Latest comment: 5 years ago2 comments2 people in discussion

Hi, could you please improve the rounding for population density to 1 decimal point, because this template is used for Chinese provinces. The Chinese Wikipedia's data is more precise. :) =*= XHCN Quang Minh =*= (talk) 11:30, 19 March 2019 (UTC)

  Not done for now: As far as I can tell, Template:Infobox settlement/densdisp uses the number of significant figures in the population and area figures to determine how many decimal places to show for the density. If you can demonstrate otherwise, or link to articles where the calculation is not being done correctly, please do so. – Jonesey95 (talk) 11:54, 19 March 2019 (UTC)

Merge problems

Latest comment: 5 years ago4 comments3 people in discussion

Would someone please fix whatever is showing

(Expression error: Unexpected ( operator ha or Expression error: Unexpected ( operator acres)

in these articles:

Sorry, I don't have time to investigate. Perhaps Zackmann08 could have a look. Johnuniq (talk) 03:08, 22 March 2019 (UTC)

fixed--Lam-ang (talk) 04:35, 22 March 2019 (UTC)
Thanks. Johnuniq (talk) 04:46, 22 March 2019 (UTC)
Johnuniq sorry mate, I've been offline. That was 100% my fault.
Lam-ang thank you for jumping on that and fixing it! Zackmann (Talk to me/What I been doing) 15:02, 22 March 2019 (UTC)

Subst Template:Infobox South African town

Latest comment: 5 years ago9 comments4 people in discussion

Template:Infobox South African town - can anyone subst: these properly, so that template can be deleted. Almost two weeks since closure. 78.54.44.99 (talk) 20:52, 22 March 2019 (UTC)

Infoboxes are not substituted. Some templates have been waiting to be deleted or merged for two years. That's what you get when you allow non-admin closures of 'delete'. For this particular case (which has over 2,000 transclusions and around two dozen different or fixed parameters), see Wikipedia:Templates for discussion/Holding cell #To convert. --RexxS (talk) 21:22, 22 March 2019 (UTC)
RexxS, oh give me a break and stop insulting others. You don't help with ANY of the conversions. Every template I close, I merge (unless someone beats me to it). I'm in the process of performing this merge right now. I'm already about 15% done. Zackmann (Talk to me/What I been doing) 21:46, 22 March 2019 (UTC)
Zackmann08 Don't be so fucking precious. Nobody insulted you. Nevertheless, your wanna-be-admin NAC of "delete" is not helping this encyclopedia. It's just make-work. The template in question cannot be so simply deleted. It has far more functionality than {{Infobox settlement}}, and numerous parameters that don't exist in {{Infobox settlement}}, as well as several that are fixed (for South African towns). You're going to have to go through 2,000+ articles adding in these parameters as appropriate:
| subdivision_type        = Country
| subdivision_name        = [[South Africa]]
| subdivision_type1       = Province
| subdivision_type2       = District
| subdivision_type3       = Municipality
| subdivision_type4       = Main Place
| unit_pref               = Metric
| timezone1               = [[South African Standard Time|SAST]]
| utc_offset1             = +2
| postal_code_type        = [[List of postal codes in South Africa|Postal code]] <span style="font-weight:normal;">(street)</span>
| postal2_code_type       = [[Post-office box|PO box]]
| area_code_type          = [[Telephone numbers in South Africa|Area code]]
Then you'll be working out how you're going to handle |censuscode=. Do you think that should be just deleted? Because I read the consensus at Wikipedia:Templates for discussion/Log/2019 March 4 #Template:Infobox South African town as Replace and delete, not just delete. Don't you agree?
As for your complaint that I don't help with conversions, well, explain why I should help with this one? I'm a volunteer and not obliged to make any edit. It's not me who is making unnecessary work by deleting specialised wrappers that are working perfectly well. I disagree with your crusade to delete useful wrappers, and I have no intention of joining it. --RexxS (talk) 22:30, 22 March 2019 (UTC)
RexxS, WP:AGF. Calling me fucking precious is not very nice my friend. Zackmann (Talk to me/What I been doing) 22:32, 22 March 2019 (UTC)
@Zackmann08: I'm not your "friend". I don't know you. Accusing me of insulting you when you were never mentioned isn't very nice either, but you don't see me whining about it. If you can't take it, don't dish it out. You could have simply replied that you were working on the replacement (not merge, I hope, because of attribution issues) and asked politely if anyone would help. Instead you found the need to personalise this. The ball's in your court. --RexxS (talk) 22:43, 22 March 2019 (UTC)
RexxS, What court? Are we playing basketball? Zackmann (Talk to me/What I been doing) 22:45, 22 March 2019 (UTC)
@Zackmann08: it's a common metaphorical expression; see Dictionary.com. --RexxS (talk) 22:58, 22 March 2019 (UTC)
RexxS: What is going on? I don't see any reason for the hostility of what I just read, nor the obvious falsehood of at least one of your comments (it's NACs that cause the backlog? please). Sending the OPs comment on this tangent was entirely unnecessary. If you think that Zack is being disruptive or that the close is bad, you know where to go: WP:AN/WP:ANI or WP:DRV, as appropriate. --Izno (talk) 00:10, 23 March 2019 (UTC)

Adding of wikidata

Latest comment: 5 years ago21 comments9 people in discussion

I was going to add a few wikidata fallbacks to the template, but wanted to get some feedback first...

These would be fallbacks. I.E. if no |image_flag= flag image was provided the template would then poll Wikidata to see if one was provided there. I don't see any harm here but wanted to check... --Zackmann (Talk to me/What I been doing) 18:34, 11 March 2019 (UTC)

I support this. Any other WD properties that fit, being stable (unambiguous is the word I think) wrt this? Do they get the editing-pencil, tracking cats or other (editor-)support? -DePiep (talk) 21:20, 11 March 2019 (UTC)
Comments from the various current TfD wanted population to be retrieved from Wikidata, after those infoboxes which had templates that handled that data were deleted and moved to wikidata. Didn't check if this is already implemented here, but from the TfD comments it seemed like it wasn't and was wanted. --Gonnym (talk) 21:41, 11 March 2019 (UTC)
@Apalsola, DePiep, and Zache: It is also an issue with Template:Infobox Finnish municipality for which conversion stopped Wikipedia:Templates_for_discussion/Holding_cell#To_convert. So pop data would be really helpful. 78.54.44.99 (talk) 00:28, 23 March 2019 (UTC)
support + pop data and coordinates. Also country to be used with locator map. Ca. 5000 villages etc from Poland don't have maps, because coords and locator map are missing in the template:Infobox Settlement (sic, capital S, see transclusions). 89.14.152.24 (talk) 21:57, 11 March 2019 (UTC)
Note I wp:BOLDly added a couple of wikidata properties. Going to let it sit for a day or two. If there are no objections, I'll certainly add more! If anyone can think of other properties that would be good candidates to add, please list them! --Zackmann (Talk to me/What I been doing) 17:36, 13 March 2019 (UTC)
I reverted the change. Just technically, this should be done using Module:WikidataIB, so that there's an edit link to the property. Personally, I'm opposed to the addition of Wikidata properties: the data on wikidata is mainly an importation of what is here, and considering the GIGO issues below - unless it is clearly demonstrated that the data on Wikidata is both accurate and more comprehensive than what is on the English Wikipedia (i.e, it actually fills in gaps for a decent proportion of articles): there is no benefit to this change. Considering Wikipedia:Wikidata/2018 Infobox RfC etc, a change to use Wikidata in the most used Infobox should be more widely discussed IMO (bold does not really apply when you're dealing with a high risk template and with a change that is controversial due to the large amount of previous discussion on it). Galobtter (pingó mió) 18:25, 14 March 2019 (UTC)
@Galobtter: when used only as fallback it is by definition more comprehensive? 78.54.44.99 (talk) 00:31, 23 March 2019 (UTC)
Not if it is duplicate to other fields or otherwise inaccurate/bad. Galobtter (pingó mió) 05:47, 23 March 2019 (UTC)

Additional Wikidata

A few more that I have identified...

--Zackmann (Talk to me/What I been doing) 18:24, 13 March 2019 (UTC)

And look at what it's done to Dallas, Shreveport, Louisiana, and other local settlement articles...messed them the heck up. @Zackmann08:TheTexasNationalist99 (talk) 15:08, 14 March 2019 (UTC)
TheTexasNationalist99, you really need to be more specific than just messed them the heck up.... --Zackmann (Talk to me/What I been doing) 16:04, 14 March 2019 (UTC)

I made my take on with the population field in the sandbox. I made two changes:

  1. first to increase the row numbering for making room for new rows with wikidata values.(diff)
  2. and I added a new row for population value coming from Wikidata which will be visible only if all population parameters are empty or undefined.(diff)

Example page where infobox is used is User:Zache/settlement. Known issues are that with Module:WikidataIB you you can only ask "preferred" value and if there is no preferred value defined. If there is multiple values and you would need to sort them by date and select latest then you are out of luck. However, this is a problem with WikidataIB and there is no technical reason why sorting could not be done. (example with frwiki, @RexxS:) --Zache (talk) 15:40, 17 March 2019 (UTC)

@Zache: No problem with ranks. Module:WikidataIB accepts |rank=preferred, |rank=normal, |rank=deprecated, |rank=best, or a combination like |rank=p n, you can use p instead of preferred, etc. It's in the documentation at Module:WikidataIB #Ranks
If you code the field for inception like this:
  • data99 = {{#invoke:WikidataIB |getValue |P571 |qid={{{qid|}}} |name=inception |fwd={{{fetchwikidata|}}} |spf={{{suppressfields|}}} |osd={{{onlysourced|}}} |{{{inception|}}} }}
then you have a field that will accept a local parameter |inception= that will override any Wikidata. See Module:WikidataIB #Base parameters.
It will fetch data with ranks preferred and normal. If you only want the best ranked values add |rank=b to the above.
It will also not fetch Wikidata unless it is enabled by setting a parameter |fetchwikidata= to ALL in each individual article. This ensures that every article where it is enabled has consensus for inclusion of Wikidata, and that the editor enabling it has seen the results in that article. See Module:WikidataIB #Whitelist and blacklist.
It will also only fetch values that are sourced to something better than "Xyz Wikipedia", unless a parameter |onlysourced= is set to no in the article. This filter ensures a minimum level of sourcing for each value fetched. See Module:WikidataIB #Sourcing.
These facilities have been provided to meet the wishes of editors that infoboxes should be "opt-in" and should only provide sourced data by default.
It will add the pen icon and a link to the relevant property in the Wikidata entry although you can suppress that. See Module:WikidataIB #Link to Wikidata.
Qualifiers are available. For population (P1082) of Geneva (Q71), at point in time (P585):
{{#invoke:WikidataIB |getValue |P1082 |qid=Q71 |fwd=ALL |osd=no |qual=P585 |list=ubl}} →
  • 157,322 (1981)
  • 158,426 (1982)
  • 158,806 (1983)
  • 159,527 (1984)
  • 159,895 (1985)
  • 160,645 (1986)
  • 161,473 (1987)
  • 163,998 (1988)
  • 165,404 (1989)
  • 167,167 (1990)
  • 169,025 (1991)
  • 170,189 (1992)
  • 171,744 (1993)
  • 172,737 (1994)
  • 173,549 (1995)
  • 172,425 (1996)
  • 172,586 (1997)
  • 172,809 (1998)
  • 173,519 (1999)
  • 174,999 (2000)
  • 175,697 (2001)
  • 177,306 (2002)
  • 178,500 (2003)
  • 178,487 (2004)
  • 178,722 (2005)
  • 178,603 (2006)
  • 179,971 (2007)
  • 183,287 (2008)
  • 185,958 (2009)
  • 187,295 (2010)
  • 188,234 (2011)
  • 189,033 (2012)
  • 191,557 (2013)
  • 195,393 (2014)
  • 194,565 (2014)
  • 198,072 (2015)
  • 198,979 (2016)
  • 200,548 (2017)
  • 201,741 (2018)
  • 201,818 (2018)
  • 203,951 (2019)
  • 203,856 (2020)
  • 203,401 (2021)
  • 203,840 (2022)  
{{#invoke:WikidataIB |getValue |P1082 |qid=Q71 |fwd=ALL |osd=no |qual=P585 |list=ubl |lang=fr}} →
  • 157 322 (1981)
  • 158 426 (1982)
  • 158 806 (1983)
  • 159 527 (1984)
  • 159 895 (1985)
  • 160 645 (1986)
  • 161 473 (1987)
  • 163 998 (1988)
  • 165 404 (1989)
  • 167 167 (1990)
  • 169 025 (1991)
  • 170 189 (1992)
  • 171 744 (1993)
  • 172 737 (1994)
  • 173 549 (1995)
  • 172 425 (1996)
  • 172 586 (1997)
  • 172 809 (1998)
  • 173 519 (1999)
  • 174 999 (2000)
  • 175 697 (2001)
  • 177 306 (2002)
  • 178 500 (2003)
  • 178 487 (2004)
  • 178 722 (2005)
  • 178 603 (2006)
  • 179 971 (2007)
  • 183 287 (2008)
  • 185 958 (2009)
  • 187 295 (2010)
  • 188 234 (2011)
  • 189 033 (2012)
  • 191 557 (2013)
  • 195 393 (2014)
  • 194 565 (2014)
  • 198 072 (2015)
  • 198 979 (2016)
  • 200 548 (2017)
  • 201 741 (2018)
  • 201 818 (2018)
  • 203 951 (2019)
  • 203 856 (2020)
  • 203 401 (2021)
  • 203 840 (2022)  
The output of the function can be formatted in many ways, including as an unbulleted or horizontal list to meet accessibility concerns, and simple alphabetical sorting is available using |sorted=yes. See Module:WikidataIB #Formatting multiple returned values.
Sorting by value of a qualifier is not available, but if there was a need for it, it could be implemented. Similarly, if a function to return only the latest value from multiple values were needed, it could be implemented.
There are a number of of examples of the functionality of WikidataIB at Module talk:WikidataIB/testing if you want to explore further. --RexxS (talk) 16:38, 17 March 2019 (UTC)
@RexxS:, My point was not really about the data with rank, but that there is a lot of stuff in wikidata where there are multiple values without rank set and it is not going away. Example case: Kuusankoski (Q985564). You can fix single ones by setting rank, but it will need automatic handling (=sorting/filtering by qualifiers) too. Anyway, I more or less figured out how WikidataIB works. I made it on purpose that it doesn't show anything if the population parameters were defined because there were multiple rows already with their internal logic and handling that seemed to be pretty complicated and it was hard or impossible to add wikidata stuff to existing logic and keep the wikicode still readable. I didn't use the suppressfields because it suppressed also fields with empty value, "", and not just parameters with content. --Zache (talk) 17:13, 17 March 2019 (UTC)
@Zache: I was answering "Known issues are that with Module:WikidataIB you you can only ask "preferred" value and if there is no preferred value defined" which is simply untrue.
For population (P1082) of Kuusankoski (Q985564):
{{#invoke:WikidataIB |getValue |P1082 |qid=Q985564 |fwd=ALL |osd=no |qual=ALL}} → 20,835 (1999), 20,656 (2000), 20,604 (2001), 20,457 (2002), 20,392 (2003), 20,337 (2004), 20,247 (2005), 20,178 (2006), 19,831 (2007)  
What problem are you trying to solve?
Suppressfields is supposed to suppress any value for a field, by definition. Why would you not want it to do that?
You can't make a robust implementation of an infobox if you try to suppress a field by setting an empty value. That became obvious six years ago with the earliest implementations of Module:Wikidata. Editors used to regularly add a set of blank parameters to an article and then ask why there's nothing coming from Wikidata, You'll also get the cases where you really want to suppress a field deliberately in a particular article. If you use |field= to try to do that, editors will come along and take it as an invitation to fill in the field with a local value, even when there's long standing consensus not to. Example: genre on Night (book).
The readability of code in templates is of small concern, as readers and most editors never see the code. Mike Peel doesn't write Lua, but was able to create a general purpose infobox for Commons {{Wikidata Infobox}} that is fully internationalised. --RexxS (talk) 18:12, 17 March 2019 (UTC)
Infobox cant print list of values (20,835 (31 December 1999), 20,656 (31 December 2000), 20,604 (31 December 2001), 20,457 (31 December 2002), 20,392 (31 December 2003), 20,337 (31 December 2004), 20,247 (31 December 2005), 20,178 (31 December 2006), 19,831 (31 December 2007)) as population because result is public outcry. Anyway the thing what i am to do is to get the wikidata population field to to template:Infobox settlement without getting instantly reverted because public outcry. --Zache (talk) 18:22, 17 March 2019 (UTC)
The readability of code in templates is of small concern, as readers and most editors never see the code - just commenting on this. I strongly disagree (as almost any coder in any language would). Readability of code is very important as it allows others to fix/update other people's code more easily without spending hours just understanding it. --Gonnym (talk) 08:59, 18 March 2019 (UTC)
@Gonnym: Please don't quote me out of context. The point is that writing complex code in a template using parser functions, etc. already makes code difficult to read. When you consider whether or not to add Wikidata calls to already complex code, then I maintain that the issue of readability is a very weak reason not to do it. That is because the only people affected are the relatively small group who maintain that template, not the vast majority of readers and users who may benefit from the change. Do you strongly disagree with that? If you think the code I write is difficult to understand, then please let me know and I'll do my best to improve its readability. --RexxS (talk) 12:15, 18 March 2019 (UTC)
I don't think I quoted you out of context, but if I did, I didn't mean to anyways. If the argument was that adding wikidata calls to an already complex code written in the template doesn't change the readability in any major way, then I agree. The real issue imo, is that we still do complex and hard to read code in template instead of Lua (yes, I know the arguments of why that is). --Gonnym (talk) 12:50, 18 March 2019 (UTC)
You're exactly right about the real issue. I won't try and read your mind, but for me the only issue is that we currently have more editors able to edit the arcane scripting that we use in templates than can program in Lua/Scribunto. I'm doing my best, a bit at a time, to redress that by teaching Lua to as many students as I can attract to the language, but it will be a long time before the balance has shifted significantly. --RexxS (talk) 17:53, 18 March 2019 (UTC)

Alignment in mobile browsers

Latest comment: 5 years ago4 comments2 people in discussion

Hello, apologies in advance if this has already been brought up. I noticed a small stylistic issue when viewing settlement articles on mobile (specifically Firefox on Android, if it matters). The coat of arms image, and its caption, is left aligned within the infobox, whereas the other images (the main image(s), maps, etc.) are all centre aligned. This stands out to me and looks like a mistake, but I don't know how to fix it myself. Thanks! odg (talk) 13:23, 25 March 2019 (UTC)

odg, I can fix it. basically, the Template:Infobox settlement/columns needs to be changed from using literal html tables to div tags the same as was done here. Frietjes (talk) 21:35, 25 March 2019 (UTC)
odg, let me know if that's better. and someone can feel free to revert my changes to Template:Infobox settlement/columns if I screwed something up, but it looks fine for me in the testcases. Frietjes (talk) 21:48, 25 March 2019 (UTC)
That looks fine now, thanks! And it doesn't appear to have messed anything up on desktop, looks the same to me there. odg (talk) 22:58, 25 March 2019 (UTC)

Wrapper Templates/Guidelines

Latest comment: 5 years ago4 comments4 people in discussion

Howdy all. So as anyone who follows TFDs knows already, there have been a large number of TFDs surrounding the numerous custom wrappers for this template. I wanted to see if we could try to get some guidelines put together on when to create wrapper templates and when not to. I have been one of those in favor of deleting most of these wrappers, but on a number of occasions, other editors have completely turned me around after pointing out some of the useful things the wrappers provide. So I've come to realize that I think we need some sort of guidelines. I'm not talking about establishing new WP policy, but just a set of best practices that we can refer to.

For example, one could argue for the creation of 58 wrapper templates for each of the 58 counties in California that provide the Country of United States, the State of California and then each of the counties in turn... Yes that saves people from having to type in 3 parameters, but that also adds 58 additional wrapper templates to be maintained... I'm pretty sure that most of us can agree that we don't need 58 wrappers for each of the county's in California... But as someone who previously nominated {{Infobox German location}} for deletion, I have been completely turned around to feel that this template actually provides real benefit.

So here is my thought... What if we get a group of 5-10 people on board and try to write up a best practice of when to use them and when not to. If someone comes along and bulk nominates a bunch of these wrappers we can go uh no.... Per best practice documented here this is just fine. And on the flip side, if someone creates a custom wrapper for their county, we can go uh no.... Per best practice documented here this is a no no.

Once we have that document in place, we can then go through all the wrappers once and basically speedily keep those that meet the criteria (not exactly sure how best to do that but we will figure out the specifics later). The end result would be we remove the ones that we all agree aren't helpful, and keep the ones that are. In keeping those ones, we also ensure that any subsequent attempts to delete them must at least note the fact that they have previously been reviewed and determined to meet the criteria for inclusion.

At the moment this is only a half baked idea, but I would be very interested in what others have to say on the mater. Please share any thoughts you have! --Zackmann (Talk to me/What I been doing) 17:00, 26 March 2019 (UTC)

Thanks for raising the issue, Zackmann08. While I think that guidelines are best created by documenting established consensus and best practice, I agree that in cases like this it would be useful to have an informed discussion to produce some workable guidelines. You will perhaps already have seen that I'm not enamoured with the TFD process as a means of generating consensus, mainly because of the relatively low level of participation, and the problems faced by contributors in assessing the actual impact and difficulty of merging a wrapper template into the parent template. Have you considered floating the idea at one of the Village Pump boards to draw in a broader range of opinions than we are likely to get here? --RexxS (talk) 17:42, 26 March 2019 (UTC)
While not a solution I can see ready in the near future, I'm researching the French infobox module code which has a system in place that can make inheritance in infoboxes possible. What that means in practice is that modules can be created that inherit (=uses as default) all the parameters of the base module, which in our case is this one, and can override any parameters they want to create new defaults for - like names for sub_division labels, country, etc. This system is much more flexible than the wrapper system, requires much less maintenance and provides a better editing experience for new and experienced editors. However, as I said, it currently is only in the research stage. --Gonnym (talk) 19:40, 26 March 2019 (UTC)
Fiwiki copied the frwikis infobox system (example: fi:Moduuli:Fr:Infobox/Vuori) so it is definitely doable. Pros are that it is versatile and pretty solid and it does most of the things that are needed. Minus is that there are module dependencies and localization needs code changes. --Zache (talk) 05:32, 27 March 2019 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Infobox_settlement/Archive_27&oldid=901463023"