This is an archive of past discussions about Template:Infobox settlement. 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.
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)
@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)
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)
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)
{{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, 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)
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)
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?
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.
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)
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)
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:
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:
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)
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
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)
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.
Portugal "Portuguese subdivision" 2019-08-27
Merging the only PT-wrappers, each type-specific, Municipality PT and Parish PT into a wrapper that is not type-specific
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. MarkussepTalk14: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.
How can you have two short descriptions? I have read somewhere that only the last short description on any page is used.
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.
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)
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)
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:
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.
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)
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)
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:
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)
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. SounderBruce00: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)
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? Erictalk19: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? Erictalk03:10, 31 January 2020 (UTC)
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)
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)
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)
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)
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? Zerotalk05: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
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. Ellsworthed.put'r there23: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)
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)
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. Ellsworthed.put'r there08: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)
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}}talk05: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}}talk18: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)
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:
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.
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)
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)
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)
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)
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)
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)
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)
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. Nemo07:57, 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)
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)
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)
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)
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)
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:
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)
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)
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 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)
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)
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. —MichaelZ.16:33, 5 October 2020 (UTC)
