Template talk:Infobox settlement/Archive 29

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 25 ← Archive 27 Archive 28 Archive 29 Archive 30 Archive 31 → Archive 33

Short descriptions

Sub-optimal automatic short descriptions for Polish locations

If you take a look at the article for Szlagnowo, it currently has a short description of "Village in Pomeranian, Poland". This is ungrammatical and incorrect; it should read either "Village in Pomeranian Voivodeship, Poland" or "Village in Pomeranian Province, Poland". Since there isn't a short description template in the article, I imagine it's generated by the infobox template {{Infobox settlement}}. Is there some way I can help with fixing this? -- The Anome (talk) 20:09, 3 August 2019 (UTC)

The Anome, The short description is generated based on the subdivision names and settlement type parameters in the infobox. You could change these parameters to change the description generated by the infobox or you could manually add {{shortdescription}} to override it. Hope that helps! --Trialpears (talk) 20:23, 3 August 2019 (UTC)
@Trialpears: I've just discovered that the magic happens in Module:Settlement short description. It looka to me as though this can all be done in the function cleanUpLoc, with a list of specific replacements such as mapping (for example) "Pomeranian, Poland" to "Pomeranian Voivodeship, Poland". However, some of the voivodeships have the same names as cities, for example Łódź Voivodeship and Łódź, in which case it's not clear what to do with "Łódź, Poland" -- is it the voivodeship or the city being referenced?

I can think of several different quick ways to fix this, of varying degrees of hackiness, but I'd like to do something maintainable rather than a hack. Perhaps passing in more parameters to the module, providing it with the types of subdivision as well as the names, might be the way to go -- it could also be backward compatible, if necessary. I can also see that this could possibly be useful for naming conventions in other countries. @Galobtter: is this something you could advise me on? -- The Anome (talk) 21:06, 3 August 2019 (UTC)

I'm at a loss to understand why the value in the infobox is "Pomeranian", an adjective. I expect an infobox to contain key-value pairs which will normally be nouns or noun phrases. I would therefore expect to see the label (key) "Voivodeship" paired with the data (value) "Pomerania". If we were considering English counties we would write entries like "Country - Lancashire" (noun), not "Country - Lancastrian" (adjective). if we stick with consistent nouns values in the infobox, these problems disappear and we don't need a limitless list of exceptions in the code. Input clean data and keep it simple. --RexxS (talk) 22:20, 3 August 2019 (UTC)
@RexxS: I agree, it seems silly to me too, but this seems to have become the convention for Polish settlement articles. (Compare Irish settlement articles, where the right thing is done: for example Kilcullen, where the county entry is correctly "County = County Kildare" not the awful and very un-Irish "County = Kildare") I could certainly update all the relevant infoboxes with my bot so that "Voivodeship = X" became "Voivodeship = X Voivodeship" in every Polish place article, and this would indeed fix this. (Note that your example above would be wrong, though -- Pomerania and the Pomeranian Voivodeship are two separate things, just like Łódź Voivodeship and Łódź; we would have to use the word "Voivodeship" in every value entry.) I've also noticed that there may be some inconsistency about the use of different conventions for voivodeship names, something I could also fix at the same time. However, we are talking about many thousands of articles to be fixed. and I worry about editors regarding this change to long-established practice as vandalism, and reverting it back: we would certainly need consensus support for this in the relevant editing communities before make the change. -- The Anome (talk) 11:29, 4 August 2019 (UTC)
@RexxS and The Anome:, articles about US places also leave out the type, if the type is in the label. Lincoln, Nebraska: County = Lancaster, not County = Lancaster County. TerraCyprus (talk) 15:52, 6 August 2019 (UTC)
@TerraCyprus: The article on Lancaster County is called "Lancaster County, Nebraska", not "Lancaster, Nebraska", so there's not a lot of consistency in the conventions. It's an unfortunate example, since the county seat of Lancaster County is Lincoln, Nebraska, and there is also a Lincoln County, Nebraska (whose county seat is North Platte, Nebraska). I think it's quite important to maintain disambiguators generally to make things as clear for the readers as possible.
In an infobox, where space is at a premium, we may prefer to write |county = [[Lancaster County, Nebraska|Lancaster]], and the code then has the choice to extract the link name to use for the short description. --RexxS (talk) 16:34, 6 August 2019 (UTC)
@RexxS: where space is at premium, see Rio Branco, Acre: Region = North, not Region = North Region. The inclusion of the type name seems to be managed differently between sets of articles, or maybe even within such sets. TerraCyprus (talk) 17:00, 6 August 2019 (UTC)
@TerraCyprus: If you look closely it's actually |subdivision_name1 = [[North Region, Brazil|North]], so the full link name is given (but not displayed), just as I said above. --RexxS (talk) 17:07, 6 August 2019 (UTC)
@RexxS: I saw it, but if I understood correctly the described issue is related to text display not the link targets. The Polish articles also have "Voivodeship" in the link. TerraCyprus (talk) 17:21, 6 August 2019 (UTC)
@TerraCyprus: The issue is what text goes into the short description. If the full link name is supplied to the infobox – whether it's displayed or not – the code that creates the short description has a choice of using that instead. --RexxS (talk) 17:26, 6 August 2019 (UTC)
@RexxS:, you wrote "Input clean data and keep it simple." as if the Polish data is not clean. I just pointed out that display is also shortened for US and Brazilian articles. I just didn't find another example with an adjective yet. And you wrote "where space is at a premium" - doesn't seem to be the reason for the Brazilian region name, as North Region fits well into one line. TerraCyprus (talk) 17:45, 6 August 2019 (UTC)
@TerraCyprus: Do you disagree with the principle of inputting clean data and keeping subsequent programming simple? The Polish data is not clean, because we are using a made-up translation of województwo pomorskie where someone has chosen to use the adjective "Pomeranian", rather than the more usual noun "Pomerania". I merely drew attention to the inconsistency of that practice compared with the far commoner conventions in English such as "Lancashire county". If the translators had chosen "province" instead of "voivodeship", I'm sure we would be using "Pomerania Province". After all, we manage to have an article titled "List of placenames in the Province of Pomerania". The point being that whenever we depart from the normal conventions, we run the risk of an algorithm that makes use of the data throwing out ungrammatical phrases such as "Village in Pomeranian, Poland" because it expects the subdivision to be a noun, not an adjective. From that point of view the data is not clean. One solution is to write extra code that catches exceptions and amends them. The simplest way, of course, is to keep the input data clean and then you don't need to keep on adding extra code to catch exceptions. --RexxS (talk) 18:10, 6 August 2019 (UTC)
@RexxS: Do you disagree with the principle of inputting clean data and keeping subsequent programming simple? - No, do you? The Polish data is not clean, because we are using a made-up translation of województwo pomorskie where someone has chosen to use the adjective "Pomeranian", rather than the more usual noun "Pomerania". - Even if your statement would be true, you have not shown that adjectives are never "usual". Re "List of placenames in the Province of Pomerania" - that is not for the voivodeship, but for an entity of the German Empire, for which the English Wikipedia has the article at Nazi Germany. TerraCyprus (talk) 18:38, 6 August 2019 (UTC)
@TerraCyprus: If you agree with the principle, why are you arguing against it? My statement about the translation is true. I don't need to show a fact is true when it can be seen by inspection. Where are your other examples of a subdivision of a country being referred to in English as an adjective? You need to look closer at List of placenames in the Province of Pomerania: it most certainly applies to modern entities, Read the text: "The lists include: name; ... Gemeinde (German municipality) today; Amt (German district) today; Landkreis (German county) today; Polish name today (if east of the Oder-Neisse line); Gmina (Polish municipality, if east of the Oder-Neisse line) today; Powiat (Polish county, if east of the Oder-Neisse line) today. The specific list, List of municipalities in the Province of Pomerania, A–Z which has column headings for "Polish name today", etc. I'm pretty sure we are using "Province of Pomerania" to include województwo pomorskie in those cases. It's just a pity we don't use the same formula elsewhere. --RexxS (talk) 21:02, 6 August 2019 (UTC)
@RexxS: If you agree with the principle, why are you arguing against it? I am not, please be more careful if you accuse others. Where are your other examples of a subdivision of a country being referred to in English as an adjective? ... in the short form... Province : Western. TerraCyprus (talk) 21:44, 6 August 2019 (UTC)
The Anome, I think passing in the type of subdivision and adding "Voivodeship" if the subdivision_type is "Voivodeship" and the subdivision_name does not already end with Voivodeship would be the best way of doing it (assuming we aren't fixing the values to be nouns instead of adjectives) Galobtter (pingó mió) 21:55, 4 August 2019 (UTC)
 Done in Module:Settlement short description/sandbox (can use Template:Infobox settlement/sandbox to test). Looks good? Galobtter (pingó mió) 22:33, 4 August 2019 (UTC)
Galobtter, that looks fantastic, and easily generalizable to other problematic cases if needed. I also think it's much preferable to the alternative of editing thousands of articles. Unfotunately, I've just tried it on Szlagnowo, and it doesn't seem to have made a change. I wonder if this is a caching issue? Purging the page didn't seem to help. -- The Anome (talk) 16:05, 6 August 2019 (UTC)
The Anome, see the edit history of the sandbox template - someone used it for their own testing in the meantime. Galobtter (pingó mió) 19:59, 6 August 2019 (UTC)
Can test on Template:Infobox settlement/sandbox2 Galobtter (pingó mió) 20:46, 6 August 2019 (UTC)
Galobtter: Thank you! I did a couple of spot-checks, and all looks good. I think this is ready to go; could you please make this change to the production template also? -- The Anome (talk) 10:10, 7 August 2019 (UTC)
Belated  Done Galobtter (pingó mió) 04:26, 20 August 2019 (UTC)
Galobtter Thank you! It seems to be mostly working: see the bug report by Johnuniq below, however. -- The Anome (talk) 09:21, 21 August 2019 (UTC)

Ciechanowiec

{{Infobox settlement}} at Ciechanowiec is displaying "Lua error in Module:Settlement_short_description at line 101: bad argument #1 to 'find' (string expected, got nil)." That is because at line 101 of Module:Settlement short description, x is 2 and subdivision_names[2] is nil. There are various ways to fix that, the best of which presumably would be to fix the article so its parameters are correct. However, it would be nice if the module handled the situation with a more meaningful result. Sorry I haven't got time to investigate further. Galobtter might be best to fix it. BTW, the new p.assign function should use local for val and var. Is p.assign intended to be used from outside the module? If not, I would make the function local (remove p.). Johnuniq (talk) 07:40, 21 August 2019 (UTC)

@Johnuniq: would you mind moving this, as a subsection, to the section #Sub-optimal automatic short descriptions for Polish locations? TerraCyprus (talk) 08:55, 21 August 2019 (UTC)
@Galobtter: I can confirm that this is still failing. -- The Anome (talk) 09:24, 21 August 2019 (UTC)
Johnuniq, Lua module definitely shouldn't give that sort of error. I am busy though, and as this seems to be the only article affected (per search), I'll fix this later. Also, thanks for the catch regarding missing locals. Galobtter (pingó mió) 05:55, 22 August 2019 (UTC)
@Galobtter: as this seems to be the only article affected (per search) How did you search for this? TerraCyprus (talk) 11:55, 22 August 2019 (UTC)
Errors of that nature are shown at Category:Pages with script errors. You can also use the standard Wikipedia search. Johnuniq (talk) 23:24, 22 August 2019 (UTC)
 Fixed Galobtter (pingó mió) 06:20, 23 August 2019 (UTC)
@Galobtter: Thank you! That's fantastic work. -- The Anome (talk) 07:20, 23 August 2019 (UTC)

Type check and short description

There are

  1. Category:Pages using infobox settlement with bad settlement type (6,001) - as of writing containing 4,868 items
  2. Module:Settlement short description - filling the former and creating the short description; template-protected and programmed by Galobtter

Galobtter: Why are there that many items in the category? And why are you circumventing your own code in the Alabama article? [1].

Does central management of the short descriptions for articles that use {{Infobox settlement}} make them more consistent? Why not for U.S. states? TerraCyprus (talk) 09:43, 20 August 2019 (UTC)

Findings: All items in the tracking category that I checked had a type that looked fine to me and each was composed, e.g. "neigborhood of ...", "district of ...", i.e. more accurate than in many infoboxes. Something isn't just of type "state", but it is a U.S. state, or a Mexican or Brazilian state. Even more diverse might be the things translated as "district". In many cases the type is linked to an article providing more information about the type, if the label is only "district" the reader may expect a general article about "district" not about districts of India. TerraCyprus (talk) 10:02, 20 August 2019 (UTC)

The code doesn't always generate the best possible description, so overriding it is necessary. Regarding the category - in my view having "neightborhood of ..." etc is redundant and pollutes the field, and makes it so that there is special code for generating the short description. Galobtter (pingó mió) 02:35, 21 August 2019 (UTC)
@Galobtter:
  1. The code doesn't always generate the best possible description, so overriding it is necessary. - Maybe improve the code if it fails on the not that obscure U.S. states?
  2. my view having "neightborhood of ..." etc is redundant and pollutes the field - on what is your view based? d:Propert:P31 also stores the real type and not just some "district". Dozens, maybe hundreds or thousands of editors in the English Wikipedia did so too.
TerraCyprus (talk) 08:51, 21 August 2019 (UTC)

Module:Settlement short description - transclusion outside Infobox settlement

transclusion count:

That means that Module:Settlement short description is transcluded on pages that don't transclude the Infobox. According to WhatLinksHere Infobox musuem, church, hospital transclude it too, It seems the inclusion is done via the Module:Type in location, also coded by Galobtter. TerraCyprus (talk) 09:36, 21 August 2019 (UTC)

Coordinates fallback wikidata

Template:Infobox U.S. metropolitan area has

| coordinates = {{if empty|{{{coordinates|}}}|{{#if:{{#property:P625}}|{{coord|format=dms|display=inline}}}}}}

Could that be activated for Infobox settlement? 77.183.50.1 (talk) 10:23, 5 June 2019 (UTC) // @Hike395: could you help? 77.183.50.1 (talk) 10:31, 5 June 2019 (UTC)

Wikidata fallback also found in {{Infobox U.S. county}} 

| coordinates             = {{ifempty|{{{coordinates|}}}|{{#if:{{#property:P625}}|{{coord|format=dms|display=inline}}}}}}

TerraCyprus (talk) 12:06, 23 August 2019 (UTC)

Government blanks

Please sync with this version of the sandbox where I added government blanks for use in wrapper templates. See discussion at Template talk:Infobox U.S. state#New Infobox format, not a fan. --Trialpears (talk) 16:40, 29 August 2019 (UTC)

Pinging @Izno and Frietjes: since you likley didn't see this uncontroversial request hiding among the others. (sorry) --Trialpears (talk) 06:26, 4 September 2019 (UTC)
okay, done. Frietjes (talk) 14:06, 6 September 2019 (UTC)

Largest city, largest metro

{{Infobox U.S. state}} has largest city and largest metro, more generalized that could be 

| part1_label = [[List of U.S. states' largest cities by population|Largest city]]
| part1_data  = {{{LargestCity|}}}
| part2_label = [[List of Metropolitan Statistical Areas|Largest metro]]
| part2_data  = {{{LargestMetro|}}}

This then can also be used for other places outside the US. Another option, more restrictive: 

| part_largest1_label = [[List of U.S. states' largest cities by population|Largest city]]
| part_largest1_data  = {{{LargestCity|}}}
| part_largest2_label = [[List of Metropolitan Statistical Areas|Largest metro]]
| part_largest2_data  = {{{LargestMetro|}}}

TerraCyprus (talk) 18:27, 6 August 2019 (UTC)

@Trialpears: this may solve the US state box problem. I made no edits in the sandbox yet, because other changes are still waiting to be implemented. TerraCyprus (talk) 21:42, 6 August 2019 (UTC)

TerraCyprus Yep I would definitely support this as well. --Trialpears (talk) 21:53, 6 August 2019 (UTC)
seat1 probably has been misused in other cases too, this could then be corrected. TerraCyprus (talk) 21:56, 6 August 2019 (UTC)

Virginia has the parameter LargestCounty in {{Infobox U.S. state}}, which is not supported by that infobox. TerraCyprus (talk) 14:24, 9 August 2019 (UTC)

"name" and "info" as in the blank fields. 

| part1_name = [[List of U.S. states' largest cities by population|Largest city]]
| part1_info = {{{LargestCity|}}}
| part2_name = [[List of Metropolitan Statistical Areas|Largest metro]]
| part2_info = {{{LargestMetro|}}}

This diff : [4], but should be done after the time zone related edit request above. TerraCyprus (talk) 19:48, 9 August 2019 (UTC) - strike since the next is applicable. TerraCyprus (talk) 16:36, 11 August 2019 (UTC)

Frietjes fixed my numbering and prepared the Infobox settlement (inserting numbering gap). So it is this diff now [5] TerraCyprus (talk) 11:50, 10 August 2019 (UTC)
@Frietjes: could you implement that one? It helps converting the infoboxes U.S. state and U.S. county to correct wrappers. Also it comes before and therefore may block the other #Edit request - literacy rate and sex ratio. TerraCyprus (talk) 11:51, 12 August 2019 (UTC)
TerraCyprus, normally, I see largest city/metro in |seat1=, is there a problem with using that parameter? Frietjes (talk) 17:54, 18 August 2019 (UTC)
Yes, that there is only one extra seat parameter so largest metro and largest city can't be conveniently displayed at the same time. My preffered outcome would just be adding another seat parameter. --Trialpears (talk) 18:27, 18 August 2019 (UTC)
okay, now done. Frietjes (talk) 13:08, 19 August 2019 (UTC)
Not done. A largest city or largest metro is not the same as a seat. TerraCyprus (talk) 14:26, 19 August 2019 (UTC)
TerraCyprus It doesn't matter. An extra seat parameter is more versatile and displays the field where it belongs. The largest city is not a seat argument is of the same form as the "a region isn't a settlement" argument. --Trialpears (talk) 14:34, 19 August 2019 (UTC)
Trialpears, of course it does matter, stop trolling and come with arguments. If someone is interpreting the parameters by their name, they are mislead. Tools brake. "An extra seat parameter is more versatile and displays the field where it belongs." - Stop trolling, or if you are interested in an honest discussion then explain how "seat2_" is more versatile than "part1_ ". TerraCyprus (talk) 14:39, 19 August 2019 (UTC)

@Frietjes: Sorry, didn't see your question. There are entities that have two seats, for them there is |seat= and |seat1=. But seats are only special kinds of parts of an entity. In the /doc there is 

<!-- seat, smaller parts -->
| seat_type               = <!-- defaults to: Seat -->
| seat                    =
| seat1_type              = <!-- defaults to: Former seat -->
| seat1                   =
| parts_type              = <!-- defaults to: Boroughs -->
| parts_style             = <!-- list, coll (collapsed list), para (paragraph format) -->
| parts                   = <!-- parts text, or header for parts list -->
| p1                      =
| p2                      = <!-- etc., up to p50: for separate parts to be listed-->

"Largest metro", "largest city", "largest county", "other cities" (all seen during the last two months) are not seats, they are just another type of parts of an entity. TerraCyprus (talk) 17:55, 20 August 2019 (UTC)

{{Infobox U.S. county/sandbox}} has: 

| parts_type              = Other cities
| parts                   = {{{other_cities|}}}

TerraCyprus (talk) 12:24, 23 August 2019 (UTC)

 Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. Going to put a 'needs consensus' here to get this out of the queue and because at least one person otherwise has disagreed that the changes in this part are good. Izno (talk) 03:35, 7 September 2019 (UTC)

Demographics - literacy rate and sex ratio

Literacy rate and sex ratio (Human sex ratio) are common parameters in demographic information systems. Two parameters could be added so that the information does not end up in blank parameters anymore or in case of wrappers is mapped to such blank parameters and in both cases is displayed in inconsistent places in the infobox: 

 | population_literacy_rate      = 
 | population_sex_ratio          =

Suggested prefix is "population_" as that is, with the exception of some "pop_", the prefix used for all other non-blank population/demographics parameters. TerraCyprus (talk) 14:54, 11 August 2019 (UTC)

Examples from infoboxes

Data is stored in different blank fields (blank, blank1, blank2) and sections (sec1/sec2) and in different ways, e.g. sex ratio, defined in the article human sex ratio as male/female:

Case Arjuni-Morgaon taluka

| population_blank2_title = [[human sex ratio|Sex ratio]]
| population_blank2       =  935

Case Waraseoni

| blank_name_sec1                 = [[human sex ratio|Sex Ratio]]
| blank_info_sec1                 = 1019
| blank1_name_sec1                = [[Literacy Rate]]
| blank1_info_sec1                = 80%

Case Mangalore

| blank_name_sec1                 = [[human sex ratio|Sex ratio]]
| blank_info_sec1                 = 1016<ref name="census2011.co.in"/>
| blank1_name_sec2                = Literacy
| blank1_info_sec2                = 94.03%

Case Shrirampur

| blank1_name_sec1       = [[Human sex ratio|Sex ratio]]
| blank1_info_sec1       = 51%-49% [[male|♂]]/[[female|♀]]

Case Malappuram district

| blank1_name_sec1        = [[Human sex ratio|Sex ratio]]
| blank1_info_sec1        = 1096 [[male|♂]]/[[female|♀]]
| blank2_name_sec1        = Literacy
| blank2_info_sec1        = 93.55%

Case Kerakat

| blank2_name_sec1        = [[Human sex ratio|Sex ratio]]
| blank2_info_sec1        = 1000/943 [[male|♂]]/[[female|♀]]

Case Himachal Pradesh

 | blank_name_sec2                 = [[Literacy in India|Literacy]]
 | blank_info_sec2                 = 83.78%<ref name="Census 2011A" />

Case Uttar Pradesh

| blank1_name_sec2                = [[Literacy in India|Literacy]] {{nobold|(2011)}}
| blank1_info_sec2                = 67.68%<ref name="pc-census2011" />
| blank2_name_sec2                = [[Human sex ratio|Sex ratio]] {{nobold|(2011)}}
| blank2_info_sec2                = 912 [[females|♀]]/1000 [[males|♂]]

Literacy rate


Wikidata:

TerraCyprus (talk) 11:27, 9 August 2019 (UTC)

Sex ratio

Edit request - literacy rate and sex ratio

[6]

The parameters did exist in infoboxes of which the wrappers have been replaced with Infobox settlement. They either got deleted or are in blank parameters in the demographics section for which the display position is not standardized, or even worse, often in some of the general blank parameters, which are displayed away from the population/demographics section (see above: #Examples from infoboxes). This is an attempt to display the two parameters, provided data is available, in a predictable manner and predictable position. TerraCyprus (talk) 13:28, 11 August 2019 (UTC)

This change would be helpful for fixing inconsistencies especially in Indian infoboxes. Also, if {{Infobox India district}} is replaced this week, it would avoid extra work, if before replacement it is changed to use the new parameters. TerraCyprus (talk) 11:51, 12 August 2019 (UTC)

 Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. Same deal here; this edit request is a month old at this point. Izno (talk) 03:37, 7 September 2019 (UTC)

Wikivoyage link

Although there is a link in the side bar when a Wikivoyage page exists, this is not always obvious to the occasional reader. As Wikipedia is often the first stopping point for visitors going to a settlement, as a tourist or on business, it would be useful to also direct them to Wikivoyage for additional information not covered by Wikipedia. I would therefore like to propose an additional row with a link to the Wikivoyage page. I have added code to the sandbox with a proposed format. Would like to have peoples comments on the suggestion and any ideas for improvement. --Traveler100 (talk) 06:58, 7 October 2019 (UTC)

In addition to the sidebar, this is also covered by the sister project links at the bottom of the article. I don't see a strong case at this point for adding a third link. Nikkimaria (talk) 11:36, 7 October 2019 (UTC)
The sister project requires a pro-active edit to every relevant page. I suppose could do a bot update but would take some effort compared to simple update to template to get onto every possible page. --Traveler100 (talk) 15:25, 7 October 2019 (UTC)
I agree with User:Nikkimaria, we don't need a 3rd link, just like we didn't agree to adding a Commons link. (IMO, it is already way too large...) -- P 1 9 9  ✉ 17:14, 7 October 2019 (UTC)

Frustrating our editors

We should try to do a better job in helping our editors. Just now an editor self-reverted their change of a population figure[7] because it didn't result in any change in the published article. You and I know that this field is populated from Wikidata, and can not be overruled even if you have better information available (like was the case here). While this is bad enough in itself, it gets worse when nothing indicates this, as far as I can see. The infobox has no indication that all or some of its values come from Wikidata, the template documentation (the specific Italian comune one, or the general one here) don't indicate this either: all you get is that when you edit the article, beneath the edit box some Pnumbers are given, without indication what they mean.

Can we please, when we fetch data from Wikidata, try a few things?

  • Update the template documentation
  • Indicate the Wikidata origin in the infobox (though discreetly and text based, not with the glaring but unintuitive Wikidata logo)
  • Allow a method to override the Wikidata information with local information

This would avoid editor frustration and allow better information in our articles. Fram (talk) 10:29, 8 October 2019 (UTC)

I am super confused. I don't see how Wikidata is being included from the template side at all. The documentation claims it uses Wikidata. @RexxS: Am I blind? --Izno (talk) 20:37, 9 October 2019 (UTC)
The article in question uses {{Infobox Italian comune}}, a customized wrapper for {{Infobox settlement}}. That wrapper template has a note that it uses population and area data, although the documentation could be clearer that if a wikidata value is present, local values will be ignored. – Jonesey95 (talk) 21:17, 9 October 2019 (UTC)
Ah, so a 3rd mostly-general-purpose module (Module:Wd). Yes, the problem is mostly that most infoboxes using Wikidata should use Module:WikidataIB (or an acceptable coding using one of the other modules), and that one does not. --Izno (talk) 21:22, 9 October 2019 (UTC)
Thanks. I didn't even notice the small box on the right side stating that they take these parameters from Wikidata, some form of banner blindness I suppose. But at least this means that it was in the documentation after all, only not in the most obviuos place perhaps. Any ideas who best to contact to improve the working of this template (the Italian one)? Fram (talk) 07:03, 10 October 2019 (UTC)
Any infoboxes should pull from the article first, and then from WD if the data isn't there. I'll look into modifying the Italian commune IB. Primefac (talk) 13:38, 10 October 2019 (UTC)
Thanks! Fram (talk) 13:46, 10 October 2019 (UTC)

Redirecting, renaming of wrapper templates, not type-specific, not country-wide

@Gonnym, Pigsonthewing, TerraCyprus, Darwinek, and JelgavaLV: Despite several cases of opposition and knowing about it, Markussep, is pushing forward with creating new settlement wrapper templates without any discussion in relevant talk pages, even redirecting/repurposing type-specific ones to new creations that are not type-specific. Then using AWB to edit hundreds of pages, so that any user not having AWB would have a hard time to revert his unilateral actions.

I request that Markussep reverts these unilateral changes. 89.14.167.121 (talk) 13:36, 19 September 2019 (UTC)

What I have been doing is combining existing wrappers that were dedicated for different types of subdivisions in the same country (Portugal and France). I think synergy is achieved here, because the same functionality can be applied for different types of subdivisions. And yes, it can be used for types of subdivisions that were not covered by dedicated wrappers yet, for instance the intermunicipal communities of Portugal (these didn't have infoboxes yet). My goal is to improve the quality and the ease of maintenance of the infoboxes. Apparently the anonymus (who is probably the same as 78.54.44.99, 89.12.52.186, 77.183.43.199, 78.55.183.179, 77.183.172.102 and many more) has a problem with that. I am not aware of any guideline against the creation or modification of Infobox settlement wrappers. Markussep Talk 14:31, 19 September 2019 (UTC)
Markussep, when will you revert your unilateral, contested, mass changes implemented without prior discussion? You have been involved with TfD, why did you think for PT and FR you can circumvent that? 78.54.192.129 (talk) 17:19, 15 October 2019 (UTC)

Short description

The infobox automatically generates a Short description, which can be overridden by entering |short_description= but the infobox fails to check if there is an independent {{short description}} template in the article and you end up will 2 short description entries. It should suppress the automatic generation if these is a {{short description}} template in the article. Keith D (talk) 00:02, 30 October 2019 (UTC)

Nothing like this is supposed to happen, for multiple reasons.
  1. Module:Settlement short description uses, or attempts to use, the "noreplace" parameter documented at {{Short description}}, so any local short description in the {{short description}} template should override the |short_description= parameter.
  2. How can you have two short descriptions? I have read somewhere that only the last short description on any page is used.
  3. I have been unable to make the |short_description= parameter actually work, but that is probably my failing. Can you demonstrate your concern by linking to a page that shows the problem you describe? – Jonesey95 (talk) 02:12, 30 October 2019 (UTC)
Update: I see that Brussels, for example, has a |short_description= parameter set to |short_description=Region of Belgium with 19 municipalities, including Brussels City, and the {{short description}} template has the description set to "Capital region of Belgium". The actual short description used by Wikipedia is "Capital region of Belgium", which says to me that the "noreplace" option in the infobox is working (i.e. the infobox lets the {{short description}} template override the infobox's description). I think. If you are seeing a problem with a specific article, please link to it here. – Jonesey95 (talk) 02:41, 30 October 2019 (UTC)
I am seeing the problem on the article you mention that shows both short descriptions. which gives

Capital region of Belgium

Region of Belgium with 19 municipalities, including Brussels City

I am using following in common.css to see the short discription if that makes any difference.

.shortdescription { display:block !important; background-color: #FFFF80; }

Keith D (talk) 11:57, 30 October 2019 (UTC)
With that line added to my .css, I am seeing doubled short descriptions at Brussels and Boston also. I have asked for help at Wikipedia talk:Short description. – Jonesey95 (talk) 20:25, 30 October 2019 (UTC)
It doesn't matter what you are seeing, the actual short description is "Capital region of Belgium". --Gonnym (talk) 20:43, 30 October 2019 (UTC)
How can you tell what it is? - You only know by what you are seeing. May be we should stop adding it by infobox templates and just use the simple {{Short description}} template as that is simple and can be seen in the wikicode. Keith D (talk) 23:23, 30 October 2019 (UTC)
It looks like the preferred way to show the short description is to use the Shortdesc helper gadget instead of the .css modification. – Jonesey95 (talk) 00:47, 31 October 2019 (UTC)
You can also check the page information. Also May be we should stop adding it by infobox templates and just use the simple {{Short description}} - no. --Gonnym (talk) 06:56, 31 October 2019 (UTC)

Should "Anthem" be changed to "Anthem(s)"?

Replace Anthem: with Anthem(s):. – Illegitimate Barrister (talk • contribs), 02:37, 30 October 2019 (UTC)

This sounds reasonable, but please link to an article where a settlement has more than one anthem listed. Are there other parameters that we should change at the same time? – Jonesey95 (talk) 02:44, 30 October 2019 (UTC)
Florida. – Illegitimate Barrister (talk • contribs), 02:46, 30 October 2019 (UTC)
Let's discuss that first. Some of us think that "xxx(s):" is unattractive and Florida seems good without the ugliness, and multiple anthems would be rare. Johnuniq (talk) 03:10, 30 October 2019 (UTC)
For what it's worth, Florida's infobox shows this:
Nickname(s): The Sunshine State
Motto(s): In God We Trust[1]
Anthem: "Old Folks at Home" and "Florida"
It seems inconsistent to show "(s)" for the first two and not for the third. – Jonesey95 (talk) 03:26, 30 October 2019 (UTC)
How about we remove "(s)" from all of them!? Let's leave this for 48 hours and see if any other opinion arise. I've changed the heading from a standard edit request in an attempt to attract more attention. After that time, and if there are no other objections, you might like to make the change to add "(s)". Johnuniq (talk) 04:01, 30 October 2019 (UTC)
Yes, we should remove the "(s)", but there are some tracking categories that we (the consensus at this talk page, at least) agreed to clear out first. See this discussion from a year ago. The upshot of this discussion is that we should add |anthems= as a valid parameter.
The tracking categories are Category:Pages using infobox settlement with possible demonym list (2,960), Category:Pages using infobox settlement with possible motto list (2,345), and Category:Pages using infobox settlement with possible nickname list (1,393). – Jonesey95 (talk) 04:27, 30 October 2019 (UTC)

I prefer Jonesey95's proposal. Somebody please go and make the change. Illegitimate Barrister (talk • contribs), 00:19, 24 November 2019 (UTC)

References & Time zone

References breaks Wikilink — Abdrashitovo, Duvansky District, Bashkortostan --AlexKozur (talk) 09:53, 28 December 2019 (UTC)

I have adjusted the template's documentation. References can go in the time zone parameter. – Jonesey95 (talk) 16:53, 28 December 2019 (UTC)

Only a talk archive using dot map

Currently it seems there is only one page listed at Category:Pages using infobox settlement with a dot map, however it's a user talk archive. Not sure if you wish to stop tracking at this point or if it's possible to whitelist that page. Jerod Lycett (talk) 20:31, 1 January 2020 (UTC)

Must City Council members meet notability for inclusion in the infobox for U.S. Council-Manager cities?

Cities like El Paso, Texas have a list of City Council members which I think is exactly appropriate for the Council-Manager form of government but I’ve been editing Washington State cities’ settlement infoboxes adding the correct form of government for each city and the names of their city manager and their council members but I've been getting reverted. I’m a subject matter expert on municipal government but admittedly I am an entry-level marginally-competent Wikipedia editor and don’t know the protocol of how to appeal or adjudicate this. I'd like to get some definitive guidance so I don't waste my time and I'd appreciate any advice. One common misconception is to list the mayor as a leader when in fact under Council-Manager (as the name implies) the City Council members are the part-time legislative body of which the mayor simply chairs the meetings and appears ceremonially as needed but the City Manager is the city’s executive. In Mayor-council the mayor IS in fact the chief executive to whom the city’s functional department heads all report to on a daily basis. But for council-manager cities, the mayor is "merely" one of the 7 or so council members so should be listed with perhaps (mayor) next to their name, as Orange, California, Allen, Texas and El Paso, Texas have done. It's also silly to omit City Manager from a Council-Manager form of government and then list the mayor so I'd like to be part of getting this right. Seriously, this is textbook government structure stuff. I will also argue that, for that particular city, the elected council members are notable to the residents of that city, which can be several thousand people for whom Wikipedia is where they might look it up not knowing how to navigate a city's website (and some small cities have some pretty primitive websites). Most folks aren’t capable of editing the infobox to customize the correct form of government for a given city but once set up correctly many more folks can easily edit to update for election results. By the way cities like McKinney, Texas that use the collapsable list for city council look really well thought out and I'd like to incorporate that going forward, it fits council-manager perfectly. I also see that referencing the city’s website in the infobox also provides a simple and authoritative path to check anytime one wishes and that’s a great idea. 1958publius (talk) 02:48, 12 January 2020 (UTC)

@SounderBruce and 1958publius: Can I suggest bringing the disagreement to WT:WikiProject Cities? I think that would bring in a broader set of interested editors. — hike395 (talk) 05:04, 12 January 2020 (UTC)
Thanks for guidance, but I have no idea how to do that. Would like to contribute to every city going state by state - have no idea where the rules of the game are so I can play well. I don't have a lot of time to devote, as you can see from my history I often go months without time to spare then put in bursts of concentrated effort with a cookie cutter applied to score of similar cities. If I could get clarity I'd sign on to a few of the Western States' WikProject focusing on the Government Section and the settlement infoboxes and little else. Lead on. 1958publius (talk) 05:24, 12 January 2020 (UTC)
The issue has been brought up at Wikipedia talk:WikiProject Cities#Infobox clutter. SounderBruce 07:37, 12 January 2020 (UTC)
@1958publius: Guidelines for the contents of all instances of {{Infobox settlement}} are generally discussed at WT:WikiProject Cities. Hopefully we can come to a consensus about whether we should list City Councilmembers in the infobox, or not. SounderBruce has started the discussion already at Wikipedia talk:WikiProject Cities#Infobox clutter. Publius, I would recommend going to that other Talk page and explaining your position. Hopefully, you would draw on various Wikipedia guidelines and policies in support. — hike395 (talk) 18:05, 12 January 2020 (UTC)

native_name_lang

Hello. native_name_lang parameter doesn't work. Can you check my sandbox for it. --Drabdullayev17 (talk) 10:11, 10 January 2020 (UTC)

It looks fine to me. If you paste your code into Special:ExpandTemplates, you will see that the native name is wrapped with a span tag that includes lang="az". Here's the whole thing, expanded:
<table class="infobox geography vcard" style="width:22em;width:23em"><tr><th colspan="2" style="text-align:center;font-size:125%;font-weight:bold;font-size:1.25em; white-space:nowrap"><div style="display:inline" class="fn org">Gabala</div><br /><div class="nickname" style="font-weight:normal;display:inline;" lang="az">Qəbələ</div></th></tr></table>
Is that different from what you were expecting? – Jonesey95 (talk) 15:19, 10 January 2020 (UTC)
Hi Jonesey95 I mean if I wrote | native_name_lang = az parameter didn't add anything to infobox. It is useless. Don't have any function. Do you understand me? (P.S. I am so sorry for my bad English.) --Drabdullayev17 (talk) 11:27, 16 January 2020 (UTC)
Drabdullayev17 It is not supposed to have any rendered effect. It makes sure the browser uses the correct font and that it's pronounced correctly for screen readers. You can read more at Template:Lang/doc#Rationale. ‑‑Trialpears (talk) 12:05, 16 January 2020 (UTC)
Trialpears thank you for explanation. --Drabdullayev17 (talk) 12:08, 16 January 2020 (UTC)

Inconsistency with eastblished parameters

Just noticed something a little strange: when using established_title and established_date are used alone, there is no separating line, but for established_title1 and established_date1 there is. I suggest having the line appear on all uses of the former to be consistent and properly separate history from the subdivision fields. SounderBruce 00:35, 16 January 2020 (UTC)

I agree it needs to be fixed. I use the following as an initial starting point in my infoboxes. If "established_date" is blank, but text exists for "established_date1" or "established_date2", then a line isn't drawn. This problem typically happens when I know the incorporation year, but I don't know the founding year. As a work around, if there are enough clues, I might set "established_date" to a decade, such as "1870s" until someone nails down an exact year. • Sbmeirow • Talk • 22:45, 16 January 2020 (UTC)
  • <!-- Established -->
  • established_title = Founded
  • established_date =
  • established_title1 = Platted
  • established_date1 =
  • established_title2 = Incorporated
  • established_date2 =
  • named_for =

New parameter for French regions

Hello all- I just added a prefecture to the infobox at Bourgogne-Franche-Comté. I did this via the parameter "seat1", which I discovered with some effort here. I think it would be better if we added "prefecture" as a parameter. I would just do it, but I'm not sure how, and thought I should run it by others. Anyone have thoughts on this? Eric talk 19:20, 30 January 2020 (UTC)

It generally does not make sense to add a parameter to this widely used template that is useful in only a handful of articles. It makes more sense to establish a standard way of using the existing parameters in those articles and to publish that standard in a suitable WikiProject's style guide, or to create a template wrapper for this infobox that applies the parameters correctly. For an example of a wrapper that does a variety of automatic setting of parameter values, see {{Infobox French subdivision}}. – Jonesey95 (talk) 23:14, 30 January 2020 (UTC)
Thanks, yes, I was looking at that before I posted here, hoping to find some guidance. I take your point about maintaining the general-purpose focus of this infobox template. So do you think my solution at the above article is a good approach? And if so, would that be something to note somewhere? Eric talk 03:10, 31 January 2020 (UTC)
Whatever approach you use, it should be the same across all articles for the regions of France. – Jonesey95 (talk) 06:27, 31 January 2020 (UTC)

Adding Homeless Population

Hi, I am trying to do a project to raise awareness about homelessness in various cities. As many people read wikipedia, I thought it would be a good place to start. The easiest place to put the homelessness information where it belongs would most likely be in the infobox, next to population, but it's locked, and sadly has no parameter for homeless population. Could somebody help me with adding it in, enabling me to put it on many city pages easily? Thank you! --Navrha1 (talk) 23:45, 1 March 2020 (UTC)

Please see WP:NOTADVOCACY and MOS:INFOBOXPURPOSE. – Jonesey95 (talk) 01:35, 2 March 2020 (UTC)
There is already too much stuff in the infobox. If you want to add info, add it to the demographics sections. • Sbmeirow • Talk • 02:33, 2 March 2020 (UTC)

Third time zone parameter needed

For the article Kenora District, there are two time zones in the district which observe daylight savings time, and one which doesn't (Pickle Lake and Mishkeegogamang First Nation). Could someone add a third parameter to accommodate a third time zone?--Molandfreak (talk, contribs, email) 01:06, 10 April 2020 (UTC)

Area magnitude

back in 2013 all of the individual area order of magnitude pages were redirected to Orders of magnitude (area) as far as I can tell. since then, I have seen all kinds of stuff put in the |area_magnitude= field, most of it has not been that helpful (in my opinion). do we still need this field? if we need it, couldn't the link be more automatically determined so it points to the best place to avoid the need for individual editors to guess at what to put there? Frietjes (talk) 15:07, 13 April 2020 (UTC)

Spacing issue

Caption

It's somewhat bugged me for years, there's been an issue of absolutely 0 spacing between images (noticeably flags, seals, and other emblems) and their captions. This can be seen in articles like New York City and Columbus, Ohio. How can this be fixed? Thanks and best, ɱ (talk) 05:58, 5 May 2020 (UTC)

I see four white pixels between the top of the F in "Flag" and the New York City flag. Perhaps you could experiment in the sandbox and illustrate what you would prefer on the testcases page. – Jonesey95 (talk) 14:25, 5 May 2020 (UTC)
I am not a template editor, even looking at the code, I have no idea how to do that. And are you saying you don't see the issue at all, or just that you see spacing for just that one flag? Surely you can see that even if some minute spacing exists, it's not comparable to the caption spacing for [[File:example.jpg|thumb|Caption]]. ɱ (talk) 14:48, 5 May 2020 (UTC)
I was just saying that I didn't see "absolutely 0 spacing" between the flag and its caption; I saw a small amount of white space. If you see the caption immediately adjacent to the flag, post a screen shot. The effect might depend on your browser, font settings, or some other effect based on your computer or your WP user settings. In the meantime, I'll take a look at the template code to see what might be possible to increase the spacing. – Jonesey95 (talk) 16:59, 5 May 2020 (UTC)
Alright. I typically use Chrome, and even not logged-in, and testing on Firefox, there's almost no spacing. Though I tested it on mobile Chrome and there is plenty of spacing there. ɱ (talk) 17:11, 5 May 2020 (UTC)
OK, compare the first few test cases at Template:Infobox settlement/testcases, especially Linares and Detroit. I added some padding above and below the flag/seal/etc. captions. It's only a little more; I didn't want to go nuts with it. If you want to see how it looks in New York City, edit the top section and put "/sandbox" after "Infobox settlement", then click Preview (not Publish) to see the difference. – Jonesey95 (talk) 17:15, 5 May 2020 (UTC)
Looks a lot better to me, thanks! Is there a way to do it for the pushpin maps too, for Linares and NYC it really shows. (NYC's interactive map spacing is fine though). ɱ (talk) 17:18, 5 May 2020 (UTC)
 Done. I have updated the live template with this little bit of padding. The template was using line breaks for spacing, which is not really appropriate, since rendering is inconsistent across browsers, as you observed. I have also updated {{location map}} to add the same amount of caption spacing above the location map caption. – Jonesey95 (talk) 18:05, 5 May 2020 (UTC)
Thank you! ɱ (talk) 18:09, 5 May 2020 (UTC)

Question

How to add this on a new draft Preetikasingh (talk) 03:46, 9 May 2020 (UTC)

Preetikasingh, edit the page you want to add it to, copy and paste Template:Infobox_settlement#Short_version to there, and fill in the parts that are relevant to the draft. Nikkimaria (talk) 12:47, 9 May 2020 (UTC)

Geoshapes

Hi, I have started adding geoshapes of Portuguese civil parishes (freguesias) to Commons. They are also being linked to the respective Wikidata items. I then changed the template at ptwiki to include this map in the infobox of the freguesia. I think it would be great to include it here as well, but I am not sure if the change is welcome here. You can see an example at the bottom of this article: pt:Bruçó. GoEThe (talk) 16:14, 25 May 2020 (UTC)

In many cases, there are already too many maps added to the infobox, making it excessively long. Best to "hide" it like the OSM map (similar to your example) that is already included in the infoboxes of municipalities in Italy and the Philippines (see for example: Muggia and Malabon). -- P 1 9 9  ✉ 16:50, 25 May 2020 (UTC)

Embedding is a repeated issue

Hi all - most infoboxes allow others to be embedded onto them, though this heavily-used one apparently doesn't. Looking at the talk page history, people have mentioned this issue plenty of times. One workaround recommended for French Quarter was to use the 'footnotes' parameter, though it leaves many undesirable horizontal lines (likely why it was not applied there). The article Old Oaks Historic District similarly could make use of having an 'embedded' parameter, so I could add its designation on the Columbus Register of Historic Properties (for now I am using 'footnotes', you can see the problem there). Thanks and best, ɱ (talk) 21:59, 8 May 2020 (UTC)

User:Ɱ, the additional rules are caused by the geography class, but there is a workaround, and that is to add the option for modules to be embedded in a subbox that doesn't have the geography class. for example, this change in the sandbox results in this rendering. if there are no objections, I will add this |module= parameter to the main infobox code. Frietjes (talk) 21:43, 25 May 2020 (UTC)
Thanks, looks good! ɱ (talk) 21:59, 25 May 2020 (UTC)
User:Ɱ, okay, now implemented. Frietjes (talk) 15:21, 26 May 2020 (UTC)
Thanks so much. ɱ (talk) 15:28, 26 May 2020 (UTC)

Ordering and mouse-over

Frequently I see, in an article, a reference to a location, and I mouseover it, hoping to see a map to find out where it is, and usually the first image is something utterly useless: a picture of a building or a flag or something. Would rearranging this template so that the map is first make mouse-overs more useful? I'm not quite clear how that works. 70.131.48.56 (talk) 16:55, 2 June 2020 (UTC)

It sounds like this could be an improvement to either Wikipedia:Tools/Navigation popups or mw:Page Previews, depending on which one you have enabled (the former is enabled in Gadgets, and the latter is in Appearance). Since you are not a logged in user, I'm guessing that you are using Page Previews. It looks like that feature simply pulls the first image from the article, which is a little clunky. I don't think we should change the layout of every infobox just to accommodate this feature. Maybe Page Previews should have a feature that allows target pages to choose which image is displayed in the Preview pop-up. – Jonesey95 (talk) 17:58, 2 June 2020 (UTC)

expand utility of image_map argument

Sometimes there is an excellent map available for a settlement, but it covers such a wide area that the settlement itself is near-invisible when the map is put in the infobox using "image_map". Please see Al-Zahiriyya al-Tahta as an example. A great solution would be for the thumb in the infobox to show only the neighborhood of the settlement, but for the whole map to appear when the thumb is clicked on.

Outside the context of the infobox, the "annotated image" template can do this.

See the example on the right and try clicking on it. How hard would it be to provide this capability in the inbox, either by expanding the use of image_map or otherwise? Zerotalk 05:02, 19 June 2020 (UTC)

I think the easiest way to do this would be to crop that image, easily using a tool like CropTool. Then you could do something like this:
| image_map               = [[File:19-26-Safad-1942 (cropped).jpg|frameless|200px|link=File:19-26-Safad-1942.jpg]]
| map_caption             = Al-Zahiriyya al-Tahta on the 1945 Survey of Palestine map; click image to view full map
Best, ɱ (talk) 05:40, 19 June 2020 (UTC)

Template-protected edit request on 26 July 2020

Something goes wrong with the link to the flag on Victoria, Gozo. It links to dablink Flag of Victoria, while it should not link to a page at all. There is no page for this specific flag. I've checked the page source itself, and I suspect an error in the template or the Template:Infobox settlement/link template. Pyrite Pro (talk) 10:06, 26 July 2020 (UTC)

To editor Pyrite Pro:  done – in the Victoria, Gozo infobox, I introduced the |flag_link=National flag parameter and linked to National flag. If you think of a better link, then feel free to change it. Thank you for catching this! P.I. Ellsworth  ed. put'r there 22:46, 26 July 2020 (UTC)
To editor Pyrite Pro: the documentation led me to another solution, which I will leave up to you. If "Victoria" is removed from the |official_name= parameter, then the flag link is removed and all that remains is the unlinked "Flag". (You will also have to remove the |flag_link=National flag parameter.) Thanks again! P.I. Ellsworth  ed. put'r there 23:05, 26 July 2020 (UTC)
To editor Paine Ellsworth:  Resolved Per your suggestion, I removed the official name (and flag link), as it did not really have any additional value in this case. Nice suggestion, and thank you for your help! Cheers, Pyrite Pro (talk) 06:56, 27 July 2020 (UTC)

Coastline length parameter suggestion

@Trappist the monk and WereSpielChequers: On the Matsu Islands page, I just added a set of parameters in the infobox about total coastline length in kilometers based on a newly added source, following the way coastline length is handled in Template:Infobox_islands. I do not really have the technical knowledge to add this paramater to Infobox settlement, but I would like to suggest it be added. Geographyinitiative (talk) 06:15, 23 August 2020 (UTC)

Hi Geographyinitiative I don't have the technical knowledge either. Maybe @Paine Ellsworth: can help? ϢereSpielChequers 07:49, 23 August 2020 (UTC)
The coastline length os a famous example (I believe the first known one) of a fractal. It is infinite. I do not think it makes any sense to include it.--Ymblanter (talk) 07:58, 23 August 2020 (UTC)
See How Long Is the Coast of Britain? Statistical Self-Similarity and Fractional Dimension--Ymblanter (talk) 07:58, 23 August 2020 (UTC)
To editors Geographyinitiative and WereSpielChequers: well, I don't quite know what to do about this. It would probably be easy enough to add the parameters, however now it looks as if a consensus is needed. The fractal issue raised by Ymblanter seems like a valid concern, although if island coastlines can be measured and included in {{Infobox islands}}, then I don't see why mainland coastlines shouldn't be included in this ibox. I could be wrong. P.I. Ellsworth  ed. put'r there 08:53, 23 August 2020 (UTC)

When they create the outer limits of a territorial sea, it is based on the coastline. However, that boundary is not infinitely long because it is based on basepoints connected by straight lines. My guess is that the coastline length is derived in a similar manner. Geographyinitiative (talk) 09:13, 23 August 2020 (UTC)

To editor Geographyinitiative: this ibox has the |module= parameter, which when set as it is at Template:Infobox settlement/testcases#Case 15: Matsu Islands, can embed another template as shown. The only difference is that the "Infobox settlement/testcases" that titles the embedded coastline info at the bottom of the template on the testcases page actually reads as "Matsu Islands" on the Matsu Islands article page. P.I. Ellsworth  ed. put'r there 12:04, 30 August 2020 (UTC)

Having trouble sectioning blank fields

For Claremont, California, I tried to add transit access in its own section, but the bars at the top/bottom sectioning it off haven't materialized. The sec1 and sec2 in |blank_name_sec1= etc. don't seem to be working. Help? {{u|Sdkb}} talk 05:17, 8 September 2020 (UTC)

I am seeing "Commuter rail" rendering fine, as described in the documentation (The name is displayed in bold on the left side of the infobox.). Do you have a link to an article that is displaying these parameters in a different way? – Jonesey95 (talk) 14:12, 8 September 2020 (UTC)
@Jonesey95: the issue is that I'm not seeing any gray horizontal bar above or below commuter rail to separate it into its own section, as should be happening per the documentation (and as would be appropriate, since transit access is a different sort of thing than FIPS number). At Beijing it's working properly, with a horizontal bar between abbreviation and city trees. Does that clarify? {{u|Sdkb}} talk 18:50, 8 September 2020 (UTC)
@Sdkb: if you skip |blank_name_sec1= and go directly to |blank1_name_sec1= you don't get the horizontal divider. to fix this, you just shift the number[8] but, would probably look better to have the rail information after the codes (in my opinion). Frietjes (talk) 19:33, 8 September 2020 (UTC)
Frietjes, I just rearranged as you suggested. Thanks! {{u|Sdkb}} talk 19:46, 8 September 2020 (UTC)

Non-standard links for time in wrapper Infobox province or territory of_Canada

Template talk:Infobox province or territory of Canada#Timezone: misleading linking in wrappers. Is there some higher level rule to prevent this? I would expect that timezone_link (not numbered) is the most specific for entity described in the article/infobox. That means for Nunavut it would be Time in Nunavut and not Time in Canada. 77.191.9.108 (talk) 23:12, 12 September 2020 (UTC)

Why not more wikidata?

Wikidata could be a great way to populate fields, especially those subject to periodic updates like census data. Having done some experimentation I've successfully implemented wikidata calls in this IB as follows:

population_total = {{wikidata|property|P1082}}

population_as_of = {{wikidata|qualifier|P1082|P585}}

population_footnotes = {{wikidata|reference|P1082}}

website = {{wikidata|property|P856}}

This means that as long as wikidata is up-to-date, so will this be. It could also extend the pool of editors who can update the data, since wikidata is shared across many languages. The French wikipedia equivalent IB is implemented such that any param left blank will automatically pull the value from wikidata.

I'm puzzled as to why this IB does not make more use of wikidata. --Cornellier (talk) 18:03, 21 June 2020 (UTC)

as long as wikidata is up-to-date - that's exactly the issue. There have been concerns and issues in the past (on various IBs) that WD doesn't have the anti-vandalism measures seen on enwiki, and there's no way to verify the accuracy of the values imported. Primefac (talk) 18:20, 21 June 2020 (UTC)
Concerns and issues sounds anecdotal. Is there any data on this? There is a Wikidata:WikiProject Counter-Vandalism. --Cornellier (talk) 19:17, 21 June 2020 (UTC)
Some projects are using WD more extensively. See, for example, the ca. 1870 transclusions of {{PH wikidata}}. Plastikspork ―Œ(talk) 19:30, 21 June 2020 (UTC)
I wouldn't call it anecdotal, given there have been multiple discussions (including a TFD and RFC) about the use of WD in {{infobox person}}, the result of which was (to paraphrase) that WD shouldn't be used in the IB in articles. I would also argue that it explains why it hasn't yet been implemented, not necessarily that it's the reason why it shouldn't be used. Primefac (talk) 15:00, 22 June 2020 (UTC)
{{infobox person}} is a whole nother kettle of fish. I'm proposing it be used more in this IB. Also, just a a data point, WD is currently being used AFAIK on every WP page that has links to articles on other language wikis. Doesn't seem to be problematic. It's also used by many pages to link to OSM and create very nice maps, for example New York City. --Cornellier (talk) 20:22, 22 June 2020 (UTC)

I agree it is high time to start linking to WD. This is a great tool. The so-called reasons not to use it are just excuses, any such issues can be addressed in the same way they were and are addressed here. -- P 1 9 9  ✉ 16:23, 22 June 2020 (UTC)

support here for using wikidata. --Zache (talk) 17:22, 22 June 2020 (UTC)

There is an outdated experiment at Template:Infobox settlement/Wikidata that someone could improve upon using modern tools like Module:WikidataIB. See {{infobox person/Wikidata}} for a more modern implementation, with documentation and explanations. – Jonesey95 (talk) 19:59, 22 June 2020 (UTC)
Here I give a good example why Wikidata should not be used.--Ymblanter (talk) 18:54, 1 July 2020 (UTC)
This isn't an argument against, the proposer and others agree that unverifiable information should not be used. Unsourced data can be scrutinized and removed or corrected as need be. ɱ (talk) 19:15, 1 July 2020 (UTC)
It must be filtered out automatically, just not show here. Until this is done, it does not make sense to import anything serious.--Ymblanter (talk) 19:25, 1 July 2020 (UTC)
I disagree; I'm skeptical that really any vandalism spreads to Wikidata, and that we can't deal with problems of content/sourcing like we always have... ɱ (talk) 19:43, 1 July 2020 (UTC)
I replied at that discussion. The Wikidata calls being used there were failing to account for sourcing. – Jonesey95 (talk) 19:44, 1 July 2020 (UTC)
And here's another instance of bad Wikidata info being used in en.wp. It's by no means the only example I've found involving geographic coordinates. In the vast majority, if not all, of the cases of Wikidata coordinates I've looked at, they're sourced (if they're sourced at all) to individual language Wikipedias, not to reliable independent sources. I'm against the indiscriminate importation of coordinates from Wikidata. Deor (talk) 19:49, 1 July 2020 (UTC)
Again, that is not an argument against importing from Wikidata because the majority of coordinates on en.wp are likewise not sourced to reliable independent sources. You are holding Wikidata to a higher standard than what we expect on en.wp. -- P 1 9 9  ✉ 14:11, 2 July 2020 (UTC)
Granted, but one goof-up on en.wp can't infect every Wikipedia around the world. Goof-ups on Wikidata are inherently viral. Deor (talk) 14:17, 2 July 2020 (UTC)
The simplest thing to do is just add the Wikidata items to your watchlist... -- P 1 9 9  ✉ 14:21, 2 July 2020 (UTC)
If anything, Wikidata is better for this because you can add a citation to it. Coordinate templates on Wikipedia don't offer that option. ɱ (talk) 15:11, 2 July 2020 (UTC)
There is no reason why a WP coordinate template used in an infobox cannot have a citation, other than generally we prefer not to have cites in those things anyway. - Sitush (talk) 17:53, 2 July 2020 (UTC)
Re. the statement "geographic coordinates [are sourced] to individual language Wikipedias". Actually the "sourcing" is that the data was imported from WP in the first place. So it's no better nor worse than WP. The solution to concerns about vandalism and verification is to keep the data in one place, not many, so it's easier to maintain. --Cornellier (talk) 17:44, 2 July 2020 (UTC)
Did you look at the link in my first post, six posts above? I've learned through experience that discussion with Wikidata fans is futile, so I'll post no further here. Deor (talk) 17:50, 2 July 2020 (UTC)
One could do without the ad hom. --Cornellier (talk) 18:12, 2 July 2020 (UTC)
The reasons for not using more from Wikidata have been discussed to death in past RfCs etc and, as far as I am aware, the concerns then raised remain. - Sitush (talk) 17:53, 2 July 2020 (UTC)
Another data point: {{infobox bridge}} "If there is no [map] then a dynamic map will be displayed in its place if the article's Wikidata item [...] has a coordinate location". So it populates the infobox with a map without any editing in the Wikipidia page. --Cornellier (talk) 19:41, 4 July 2020 (UTC)
I don't understand why there is so much back and forth when someone could be actively working on the outdated experiment at Template:Infobox settlement/Wikidata, which someone could improve upon using modern tools like Module:WikidataIB. See {{infobox person/Wikidata}} for a more modern implementation, with documentation and explanations. If you think wikidata could work for settlements, that is your best avenue for demonstrating that it could work. – Jonesey95 (talk) 00:28, 5 July 2020 (UTC)
Because not everybody is familiar with lua programming?--Ymblanter (talk) 11:40, 5 July 2020 (UTC)
As far as I know, there is no Lua code in {{Infobox person/Wikidata}}. You may have to read the documentation at Module:WikidataIB if simple copying and pasting of examples in the person infobox doesn't work for settlements, but you don't have to learn to program. – Jonesey95 (talk) 14:33, 5 July 2020 (UTC)
Fair enough. I'll see what I can hack together as a prototype. --Cornellier (talk) 15:25, 5 July 2020 (UTC)

The simplest first step here is to default to the Wikidata image when none is provided. I see that users had to manually add thousands of images from Wikidata to articles about small villages as part of m:WPWP, quite a waste of time. Nemo 07:57, 10 September 2020 (UTC)

leader_party1

Please add "leader_party1", absence produces error at New South Wales. 77.191.249.65 (talk) 20:02, 10 September 2020 (UTC)

There is no such parameter in this template. Use |leader_party=. – Jonesey95 (talk) 22:14, 10 September 2020 (UTC)
"There is no such parameter in this template." - That is why the request has been made. "Use |leader_party=." - but not for values which should be stored in leader_party1. 77.191.249.65 (talk) 01:14, 11 September 2020 (UTC)

I've worked out what 77.191 is saying. The template has |leader_name= with corresponding |leader_party=. It also has |leader_name1= but there is no corresponding |leader_party1=. This may be an omission from when leader_name1 was added to the template. — Martin (MSGJ · talk) 12:42, 11 September 2020 (UTC)

Previously requested in 2008: Template talk:Infobox settlement/Archive_8#Leader Party
77.191: I suggest you code it in the sandbox. Note that there are parameters up to leader_name4 so would it make sense to add parties for all? — Martin (MSGJ · talk) 12:48, 11 September 2020 (UTC)
Okay, so from my read of the /doc, |leader_name= is meant to be for a single leader, whereas the numbered |leader_nameX= are meant to be for collapsed lists (see Example 2 or Halifax). In other words, they're set up completely differently. Gonna close the request for the moment until we figure out what we "want" to do (i.e. consensus). Primefac (talk) 13:56, 11 September 2020 (UTC)
The current code:
 | rowclass55 = mergedrow
 | label55 =  • {{{leader_title}}}
 |  data55 = {{#if:{{{leader_title|}}}|{{{leader_name|}}} {{#if:{{{leader_party|}}}|({{Polparty|{{{subdivision_name}}}|{{{leader_party}}}}})}}}}
 | rowclass56 = mergedrow
 | label56 =  • {{{leader_title1}}}
 |  data56 = {{#if:{{{leader_title1|}}}|{{{leader_name1|}}}}}
 | rowclass57 = mergedrow
 | label57 =  • {{{leader_title2}}}
 |  data57 = {{#if:{{{leader_title2|}}}|{{{leader_name2|}}}}}
 | rowclass58 = mergedrow
 | label58 =  • {{{leader_title3}}}
 |  data58 = {{#if:{{{leader_title3|}}}|{{{leader_name3|}}}}}
 | rowclass59 = mergedrow
 | label59 =  • {{{leader_title4}}}
 |  data59 = {{#if:{{{leader_title4|}}}|{{{leader_name4|}}}}}
To have leader[1-4]_ behave different from leader_ is inconsistent with behaviour of other parameters and there are instances where leader1_ has been used for a sincle human and not a list. 77.191.9.108 (talk) 22:52, 12 September 2020 (UTC)
If folks want to add it, I certainly can. I can't guarantee it but I suspect the current structure is due to a merge at some point in the past. Primefac (talk) 15:48, 13 September 2020 (UTC)

It is also needed for Canada, maybe Nikkimaria can say more about it. I saw it at least on one of the 13 provinces/territories. 77.191.9.108 (talk) 22:39, 12 September 2020 (UTC)

Timezone3 timezone4

Please add two more, Nunavut has four, see Time in Nunavut. Ontario has three. 77.191.9.108 (talk) 22:42, 12 September 2020 (UTC)

 Not done: please make your requested changes to the template's sandbox first; see WP:TESTCASES. It is not clear that there is consensus for this change, but I can imagine that it would be useful. The sandbox version of the template is currently synced with the live template. The rows will need to be renumbered to insert a third and fourth time zone. – Jonesey95 (talk) 00:16, 13 September 2020 (UTC)
fine, but don't close the request. Re "but I can imagine that it would be useful" - the article Nunavut is currently broken. So, it has nothing to do with imagination. 77.11.42.242 (talk) 02:39, 13 September 2020 (UTC)

 Not done: please make your requested changes to the template's sandbox first; see WP:TESTCASES. [...] Jonesey95 (talk) 00:16, 13 September 2020 (UTC)

* Pppery * it has begun... 02:40, 13 September 2020 (UTC)
fine, but don't close the request. Re "please make your requested changes to the template's sandbox first" - no. It is very easy to do for people that can move the numbers, I cannot. And it is a waste of time, if not implemented. 77.11.42.242 (talk) 02:39, 13 September 2020 (UTC)
 Not done: please make your requested changes to the template's sandbox first; see WP:TESTCASES. — Martin (MSGJ · talk) 09:35, 14 September 2020 (UTC)

Timezone3 timezone4 timezone5

Code in sandbox, testcase added. Please explain how to do renumbering of parameters. TerraCyprus (talk) 22:08, 15 September 2020 (UTC)

@Plastikspork: thank you. Did you use a tool for renumbering? I tried infoboxgap.js but it changed much more, maybe because there is a gap somewhere. TerraCyprus (talk) 22:28, 15 September 2020 (UTC)
Yes, I used "infoboxgap.js" You just have to make sure you insert the gap at the correct number. Plastikspork ―Œ(talk) 23:29, 15 September 2020 (UTC)
Plastikspork, in the tools section I have "Infobox gap" and "Infobox renumber". I used "Infobox renumber", and near #50 their is a gap, that is why so much changed, but maybe that gap is there for some future code. So, probably one clicks "Infobox gap" six times to increase the numbers at the end by 6? TerraCyprus (talk) 10:49, 16 September 2020 (UTC)
TerraCyprus, in this case you would gap it 6 times starting at 131, 132, 134, ... since you wanted to insert 6 lines starting at 131. If you gap it at 1 it will shift all the numbers, not just the place where you want to add lines. Thanks! Plastikspork ―Œ(talk) 12:15, 16 September 2020 (UTC)

Pages to be adjusted after the requested change is implemented:

TerraCyprus (talk) 12:07, 16 September 2020 (UTC)

@Plastikspork: do you think it can be taken live now? I will then also volunteer to adjust related templates and articles. TerraCyprus (talk) 12:35, 16 September 2020 (UTC)

TerraCyprus, look fine to me. I typically wait a couple days for comments, but someone else might implement it sooner. Thanks! Plastikspork ―Œ(talk) 12:36, 16 September 2020 (UTC)
ProcrastinatingReader, you just edited some time parameters in a wrapper. Maybe you can have a look here? TerraCyprus (talk) 01:05, 18 September 2020 (UTC)
If you're just looking to add a couple more UTC parameters then it's just a case of copying and pasting I believe. Looks fine to me at a very quick glance, but I've not enough familiarity to be confident in implementing this change myself. ProcrastinatingReader (talk) 02:48, 18 September 2020 (UTC)
TerraCyprus, I updated the template code as requested. Thanks! Plastikspork ―Œ(talk) 12:54, 18 September 2020 (UTC)

Overlapping text

In Martadi, the English title of the infobox overlaps with the native name (in Nepali, I guess). Is this common for similar scripts, and can it be avoided? kennethaw88 • talk 05:21, 25 September 2020 (UTC)

@Kennethaw88: Others use hacks, e.g. Nanporo, Hokkaido
{{Infobox settlement
| name = {{raise|0.2em|Nanporo}}
| official_name = 
| native_name = {{lower|0.1em|{{nobold|南幌町}}}}
| native_name_lang = ja
would prefer it is done in Infobox settlement directly. TerraCyprus (talk) 14:05, 25 September 2020 (UTC)

Template-protected edit request on 26 September 2020

Can someone please add the TfM tag to be added to the top of this template because there's currently a discussion about merging {{Infobox province or territory of Canada}} with this template? -- PK2 (talk) 09:42, 26 September 2020 (UTC)

 Not done: While normally we would put the TFD notice on both templates in a merge discussion, the only possible outcomes of this discussion would either be "no change" or "merge into IB settlement" - since the output of this template isn't going to be affected, there is little reason to add a TFD notice here. I know it's a little IAR, but it also saves essentially unnecessary notices being placed on thousands of articles where it's not necessary. Primefac (talk) 13:12, 26 September 2020 (UTC)

Map wider than 300px

Wack Ngouna Arrondissement 

|image_map              = Nioro du Rip arrondissements.png
|mapsize                =380px

shouldn't there be an upper limit of 300px be programmed into the box? TerraCyprus (talk) 16:00, 27 September 2020 (UTC)

No, because there will always be exceptions. 380 is fine here to ensure at least some legibility, pending the entire map being replaced (which is needed here). ɱ (talk) 16:09, 27 September 2020 (UTC)
"because there will always be exceptions"? Yes, it's an exception, but one contradicting Wikipedia:Image use policy#Infobox and lead images. Why not enforce the policy via code? TerraCyprus (talk) 16:13, 27 September 2020 (UTC)
Because exceptions will always exist, even policies aren't the last word on the subject (WP:IAR). I think the legibility here is more important than some pixel-width rule. ɱ (talk) 16:34, 27 September 2020 (UTC)
But code is the last word. Why does the code allow 300+? TerraCyprus (talk) 15:41, 28 September 2020 (UTC)

Changes to subtemplates to fix Category:Pages with non-numeric formatnum arguments errors

I am making some changes to subtemplates of this template in order to fix Category:Pages with non-numeric formatnum arguments errors. If I have broken any transclusions of this template, all of my changes can safely be reverted back to yesterday's version of the subtemplates. – Jonesey95 (talk) 07:02, 28 September 2020 (UTC)

I think that I have fixed most of the errors. Numbers using commas as decimal separators, in contravention of MOS:DECIMAL, will probably show incorrect numbers. An error-tracking category could be set up for those. – Jonesey95 (talk) 07:17, 28 September 2020 (UTC)
There are some interesting edge cases left, like population references in the population parameters instead of |population_footnotes=, and some odd handling of negative numbers. If they are worth fixing, it will probably be best to set up some tracking categories within this template and its subtemplates, but it is probably best to let the category population decrease via the job queue before digging in to these stragglers. – Jonesey95 (talk) 00:55, 29 September 2020 (UTC)

ISO directions are self-contradictory

Use ISO 639-2 code, e.g. "fr" for French

For French, ISO 639-2 is fra or fre. The code fr is ISO 639-1. I guess 639-1 is correct for this template, and I’ll make the change. —Michael Z. 16:33, 5 October 2020 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Infobox_settlement/Archive_29&oldid=1141945219"