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

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)

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)

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)

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)

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)

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

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)

Would someone please fix whatever is showing

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

in these articles:

• Hawsha
• Khirbat Bayt Lid
• Khirbat Zalafa
• Nasir ad-Din, Tiberias
• Qira, Haifa

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)

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)

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

• Property 41 - flag image
• Property 856 - official website
• Property 94 - coat of arms

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...

• Wikidata:Property:P571 - Inception
• Wikidata:Property:P1448 - Official name
• Wikidata:Property:P1813 - Short name
• Wikidata:Property:P1549 - Demonym
• Wikidata:Property:P1082 - Population (need to be able to pull year as well)
• Wikidata:Property:P2044 - Elevation
• Wikidata:Property:P2046 - Area
• Wikidata:Property:P242 - Locator Map

-- 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)

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)

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)