Template talk:Infobox settlement/Archive 25

Archive 20

←

Archive 23

Archive 24

Archive 25

Archive 26

Archive 27

→

Archive 30

Consider Moving Flag and Seal above Image Collage

Many websites pull information directly from wikipedia. As an example, Facebook auto-generates pages for locations using wikipedia images and text. As the pages image, it grabs the first sidebar image availible. For the city project, the template states that an image (or collage of images) should be top on the sidebar. This causes awkward formatting of pages auto-generated from the images. Consider the difference between the New York State Facebook page, which has a clean crest at the top, and the New York City Facebook page, which shows an awkward crop of the image collage. This issue is further exacerbated when the image is shrunk - the NYC image is barely recognizable at a smaller size.

I propose swapping the positions of the image and crest/flag in the template. — Preceding unsigned comment added by Afischer15 (talk • contribs) 16:44, 30 August 2014 (UTC)

Template assistance

I would like someone to augment {{Infobox building}} to have the same multiple pin map option that {{Infobox settlement}} has. I.e., I would like to see both the before and after map of this edit included on the page. Can anyone augment the template for that feature. P.S. the example that I showed in that edit (Broadway_Hollywood_Building) is going on the main page at DYK on the 14th so if the change is not too complicated to copy over, it would be good if it could be done fairly quickly.(--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 19:04, 12 September 2014 (UTC)

auto problem

On page Tagbilaran auto doesn't work. Population is obtained by {{#property:P1082}}. But it doesn't work either if I use a value instead. 112.198.82.1 (talk) 03:58, 11 October 2014 (UTC)

looks like you fixed it. Frietjes (talk) 16:29, 11 October 2014 (UTC)

No I just inserted the hand-cranked answer. 112.198.82.1 (talk) 13:52, 12 October 2014 (UTC)

Named for

"named for" is an Americanism. This template appears on articles where British English is the correct form and the usage should be "named after". — Preceding unsigned comment added by 109.246.135.18 (talk) 19:47, 26 October 2014 (UTC)

Coordinates display

Moved to Wikipedia:Village pump (technical)/Archive 131 § Coordinates display appears to be broken

 – That's where problems like this usually go --Redrose64 (talk) 15:18, 27 October 2014 (UTC)

Template-protected edit request on 27 October 2014

When population density is set as "auto", could you change the template so that it shows the population density at the single digit and not at the next hundred? Currently Template:Infobox French commune uses "auto", and so the large communes of France have their densities showing up at the next hundred, which is rather imprecise. Thank you. Der Statistiker (talk) 23:28, 27 October 2014 (UTC)

Disabled request template, since no specific code change has been supplied; and to allow discussion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:33, 28 October 2014 (UTC)

Bordeaux
Clockwise from top: Place de la Bourse by the Garonne, Allees du Tourny and Maison de Vin, Pierre Bridge on the Garonne, Meriadeck Commercial Centre, front of Palais Rohan Hotel, and Saint-Andre Cathedral with Bordeaux Tramway
Coat of arms
Motto(s):  Lilia sola regunt lunam undas castra leonem. "The fleur-de-lis alone rules over the moon, the waves, the castle, and the lion" (in French: Seule la Fleur de Lys règne sur la lune, les vagues, le château et le lion)
Country	France
Region	Nouvelle-Aquitaine
Department	Gironde
Arrondissement	Bordeaux
Government
• Mayor (2014–2020)	Alain Juppé (UMP)
Area 1	49.36 km2 (19.06 sq mi)
• Urban  (2010)	1,172.79 km2 (452.82 sq mi)
• Metro  (2010)	5,613.41 km2 (2,167.35 sq mi)
Population  (Jan. 2011)	239,399
• Rank	6th in France
• Density	4,900/km2 (13,000/sq mi)
• Urban  (Jan. 2011)	851,071
• Urban density	730/km2 (1,900/sq mi)
• Metro  (Jan. 2011)	1,140,668
• Metro density	200/km2 (530/sq mi)
Time zone	UTC+01:00 (CET)
• Summer (DST)	UTC+02:00 (CEST)
INSEE/Postal code	33063 /
Website	www.bordeaux.fr
1 French Land Register data, which excludes lakes, ponds, glaciers > 1 km2 (0.386 sq mi or 247 acres) and river estuaries.

I cannot supply a specific code since I don't see where exactly inside the template is the setting that makes "auto" density appear at the next hundred. It's perhaps a sub-template used inside this template. Can any admin inquire about this? Look at the Bordeaux infobox below for example. "Auto" makes the population density appears as 4,900/km², when it is in fact 4,850/km². Not very precise for an encyclopedia. Der Statistiker (talk) 12:15, 28 October 2014 (UTC)

Der Statistiker, it always rounds to two significant figures. we can't always make it round to the nearest person/area since there are some places with less than 1. we could have it use more sigfigs (or more for some ranges). I can fix it to do whatever there is consensus to do. Frietjes (talk) 17:31, 2 November 2014 (UTC)

note the code is in Template:Infobox_settlement/densdisp, where it uses "1 - order of magnitude", which is 2 sigfigs. Frietjes (talk) 17:34, 2 November 2014 (UTC)

official_name vs native_name

What's the difference between official_name and native_name at Template:Infobox settlement? There aren't enought details given at Template:Infobox settlement#Parameter names and descriptions. Intrebatorul (talk) 15:04, 10 November 2014 (UTC)

@Intrebatorul: I've expanded the description in the documentation. Let me know if that's still not clear. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:26, 11 November 2014 (UTC)

@Pigsonthewing: I need two clarifications, if possible:

• official_name - The official name in English if different from name; Aren't official names in the official language of the country? (for instance Munchen is in German, not in English)
• native_name - Name in the local language, if different from name; Isn't the local language the same with the official language, meaning that the official name is the same with the native name? Intrebatorul (talk) 14:52, 11 November 2014 (UTC)

@Intrebatorul: Munchen should use |native_name=; as stated, |offical_name = is for English-language names. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:12, 11 November 2014 (UTC)

Adding pronunciation information to template

I have recently started an RfC on whether to add pronunciation information to person infoboxes (not necessarily to move pronunciations to the infobox, but to at the very least give the option). I think in general it would be useful to have the pronunciation in the infobox even if it is in the lead, but it's particularly relevant for names of people and places where the pronunciation might be useful information, but which is not so non-intuitive as to really justify space in the lead (this may be particularly for non-native speakers who may have different intuitions about how a place name would be pronounced and where the emphasis might go). I was thinking it would likely be useful to do the same thing here, re-using the same implementation that will eventually be used at {{Infobox person}} in this infobox. It does not seem to be a very controversial addition over at {{Infobox person}}, so I'm thinking there probably doesn't need to be a separate RfC here. If you have some objections or think a separate RfC is warranted, please let me know. Comments at the RfC are also appreciated. Thanks. 0x0077BE ^{(talk · contrib)} 15:12, 17 November 2014 (UTC)

Removal of dot map function

I would like to propose the removal of the |image_dot_map= since they are generally inferior to |pushpin_map=. the usage has been tracked in Category:Settlement articles with dot maps, which is now empty. in the rare case where it's not possible/desirable to use a {{location map}} you can always pass a call to {{infobox map}} through the |image_map= parameter. removing the |image_dot_map= would simplify the code, reducing the complexity. any objections or comments? Frietjes (talk) 18:46, 25 November 2014 (UTC)

I have no objections to removing obsolete code. CRwikiCA talk 18:54, 25 November 2014 (UTC)

Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:59, 25 November 2014 (UTC)

now removed and I added a check for any non-blank unsupported parameters which will most likely significantly expand Category:Settlement articles requiring maintenance. Frietjes (talk) 16:38, 26 November 2014 (UTC)

Pocahontas County, Iowa

I've been trying to get an image into the infobox there and haven't made any progress. I've left the article with the line

"| image_skyline = File:Pocahontas County Courthouse.JPG" in it, which doesn't show up, but have tried several other variation, e.g. without the "File:"

What am I doing wrong?

Smallbones_(smalltalk) 20:31, 30 November 2014 (UTC)

Smallbones, that article uses {{Infobox U.S. county}}, which is a different infobox. Frietjes (talk) 15:52, 1 December 2014 (UTC)

Fantastic! Smallbones_(smalltalk) 16:09, 1 December 2014 (UTC)

Location map no longer centred

Can this edit by reverted? The location map is no longer horizontally centred. 213.7.22.7 (talk) 12:38, 8 December 2014 (UTC)

@Gadget850: There was already a float parameter set to none on lines 107, 152 and 179. You're gonna have to remove these if |float=center is gonna work. 213.7.22.7 (talk) 12:52, 8 December 2014 (UTC)

fixed. Frietjes (talk) 17:08, 8 December 2014 (UTC)

Thanks: I will keep an eye out for that in the future. --  Gadget850 ^talk 17:14, 8 December 2014 (UTC)

"Auto" density should compute based on land area, not total area

Population density has to do with settle-able area. While there are cities with "houseboat" units, these are never a significant portion of any particular settlement and, if there were such a settlement, it ought to use a different template. I fear that a lot of the listed densities for cities are wrong due to this error. Zelbinian (talk) 07:30, 21 August 2012 (UTC)

100% agree. See Lauderdale-by-the-Sea, Florida whose actual population density is 6,913 persons/sqmi (when calculated based on land area) and not 3,900 persons/sqmi (when calculated based on total area). 70.42.69.221 (talk) 14:15, 21 September 2012 (UTC)

If the land area is given, sure. But if only the total area is known, the template should still display a density. —Stepheng3 (talk) 17:06, 21 September 2012 (UTC)

how about if we add the option for "density_km2 = land" to have it use the land area? Frietjes (talk) 19:28, 21 September 2012 (UTC)

We shouldn't have different instances of this template displaying values calculated using different methods, under the same heading. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:58, 21 September 2012 (UTC)

Reviving this conversation... I agree with Andy Mabbett, yet I must say that this is a valid request, and I think Stepheng3's suggestion is sound – that is, if |area_land_*= is specified, then use it, else use |area_total_*=.

The U.S. Census computes and reports density using land area. Note the following, from Census.gov Geographic Definitions -- Population Density:

"Population and housing unit density are computed by dividing the total population or number of housing units within a geographic entity (for example, United States, state, county, place) by the land area of that entity measured in square kilometers or square miles. Density is expressed as both "people (or housing units) per square kilometer" and "people (or housing units) per square mile" of land area." (emphasis added)

For many communities, the difference is negligible, but for others, this is significant. In Provincetown, Massachusetts, for example, with a 2010 total population of 2,942, a total area of 17.5 sq. miles, and land area of 9.7 sq. mi., the density is being calculated as 168, where it should be 304. Provincetown (CDP), Massachusetts is even more substantial, where the present formula yields a density of 505, when it should calculate to 1479. Anyone have a problem adding an {{edit protected}} request? Grollτech (talk) 18:23, 18 December 2012 (UTC)

Please don't do that until you've found or written code that would permit this. It's a very good idea, but you need to make it plain for non-tech-savvy admins like me. Nyttend (talk) 20:40, 18 December 2012 (UTC)

US Census data is not mandatory for that field. If WP would only show US Census data, it would be much smaller. But the field should show where the value comes from, i.e. "Density (Land)" or "Density (Land+Water)" or show both if there is a diff. NVanMinh (talk) 06:46, 20 December 2012 (UTC)

There's nothing more reliable than the Census Bureau, so we should use Census Bureau results for the fields in question. However, I don't understand why you bring this up here; could you explain why you mention it? Nyttend (talk) 13:40, 23 December 2012 (UTC)

If nobody who's already familiar with this template's code is available to make the change, I'd be happy to go ahead and code the changes in the sandbox. NVanMinh, I understand that U.S. Census data isn't mandatory for the field, and that this is a global (not U.S.-centric) template. However, it is obvious that the 'area', 'population' and 'density' fields within this infobox are based on the Census Bureau's data model. More importantly, as the OP stated, "Population density has to do with settle-able area." This view is consistent with the population density article, which defines biological population density as "population divided by total land area or water volume, as appropriate." Since humans are the subject biota of {{Infobox settlement}}, Land Area is really the only valid basis for computing density. And yet, since this template presently provides the "courtesy" of automatic calcs based on Total Area, it should probably continue to do so, but only if the value for "Land Area" is absent – in that instance, it may be appropriate to annotate the result with something like "(based on Total Area)"? Grollτech (talk) 20:50, 23 December 2012 (UTC)

Infobox settlement
Area
• City	100.105 sq mi (259.27 km2)
• Land	97.915 sq mi (253.60 km2)
• Urban	246.8 sq mi (639 km2)
• Metro	357.9 sq mi (927 km2)
Population  (2010)
• City	466,488
• Estimate  (2011)	477,891
• Density	4,700/sq mi (1,800/km2)
• Urban	1,440,000
• Urban density	5,800/sq mi (2,300/km2)
• Metro	2,600,000
• Metro density	7,300/sq mi (2,800/km2)

{{Geobox|settlement}}

I agree with the suggested change, but to make it simpler I would keep the title Density if calculated based on area_total and use the title Density (land) if calculated based on area_land. I also have two related suggestions that I think should be implemented at the same time:

Suggestion #1: To the far right is an infobox with population_total (for an official census) and population_est (for a more recent estimate). As can be seen in the example (or by examining Template:Infobox settlement/densdisp), the auto density calculation is currently population_total divided by area_total (4660 which the template rounds to 4700), not divided by population_est (4774 which would be rounded to 4800). However, this may not be clear to the reader since the density appears below the estimated population. Therefore I suggest that the density be displayed above the estimate, immediately below the total population, as is done with both the urban and metro population densities (note: Geobox uses a different order, which is all populations first, followed by all densities).

Suggestion #2: The auto density calculation should be rounded to the nearest whole number. In the examples to the right, the auto density calculation in Template:Geobox rounds to 4660 (the nearest whole number) but Template:Infobox municipality rounds to 4700. This is handled in Template:Infobox settlement/densdisp which appears to round the number based on its order of magnitude. If there is no good reason to do this, that code could be simplified to always display a whole number. If there is a good reason to leave it as is, then I suggest the addition of a parameter named population_density_round (such as exists in Template:Geobox) which could override the default rounding for the auto calculated density.

-- Zyxw (talk) 06:47, 29 January 2013 (UTC)

Using this on cywiki (Welsh language)

Hi all. I've added this template in my userspace here, and I think it calls up the map and corresponding template wrongly. I can't find 'Template:Location map Croatia' on en to copy into cy, yet other countries have such a template (eg Argentina template on the page). Secondly, if we need to create 200+ templates, for all countries, can someone please help? PS When creating infoboxes please add translation tips in the doc! Thanks! Llywelyn2000 (talk) 08:09, 31 December 2014 (UTC)

Template redesign feeler

Hello, everyone! Let me preface this with a disclosure that I've never been a great fan of this template, feeling that its bloat and inflexibility often comes in the way of its expansive features and suitability for a great array of needs. While my feelings in that area have not really changed, this time I would like to put out a feeler about a possibility of this template's redesign.

First off, this is neither a call for immediate action, nor a !vote, nor even an RfC, but merely a place to collect other people's thoughts about the proposal which follows. If at any point you see serious problems with this proposal, by all means please post something below. Whatever happens next, this isn't going anywhere until we get the general idea how editors feel.

Proposal

Brief introduction The way this template is currently built is by providing an expansive set of sections dealing with various aspects which may need to be covered in an infobox. All sections are optional and are not displayed when fed no data. While that is great, once a section is fed proper data, it displays them in a particular way and in a particular place; in other words, the template's section order is rigid and unchangeable and same goes for the internal organization of individual sections. While in many situations that does not really matter, in some it creates problems. Problems On some occasions, Infobox Settlement (IS) cannot be used. While many stand-alone templates had been re-designed into IS wrappers over the past few years, there are still a few holdouts for which utilizing a separate template unrelated to IS is a more practical solution. The most common such problems include infoboxes with sections whose formatting is significantly different from what IS provides, where section order is important and different from the section order used by IS, where more than one section of the same type is required, or where IS is missing some very specific section. Modifying IS in its current form to address those problems is often impractical, since it requires adding large chunks of code to deal with only a handful of articles, adding to bloat and confusion. Proposal All of the problems above and more can be addressed by replacing IS (as a catch-all concept) with a set of building blocks handling individual sections and by making sure those building blocks can be seamlessly combined. There would be, for example, a separate template for names, for symbols (flags, coats of arms, anthems, etc.), for maps, divisions, government information, and so on. Benefits Building blocks provide a more manageable solution for customizing the sections, while still supporting overall standardization. Building blocks themselves can be more customizable than IS sections currently are. Discussions dealing with individual building blocks can be consolidated and kept separate from the overall IS discussions, where anything and everything is dealt with all in one place. The building blocks can be combined in any order, which makes possible re-arranging them in cases where order is important. Existing stand-alone templates, many of which currently duplicate much of the IS functionality yet are still kept separate due to the presence of important, but highly specific information, can be re-written using the standard building blocks. Separate, country-specific blocks can be created and plugged only into the country-specific wrappers. Once all of the building blocks are available, IS itself can be re-written to utilize their standard forms. If done correctly, none of the articles currently relying on IS will be affected. Crudely, the IS code (or, indeed, the code of any template using these blocks) will look something like this: {{Infobox settlement|{{Names block|params}}{{Symbols block|params}}{{Maps block|params}}...}} This point is so important, that I'll repeat it: if the proposal is implemented properly, no edits to individual articles will be required, nor will there be any visual change (unless one is desired and provided from within the building blocks themselves). Conclusion Frankly, I'm not seeing any downsides to this solution. The biggest obstacle, of course, is finding volunteers to design the building blocks and to make sure they all fit seamlessly together. The hope is that volunteers will show up if this proposal is favorably received. Please add your thoughts in the Discussion section below, and thank you for your time and consideration!

— Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); November 12, 2014; 22:03 (UTC)

There seems to be no support for this whatsoever. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:45, 17 January 2015 (UTC)

Template-protected edit request on 17 January 2015

Per WP:ACCESS#Text, the minimum permissible font size is 11px. The font size of the image caption is 10.5px, which makes it rather difficult to read indeed. Therefore, I suggest that the caption no longer be enclosed within <small>...</small> on line 88. Alakzi (talk) 15:30, 17 January 2015 (UTC)

Agreed; done. @Alakzi: Does this also apply to captions for coats-of-arms/ shields? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:58, 17 January 2015 (UTC)

Thanks, Andy. It seems to also apply to the map caption. The coat of arms and the shield have got a label, but no caption. Alakzi (talk) 16:46, 17 January 2015 (UTC)

OK, I've done the same for map caption. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:44, 17 January 2015 (UTC)

Instead of removing <small>...</small>, is there not a way to make the font 85% (or 11px)? -- P 1 9 9  ✉ 18:48, 19 January 2015 (UTC)

Request for map grid coordinates fields

In some category of place, especially archaeology, locations are routinely given according to some geographic coordinate system. For example, a place in Lebanon might be at 116/198 in the Levant grid. As far as I can tell, there are no existing parameters suitable for this information (which should be in addition to lat/long and not replacing it). I propose two optional fields:

 grid_name = Levant grid
 grid_position = 116/198

Both fields should allow free text arguments since there are multiple syntaxes in use. The best place for this to appear would be immediately below the lat/long coordinates, perhaps as "Levant grid: 116/198" or on two lines. Can someone implement this (or argue against it) please? Thanks in advance. Zero^talk 06:46, 25 January 2015 (UTC)

I´ll just say +1 to this suggestion. Many of the very best sources for the Middle East uses grid numbers only, it would be extremely helpful to be able to have that in the info box, Huldra (talk) 23:28, 26 January 2015 (UTC)

seems useful, could also be used for Palestine grid, ... will add in a moment since there appear to be no objections? Frietjes (talk) 20:25, 31 January 2015 (UTC)

done and partially updated the documentation (please improve the documentation). now in use in Template:Infobox Palestine municipality. Frietjes (talk) 20:38, 31 January 2015 (UTC)

Should probably also be added to various other infoboxes in Wikipedia:List of infoboxes#Historic sites and structures (if they don't have it already). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:42, 31 January 2015 (UTC)

Also, such grid names should usually be linked; I see we have no Levant grid article - yet. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:43, 31 January 2015 (UTC)

note, this could also be useful for Ordnance Survey National Grid and Irish grid reference system ... if you want to restrict it to a specific list of grids, we could use a switch and do nothing if the particular grid is not in the list (e.g., {{#switch:{{{gridname}}}|Palestine grid=[[Palestine grid]]|OS grid=[[Ordnance Survey National Grid|OS grid]]|...|#default=}}. Frietjes (talk) 21:19, 31 January 2015 (UTC)

Thank you; this is very useful. Also, is it possible to place the same on "Infobox Palestinian Authority muni"? That is basically all the villages on the West Bank, and "Infobox Palestinian Authority municipality" (That´s the towns.)

Could we include it in the Israeli places too? There we need two, Old Israeli grid and Israeli Transverse Mercator. If you look at Archeology-reports from Israel today, like [1], they typically use both. Huldra (talk) 16:51, 5 February 2015 (UTC)

New slogan parameter

This discussion at the Canadian WikiProject has identified a need for a new parameter for slogans to differentiate municipally-adopted official slogans from nicknames that aren't municipally-adopted (i.e., self-applied). Can a new "slogan" parameter be incorporated? Cheers, Hwy43 (talk) 21:20, 1 February 2015 (UTC)

How is a "slogan" differentiated from a "motto"?—Stepheng3 (talk) 20:32, 3 February 2015 (UTC)

According to their articles, a motto is a phrase meant to formally summarize the general motivation or intention of a social group or organization and is often in Latin, whereas a slogan is a phrase used in a political, commercial, religious, and other context as a repetitive expression of an idea or purpose. Key thing here for municipalities is that they often have both a motto (usually in Latin or translated from Latin) and an official slogan (often for marketing purposes). For example, Edmonton's official motto, in English, is Industry, Integrity, Progress, while its official slogan is City of Champions. The motto is found within Edmonton's armorial achievement or heraldic achievement while its official slogan is not. Cheers, Hwy43 (talk) 23:55, 3 February 2015 (UTC)

This distinction is not so clear (or non-existing) for many other countries. Having this extra field will likely create a lot more infobox clutter (most are already unwieldy long) or become another battleground between editors who can't agree on what goes where. Just look at Philippine cities, they are being edited incessantly to add/remove/edit every catchphrase ever used. IMO, a slogan like City of Champions should not be added because it is nothing more than a marketing ploy (see WP:NOTSOAPBOX). -- P 1 9 9  ✉ 14:39, 4 February 2015 (UTC)

I see. I posed this suggestion on behalf of another editor that suggested it at the above discussion, and am not overly attached to absolutely getting a new parameter, but if others do see a need I will beat the drum. Definitely aware of WP:SOAP as are the others at that discussion.
Quick sidebar: Edmonton's City of Champions was actually a nickname for the city first, arising out of its residents' unifying response in the wake of a tragic natural disaster. It was subsequently adopted by the City of Edmonton as an official slogan. Notwithstanding, the vast majority of marketing slogans for other cities were not originally founded as nicknames.
The above discussion is nearly at a consensus that, for Canadian municipality articles, slogans "not be included in the nickname field" ... "unless they are used colloquially by the general population", which will weed out most slogans that are purely marketing ploys.
Cheers, Hwy43 (talk) 07:03, 6 February 2015 (UTC)

Thanks for clarifying that. In fact, it would be nice if, once the issue is resolved at WPCanada, it will become a precedent for other countries... -- P 1 9 9  ✉ 14:45, 6 February 2015 (UTC)

Template-protected edit request

Please put source code of this template between <includeonly></includeonly> tags. --XXN (talk) 00:19, 12 February 2015 (UTC)

Not done: It is standard practice to show the default output on the template page, unless that output is an error message or broken wikicode, etc. This looks like a cosmetic change that would just clog up the job queue for no reason. — Mr. Stradivarius ^{♪ talk ♪} 00:38, 12 February 2015 (UTC)

Please add one more established_title

Please add:
| established_title5 =
| established_date5 =
It is needed for Astana, which was renamed for 5 times.--ChelseaFunNumberOne (talk) 11:40, 18 February 2015 (UTC)

Override "Urban" and "Metro" titles

In the Thessaloniki article, I'd like to link Thessaloniki Urban Area and Thessaloniki Metropolitan Area right from the area and population sections. Currently, the "Urban" and "Metro" titles aren't linked at all in the area section, and they are linked to generic articles in the population section, while the "City" title can be refined using the |total_type parameter. I therefore propose that we introduce additional |area_type and |metro_type parameters to allow overriding default behaviour. --PanchoS (talk) 11:27, 20 February 2015 (UTC)

@PanchoS: It's probably easiest to use area_blank1 and area_blank2 for this. CRwikiCA talk 19:19, 20 February 2015 (UTC)

Requesting fields "established_title5" and "established_date5"

Can someone add a fifth field (or more) for "established" to this template? For example, the article Astana needs it. - Anonimski (talk) 16:23, 21 February 2015 (UTC)

Have you considered whether we need to list the renames in the infobox? Alakzi (talk) 16:26, 21 February 2015 (UTC)

Template-protected edit request on 25 February 2015

Add these three as Sarajevo needs three more spots

| rowclass10 = mergedrow | label10 =  • {{{twin10}}} | data10 =

| rowclass10 = mergedrow | label10 =  • {{{twin11}}} | data10 =

| rowclass10 = mergedrow | label10 =  • {{{twin12}}} | data10 =

Aneditor (talk tome) 03:44, 25 February 2015 (UTC)

• In 2012, there was consensus to remove the twinning parameters from the infobox. I suggest that they are removed. Alakzi (talk) 03:52, 25 February 2015 (UTC)

Not done: please make your requested changes to the template's sandbox first; see WP:TESTCASES. — {{U|Technical 13}} (e • t • c) 13:02, 25 February 2015 (UTC)

Template-protected edit request on 6 March 2015

Please update from sandbox to remove the twin* parameters per the 2012 consensus. Alakzi (talk) 01:12, 6 March 2015 (UTC)

Any take on why this edit wasn't performed three years ago? – Paine Ellsworth^CLIMAX! 11:03, 9 March 2015 (UTC)

John, would you know? Alakzi (talk) 12:27, 9 March 2015 (UTC)

Not done for now: Pending a response to the question at hand. — {{U|Technical 13}} (e • t • c) 01:52, 12 March 2015 (UTC)

It's been nearly four days already; I don't think we're getting one. Is anybody now opposed to this change? Alakzi (talk) 02:05, 12 March 2015 (UTC)

done. Frietjes (talk) 20:10, 12 March 2015 (UTC)

Enabling wikidata

@PC-XT, Jackmcbarn, Mr. Stradivarius, and Unbuttered Parsnip: I have started enabling the ability to pull information from wikidata, and it's almost working. I have started with the coordinates. if you check this version of Madridejos, Cebu, you will see that it is able to correctly render the location map, and it does display coordinates, but the optional args are not being parsed. I imagine this could be fixed with minor changes to module:coordinates? basically, I would like to be able to pass |type=, |format=, and |display=. currently, the automatic wikidata usage is only enabled when |coordinates_wikidata=yes or any nonblank value. it could be useful to make this happen automatically, just by omitting the coordinates from the infobox, but I believe this template has been used in cases where it isn't the primary infobox, so having a flag to turn on the feature seems useful. by the way, if you check the source for Madridejos, Cebu it looks like there is more we could pull from wikidata, but I figured we should start with the coordinates. another option would be to integrate the wikidata feature with {{geobox coor}}? Frietjes (talk) 15:07, 28 February 2015 (UTC)

I'm sick, but I'll try to track down the parameter problem in the next few days, if someone else doesn't do it, first. I'm wondering if switching it to use module:arguments would help? —PC-XT+ 04:04, 1 March 2015 (UTC)

Can the undue precision of coordinates shown in your example be controlled? Is any consideration given to pass parameters like _dim: and _scale:? -- Michael Bednarek (talk) 07:32, 1 March 2015 (UTC)

good question. having the 'format=dms' work will partially address this problem, but it would be good to make this even more robust. Frietjes (talk) 14:53, 1 March 2015 (UTC)

Frietjes, does it work to invoke module:coordinates/sandbox, instead of the main module? I remember fixing a similar issue in that sandbox, but I don't think it was applied. One testcase is failing, now, which I don't remember failing then, so I'm not sure it can be applied until that is explored. I'll try to look at it better, tomorrow. —PC-XT+ 03:54, 4 March 2015 (UTC)

PC-XT, that version seems to work if I pass the type using |3=, see this version of the sandbox. Frietjes (talk) 14:43, 4 March 2015 (UTC)

Frietjes, yes, |type= is not supported, but is tracked by Category:Pages with malformed coordinate tags. I could add support to the sandbox, but I'm unsure if the tracking is due to consensus against such implementation, or if it was merely carried over from the template code. If |3= is inconvenient, perhaps a floating alias of some kind could be added so the module can handle cases in which |3= may or may not hold a part of the coordinates, but that doesn't appear to be an issue in this case? Otherwise, |format= seems to be working properly. |display= should work, but I don't see it being used in this template sandbox? The failed testcase is due to combining two spans. One was only applying a style and the other only an id, so I don't see that as a problem. —PC-XT+ 18:46, 4 March 2015 (UTC)

PC-XT, yes, using |3= works for me. the only other lingering issue would be a method for reducing the excessive precision when |format=dec. however, that's a less critical problem, since it appears most articles where this will be deployed use |format=dms. so, in summary, if it's possible to update the main template, please do so, and I will start documenting the new feature. Frietjes (talk) 18:52, 4 March 2015 (UTC)

Frietjes, I've opened the edit request. —PC-XT+ 19:23, 4 March 2015 (UTC) Link: Module talk:Coordinates#Flummoxed —PC-XT+ 21:51, 4 March 2015 (UTC)

@Frietjes: Great work to get the coordinates to work with Wikidata! I noticed one small thing: the coordinates are no longer in the title (even if coordinates_display = title,inline). Can you correct that? Thanks. -- P 1 9 9  ✉ 20:15, 12 March 2015 (UTC)

PC-XT, fixed, forgot about the differing syntax with geobox coor. note that we now have a similar feature with infobox airport. I plan to add it to {{infobox islands}} as well. it might be good to simply add this to {{geobox coor}} instead? Frietjes (talk) 20:34, 12 March 2015 (UTC)

I'm glad to see {{geobox coor/sandbox}} calls the module directly, instead of wrapping the template. —PC-XT+ 23:48, 13 March 2015 (UTC) You might want to include the #coordinates parser function when not pulling from wikidata, since Lua may still have issues handling it. Does anyone know that phabricator bug? I couldn't find it. Maybe I'm doing the search wrong. I had trouble with the # sign corrupting the url. I did find it mentioned at Template talk:Coord/Archive 11#Wikidata tracking, though. —PC-XT+ 01:31, 14 March 2015 (UTC) Phab:T65597 is marked as resolved. Is that the only one affecting this case? Should we try it in Lua, again? —PC-XT+ 02:07, 14 March 2015 (UTC)

User:PC-XT, I created module:geobox coor to address the problem with the wikidata returning excessively precise numbers. basically, someone needs to fix the conversion from dms to dec to round the result or module:coordinates won't be able to determine the precision before the conversion. so, until this is fixed, I just put a hack in module:geobox coor to round the results for module:coordinates. do you know where we can file a request for changing the dms to dec conversion when the coordinates are pulled from wikidata? Frietjes (talk) 17:15, 14 March 2015 (UTC)

Frietjes, I copied your wikidata rounding function to Module:Coordinates/sandbox and added something similar to what I expect wikidata and {{#property:P625}} use to round coordinates, with help from wikidata:Property talk:P625#Special precision. In most cases, this method should give the same results as yours, but 0s could be left in, if such precision is specified on wikidata. Since wikidata precision may be null, it should probably fall back on your function. Documentation is sparse, and I am not sure this formula is appropriate for use in this module, so it can be fixed or reverted to just use your function as needed. One fix I am considering is a custom rounding function for cases where dms output format is requested and the wikidata precision suggests it, to avoid rounding error. Any thoughts on any of this? —PC-XT+ 23:39, 14 March 2015 (UTC)

User:PC-XT, ha, I didn't know about the precision property. I changed module:geobox coor to use that instead of my hack. if that method doesn't work, it just falls back to not rounding the coordinates. I think we can do the same with module:coordinates, and remove the hack from there as well. once the live coordinates module uses the precision property, I can then completely remove the wikidata-specific stuff from module:geobox coor and just have module:coordinates do it instead. thanks for the help, I can't believe I missed this feature. Frietjes (talk) 16:20, 15 March 2015 (UTC)

Yeah, it was hard to find. I did the same to module:coordinates/sandbox and put in the edit request. As for rounding error, dms coords seem to round to more decimal precision, so that shouldn't be a problem. I was considering other changes like accepting the type from |3=, |5=, |7=, or |9= when using wikidata, but they can be discussed, first. I'm glad I could help. You always do so much to help others. —PC-XT+ 04:53, 16 March 2015 (UTC)

Minority language name

Is there a possibility to add section "minority name(s)" or "official minority name(s)" in this infobox? I asked community about their opinion whether minority name(s) should be included in infobox if they have co-official status in some settlement acording to relevant local statute and/or state regulation? You can see community opinion expresed in this discusion Talk:Minority language#Minority languages ​​in geographical articles. This section might be relevant since many European countries are signatory of European Charter for Regional or Minority Languages that grants co-official use of minority language in some settlements. As far as I know, there also might be simmilar legislation in Canada so it can literally be relevant for at least hundreds, if not thousands settlements in those two regions. From the above cited talk you can see that community support idea that some official minority name should be in infobox and section official minority name(s) would work perfectly for this need.--MirkoS18 (talk) 15:20, 1 June 2015 (UTC)

Do you mean the name of the language; or the name of the place in the language? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:25, 1 June 2015 (UTC)

What I mean is name in minority language but both of it might be useful for readers because they can not recognize language just by inscription in that minority languages.--MirkoS18 (talk) 15:30, 1 June 2015 (UTC)

For the name of the settlement, use |native_name=. You can wrap this in a form of {{lang}}, such as {{lang-de}}, if necessary. If you have an example in mind, I'd be happy to demonstrate. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:42, 1 June 2015 (UTC)

Thanks you for advice! So, if I understood well section |native_name= is intended among other to meet editors need to add co-official minority names there? We actually don't need any other section since this one would be good fit for this?--MirkoS18 (talk) 16:51, 1 June 2015 (UTC)

Yes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:56, 1 June 2015 (UTC)

To clarify the situation Mirko's talking about, I suspect there may be some resistance to listing the secondary/minority name as the "native name", as in the case of the Croatian/Serbian naming problems he's dealing with. The "native" name in that case, is the Croatian name listed in the article's title and the |name= field. AdventurousSquirrel (talk) 20:23, 1 June 2015 (UTC)

Discussion about including US pushpin in infoboxes for US towns

Feel free to join in the discussion at the WikiProject Cities talk page —hike395 (talk) 18:50, 6 June 2015 (UTC)

Template-protected edit request on 7 June 2015 - Demonyms

Above the "Etymology" section, I would suggest that there be a section which says "Demonym" so that there could we put down corresponding demonyms for some words (i.e. "Dakotan" is a demonym for "Dakota"). Gamingforfun365 (talk) 08:02, 7 June 2015 (UTC)

We've got |population_demonym=, which is located below the population section. Alakzi (talk) 10:40, 7 June 2015 (UTC)

Enabling wikidata (census populations)

Is there any work being done in wikidata to collect official census population counts for municipalities? I follow many city pages and population figures are often being edited and reverted, so it would be nice to draw from wikidata to populate this infobox automatically. It would also make life easier when new census figures are released. I am willing to help in any way I can, and am actively working with Canadian municipalities specifically. Mattximus (talk) 02:33, 31 May 2015 (UTC)

Mattximus, this is definitely possible. many Philippine municipalities are using an intermediate template, {{PH wikidata}}, to pull information from wikidata, and we already have support for pulling coordinates. one key is that we should be pulling both the citation and the number from the same source, so the two stay in sync. so, assuming we can pull references from wikidata, this sounds like a good thing to explore. Frietjes (talk) 13:36, 8 June 2015 (UTC)

Proposal to change coordinate data format

I propose we change the coordinate data from:

 | latd  =  |latm  =  |lats  =  |latNS  =
 | longd =  |longm =  |longs =  |longEW =

to something like (I don't care what you name it)

|coordinate =

where it is represented by 2 floating points rather than 8 characters. This will make it easier for bots to grab the data and make it easier for user to enter it (2 points with comma vs 6 numbers and two letters.). --Cs california (talk) 22:56, 8 June 2015 (UTC)

(1) You may, in fact, enter the decimal latitude and longitude using |latd= and |longd=; the remaining parameters can be omitted. (2) Bots should not be extracting any data from wikitext. {{Coord}}, the template the coordinates are piped into, emits metadata for the sole benefit of our robotic overlords. Alakzi (talk) 23:13, 8 June 2015 (UTC)

Elevation

The numbers entered in the parameters elevation_m and elevation_ft around on the enwiki articles, do they mean the average or maximum elevation? It is somewhat unclear, and I think many editors might mistakenly enter the wrong numbers. The parameter should be named average_elevation_ft instead (provided that it does indeed mean the average elevation). Utopiantos (talk) 23:08, 15 July 2015 (UTC)

Utopiantos, probably average since there is also |elevation_max_m= and |elevation_min_m= ... there is also |elevation_point= for denoting the location of the measurement (see the section of the documentation). the problem with changing the label on the existing parameter would be possible inconsistencies with prior understandings of the parameter. however, I could see adding a new parameter for "average elevation", and then deprecating the old one if its not used with |elevation_point=. Frietjes (talk) 16:28, 25 July 2015 (UTC)

Misuse of image fields

Misuse of the image parameters of this infobox is causing problems importing data into Wikidata; see discussion there. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:47, 15 August 2015 (UTC)

Stray tags

When I imported this template to a local wiki for testing purposes, a stray </th></tr> tag appears: I have Scribunto installed already. What am I missing in the import? Thanks in advance. --Marianian^(talk) 12:56, 5 September 2015 (UTC)

Are you saying that when using the imported template, the html output has stray tags? Please provide a very brief example of input which shows the problem. When viewing the html source, quote a bit of the text which includes a stray tag so people here can see where it occurs. A confounding issue is that Wikipedia uses HTML Tidy so stray tags may be generated here as well, but they are removed. If you don't get an answer here, a better place for tricky problems is WP:VPT. Johnuniq (talk) 02:51, 6 September 2015 (UTC)

Hi, here is the example: https://nsindex.net/wiki/Vorbarr_Sultana. As far as I know I have already imported the dependencies. --Marianian^(talk) 11:36, 7 September 2015 (UTC)

may be coming from Template:Infobox settlement/columns, but who knows since I can't make test edits on your site. here, as pointed out, we use the HTML Tidy extension to clean most of these up. Frietjes (talk) 12:57, 6 October 2015 (UTC)

TD and file description

Hi,

could you add table data to this template and move the position of file description just next to the file. It would shorten our time necessary to edit Wikipedia, which will lead to the editor happiness being able to add more information in the short time. Thx!--Juandev (talk) 10:06, 10 September 2015 (UTC)

not sure what you are asking. Frietjes (talk) 13:05, 6 October 2015 (UTC)

Merging the PH wikidata

currently, many Philippines articles are using template:PH wikidata to grab settlement-specific data from wikidata for use in this template. It has been proposed a couple times that we should just merge that template with this one. Basically, any field that isn't specified in the infobox could be populated from wikidata if the information exists on wikidata. for an example of the fields that would be potentially imported, see template:PH wikidata. basically, the plan would be to make the 'PH wikidata' a subtemplate of this template, and use it if the information is not specified in the infobox in the article. in other words, the order would be (1) article, (2) wikidata. the other option would be to check wikidata first, so the order would be (1) wikidata, (2) article. a third/fourth option would be either of the first two options, but only turn on this feature if someone specifies |use_wikidata= in the infobox. comments? suggestions? thank you. Frietjes (talk) 13:05, 6 October 2015 (UTC)

Thanks Frietjes. In order to take full advantage of Wikidata's intended purpose and features, I would propose that the Wikidata would become the default for populating the templates, with the option to enter data in the articles (as usual) to override Wikidata or to provide info not yet in Wikidata. That way transition would be seamless. -- P 1 9 9  ✉ 13:48, 6 October 2015 (UTC)

I'd definitely welcome linking the infobox with Wikidata population - I feel that the current practice of updating population figures in every single Wikipedia edition is hugely wasteful.

The infobox should also be able to track discrepancies between Wikipedia and Wikidata, i.e. to detect if the WD population is different to that in the infobox and signalize it by using a tracking category.

However, that's the easy part, because there are some tricky implementation issues:

1. Simply invoking the P1082 property - like {{PH wikidata}} currently does - won't work correctly when there are multiple statements referring to different points in time. If that's the case, I suppose we need to iterate over all statements and fetch only the one which refers to the most recent point in time. That would require Lua scripting IIRC.
2. Like {{PH wikidata}}, we need to fetch the determination method too (P459): is it a census or an estimate? Tricky bit: if there is at least one census figure, should we (always?) override it with more recent estimate figures?
3. If we actually draw a population figure from Wikidata, what happens with |population_footnotes=? It is not a good idea to decouple referencing from the figure itself (i.e. allow the possibility for the figure to change while the ref stays the same), but what to do instead then?
4. Differentiating between urban, rural and metro populations might be tricky too. Not sure if Wikidata supports these qualifiers.

Not entirely straightforward... GregorB (talk) 20:33, 20 October 2015 (UTC)

Thanks for pointing out some of the intricacies. I think we should focus on getting those improvements in that are straightfoirward, rather than trying to replace this derivative template at once. I'd be happy to prepare a new sandbox version introducing the easier cases first (possibly including some of Template:Infobox Syrian district, too), as soon as the flaws I came up with are fixed. Cheers, PanchoS (talk) 17:16, 24 October 2015 (UTC)

I agree, it is better to start with simpler properties - population seems to be rather challenging, although it would have been a big win. GregorB (talk) 20:54, 24 October 2015 (UTC)

Template-protected edit request on 24 October 2015

Please commit my latest edit from sandbox to fix a logic error:

{{{population_total}}} is expected to be displayed in a mergedtoprow unless a {{{total_type}}} is specified. This behaviour is helpful, whenever the infobox holds only population data of a single scope. The current, flawed logic (involving an &nbsp;) however prevents merging {{{population_total}}} with the top row unless &nbsp; is specified as {{{total_type}}}.

If I merged the 58 and 59 fields, this is only for simplicity, because only either of these will ever be rendered: "Population" shows up as a header, unless there is data in the same field. Note that I hesitated to renumber the following ones because it didn't seem to make too much sense.

Cheers, PanchoS (talk) 17:01, 24 October 2015 (UTC)

For backwards compatibility, perhaps it would be better if a blank {{{total_type}}} had no effect, and "&nbsp;" were simply replaced with something that makes sense, like "none". Alakzi (talk) 17:34, 24 October 2015 (UTC)

Not done for now: Please reactivate the edit request when you have reached a consensus for how the template should be changed. Best — Mr. Stradivarius ^{♪ talk ♪} 06:14, 25 October 2015 (UTC)

The world is not head of the city?

Why not a "mayor" name? --Lukaslt13 talk 18:35, 20 December 2015 (UTC)Lukaslt13Lukaslt13 talk 18:35, 20 December 2015 (UTC)

leader_title = Mayor • Sbmeirow • Talk • 06:02, 21 December 2015 (UTC)

Infobox German location

In Template:Infobox German location the automatic categorization of year of establishment should be removed, per Wikipedia:Categories_for_discussion/Log/2015_December_15#Subcats_of_Category:Populated_places_established_in_the_1370s. Can someone help me with this? Marcocapelle (talk) 09:46, 24 December 2015 (UTC)

Transcription?

I just realized that for all transliteration fields, the actual string that appears to the user is "transcription". A transcription is not the same as a transliteration, and is often inappropriate in the context. I'd like to change it. Does anyone oppose this? —Ynhockey ^(Talk) 12:40, 29 December 2015 (UTC)

• Some fields do show transcription, others transliteration, see Dêlêg. You may need to examine some more cases if indeed all uses of this field actually mean to say transliteration instead of transcription... -- P 1 9 9  ✉ 17:19, 30 December 2015 (UTC)

RfC announce: Religion in infoboxes

There is an RfC at Template talk:Infobox#RfC: Religion in infoboxes concerning what should be allowed in the religion entry in infoboxes. Please join the discussion and help us to arrive at a consensus on this issue. --Guy Macon (talk) 17:39, 4 January 2016 (UTC)

Template error

FYI, File:Template Infobox settlement error.jpg Thought I'd post here for someone to fix. Not sure if it's the template or the article. Mlpearc (open channel) 17:52, 15 January 2016 (UTC)

User:Mlpearc, if you read the error message, it is warning you about |dot_x=, |dot_y=, ... which are used in the article source code, but are not used by this template. the simple fix is to just remove them if they are blank. for |leader_name5=, there is a value set in the infobox in the article, but this template does not support numbers over 5. Frietjes (talk) 13:51, 17 January 2016 (UTC)

@Frietjes: I'm not using or need the template I just noticed the errors. Thanx, Mlpearc (open channel) 16:59, 17 January 2016 (UTC)

Interference with wikEd text highlighting feature

Hi, this template appears to be interfering with the WP:wikEd text highlighting feature. I have also filed a trouble ticket on the wikEd talk page. We noticed it here when editing the full article, but not here when section editing, which leads me to believe the settlement infobox is the culprit, as the issue starts at the top of the infobox and then continues throughout the entire article if the whole article is edited at once. Also, noted when full article text editing with wikEd at Amsterdam which also uses infobox settlement. User Corinne has also filed a trouble ticket here at the Village Pump Technical. Ping me back. Cheers! {{u|Checkingfax}} {Talk} 04:51, 24 January 2016 (UTC)

Coordinates at 0,0

For some reason article Riacho Fundo has its coordinates set as 00°00′S 00°00′W, contrary to what's written in corresponding wikidata item. --178.252.126.70 (talk) 14:09, 6 February 2016 (UTC)

Made corrections to and remove vandal from Riacho Fundo – 194.75.238.182 (talk) 20:47, 17 February 2016 (UTC)

Nickname and motto

The nicknames generally are nonsense: editors add their own words. Let's get rid of them.

Mottos are not very useless – get them out too.

194.75.238.182 (talk) 20:51, 17 February 2016 (UTC)

For city nicknames, there is a good previous discussion at Wikipedia talk:Canadian Wikipedians' notice board/Archive 22#City nicknames. Lots of helpful arguments that should be applied across the board. -- P 1 9 9  ✉ 16:28, 18 February 2016 (UTC)

Template-protected edit request on 20 February 2016

Please assist to update "translit_lang_type" list for adding "Cantonese Jyutping" & "Hakka PFS" into Template:Infobox Singapore neighbourhood accordingly, thanks. Gzyeah (talk) 11:57, 20 February 2016 (UTC)

Sorry I don't understand what you are asking. Please put your code in the template's sandbox. If you are requesting help, then try WP:VPT, but you'll need to explain better than this. Regards — Martin (MSGJ · talk) 08:44, 24 February 2016 (UTC)

Parameter for twin cities still called in wrapper templates

While looking into a South African town article, I noticed that the removed "twin" parameters (dropped with this diff) are still called by a few wrapper templates - namely:

• Template:Infobox French canton
• Template:Infobox London Borough
• Template:Infobox South African town which should probably be changed as well.

Just notifying here, as I am not sure about the exact details for this decision (although trimming some excessive infobox details sounds like a good idea). GermanJoe (talk) 08:50, 7 February 2016 (UTC)

thanks for the notification. those wrappers have been fixed. Frietjes (talk) 13:08, 11 March 2016 (UTC)

Is embedding possible?

Last year, embedding using a module was tried with this template here. Is it possible to add it to this template? I'm just wondering if there is a way to handle settlements that are also UNESCO World Heritage sites, using Template:Infobox World Heritage Site and making them combine with this template. Funandtrvl (talk) 01:41, 23 January 2016 (UTC)

Funandtrvl, if you provide an example, I can work on a solution. basically, I believe the problem is that the geography class used by the infobox is creating tons of borders on the child template, since the child template doesn't use the "mergedrow" classes. however, we could probably work out a different solution. Frietjes (talk) 13:12, 11 March 2016 (UTC)

possible new field

A reader wrote to Wikimedia (OTRS 2016020210000748) requesting that the name of the Municipality Vice Chairperson should be added to Perumbavoor.

I plan to explain that it isn't quite as simple as it sounds as the article uses this template, and there is no such field at the moment.

Please treat this as a request for inclusion of such a field; I have no idea how common this term is, so I will leave it to you to determine whether it should be added.--S Philbrick(Talk) 20:19, 6 February 2016 (UTC)

Sphilbrick, there is nothing to change here, you just need to add |leader_title2=Municipality Vice Chairperson and |leader_name2=foo bar to that article. Frietjes (talk) 13:09, 11 March 2016 (UTC)

Thank-you, I'll pass that along.--S Philbrick(Talk) 13:13, 11 March 2016 (UTC)

Population density not displaying

On this page, I have tried multiple variations and pop density will not display. B137 (talk) 20:14, 17 November 2015 (UTC)

I figured it out but it brings up a bigger issue.

WP:Synth

Example
Area
• Total	12 km2 (5 sq mi)
Population
• Total	1,234
• Density	100/km2 (270/sq mi)

There is no clear way of adding a citation for population density, and due to automatic calculations you cannot add it manually after the figure. They seem to be implying that a reference is not needed because Wikipedia can just divide the population total by the land area, but that is concocting data, which is usually admonished no matter how obvious or intuitive it is. B137 (talk) 20:24, 17 November 2015 (UTC)

Not necessarily - see WP:CALC. GregorB (talk) 20:30, 17 November 2015 (UTC)

On the /doc page, it stills shows 'auto' after population_density_km2 and population_density_sq_mi. It doesn't seem to work anymore, so should I remove it from the instructions? I'm assuming the functionality has been changed since the /doc page was updated. Please correct me if that is incorrect. Funandtrvl (talk) 01:33, 23 January 2016 (UTC)

Funandtrvl, the parameter still works, but requires that the values passed to the population and area are both numbers, otherwise dividing doesn't work. Frietjes (talk) 13:19, 11 March 2016 (UTC)

Template-protected edit request on 17 March 2016

The presence of the parameter "image_dot_map" is still tested in the code, whereas it is now obsolete. Could you remove {{{image_dot_map|}}} in the line

| rowclass10 = {{#if:{{{image_map|}}}{{{image_map1|}}}{{{image_dot_map|}}}{{{pushpin_map|}}}{{{pushpin_map1|}}}|mergedbottomrow}}

? Thank you, Automatik (talk) 14:01, 17 March 2016 (UTC)

Not done: I am not finding this in the template's code. There are only two occurences of image_dot_map and they are used for tracking purposes, not in the way you describe, — Martin (MSGJ · talk) 14:16, 17 March 2016 (UTC)

You're right, I was looking at an old version of the template. My apologies. Automatik (talk) 14:17, 17 March 2016 (UTC)

Whack! You've been whacked with a wet trout. Don't take this too seriously. Someone just wants to let you know that you did something silly.

Several parameters of {{infobox German state}} not used in template {{infobox settlement}}?

When previewing my edits on Saxony-Anhalt I get the warnings

Warning: Page using Template:Infobox settlement with unknown parameter "dot_y" (this message is shown only in preview).
Warning: Page using Template:Infobox settlement with unknown parameter "dot_mapsize" (this message is shown only in preview).
Warning: Page using Template:Infobox settlement with unknown parameter "national anthem" (this message is shown only in preview).
Warning: Page using Template:Infobox settlement with unknown parameter "dot_map_alt" (this message is shown only in preview).
Warning: Page using Template:Infobox settlement with unknown parameter "dot_map_base_alt" (this message is shown only in preview).
Warning: Page using Template:Infobox settlement with unknown parameter "dot_map_caption" (this message is shown only in preview).
Warning: Page using Template:Infobox settlement with unknown parameter "date" (this message is shown only in preview).
Warning: Page using Template:Infobox settlement with unknown parameter "dot_x" (this message is shown only in preview).

which apparently stem from the use of the template {{infobox German state}} on that page. I don't feel confident editing these templates, could one of you experts please look into this? Thanks, AxelBoldt (talk) 16:52, 17 March 2016 (UTC)

AxelBoldt, fixed, thank you for noticing and reporting the problem. Frietjes (talk) 17:10, 17 March 2016 (UTC)

• Ahem... Seen some of the above myself in recent days, and can add these just now seen the first time tweaking Lehigh Valley:

Template:Infobox settlement(edit talk links history) {{Infobox settlement |MSA_name = Allentown-Bethlehem-Easton |name = Lehigh Valley, PA-NJ MSA<br/><small>[[List of United States Metropolitan Statistical Areas|Metropolitan Statistical Area]]</small><br/><small>Eastern Pennsylvania</small>}} & Etc.

Warning: Page using Template:Infobox settlement with unknown parameter "density_mi2" (this message is shown only in preview).
Warning: Page using Template:Infobox settlement with unknown parameter "density_km2" (this message is shown only in preview).
Warning: Page using Template:Infobox settlement with unknown parameter "MSA_name" (this message is shown only in preview).

• Unlike the AxelBoldt, I'm not even brave enough to look. SUSPECT however, someone might assign a dummy category or template call to such parameters, and can run a bot to eliminate same.

Setting ... {{Edit protect}} in a blatant attempt to have the problem looked at by someone annoyed enough to solve these issues... issues which likely wouldn't exist if template coding hadn't gone overboard in consolidating templates a few years back.

• OTHERWISE, championing the principle of "If you break it, you fix it!", the no longer used parameters ought at least to be trapped IN THE TEMPLATE and NOT reported as an error.
• Otherwise suggest you lot of over coders get off your butt and run a bot to kill them off. Getting these messages is alarming, hence inconsiderate. // FrankB 21:41, 4 May 2016 (UTC)

Not done: Those errors are deliberate--in the particular article of interest, you should remove the parameters in question, since the template no longer uses them. Izno (talk) 01:39, 5 May 2016 (UTC)

Template-protected edit request on 12 June 2016

In Kalmar County the parameter | image_blank_emblem is used to show a map. If this use is adequate the code title=Official logo of should be changed to something else. So that when you hoover your mouse over the image it doesn't show the wrong text. – GeMet [gemet|ʇǝɯǝƃ] 20:21, 12 June 2016 (UTC)

@GeMet: I think |image_blank_emblem= was not designed to be used that way. You could use |image_map=, but if the concern is infobox length (due to the map dimensions), we could introduce |blank_emblem_prefix= to override "Official logo of", which would solve your problem. I'm on the fence about whether this needs consensus. I made this testcase, which uses |blank_emblem_prefix= from the sandbox to customize hovertext. Any comments from others are welcome. — Andy W. (talk · ctb) 20:39, 12 June 2016 (UTC)

(edit conflict)  Not done This is not the correct usage for |image_blank_emblem=. I have moved the map to |image_map=. — JJMC89 (T·C) 20:41, 12 June 2016 (UTC)

@GeMet: The following code will get you a result similar to, but not exactly equal to, the result you seek:

Extended content

{{Infobox settlement | official_name = Kalmar | native_name = | native_name_lang = se | settlement_type = [[Counties of Sweden|County of Sweden]] | image_flag = | image_shield = Kalmar län vapen.svg | shield_size = 75px | pushpin_map = Sweden | pushpin_mapsize = <!--omit "px"--> | pushpin_label_position = bottom | pushpin_map_alt = Location in Sweden | pushpin_map_caption = Location in Sweden | pushpin_map_narrow = yes | latd = 56 |latm = 44|latNS = N | longd = 15 |longm = 54|longEW = E ...

— Andy W. (talk · ctb) 20:54, 12 June 2016 (UTC)

Template-protected edit request on 13 June 2016

Presently, the infobox pipes "UTC" and the specified offset, to Coordinated Universal Time, eg "UTC+1". It also does this again for daylight saving time (piped to a section, but unnecessary since the label links to Daylight saving time), and two more times if a second time zone is specified. This is contrary to MOS, piping unnecessarily and over linking. Please correct the pipe in the first instance (so only "UTC" is piped) and remove the links in the following three instances. ie from:

Extended content

<!-- ***Time Zones*** --> | rowclass82 = mergedtoprow | label82 = {{#if:{{{timezone2|}}}|[[Time zone]]s|[[Time zone]]}} | data82 = {{#if:{{{timezone1|{{{timezone|}}}}}}|{{{timezone1|{{{timezone}}}}}} {{#if:{{{utc_offset1|{{{utc_offset|}}} }}}|([[Coordinated Universal Time|UTC{{{utc_offset1|{{{utc_offset}}}}}}]])}} }} | rowclass83 = mergedrow | label83 = <nowiki /> | data83 = {{#if:{{{timezone1|{{{timezone|}}}}}}|{{#if:{{{timezone2|}}}|{{{timezone2}}} {{#if:{{{utc_offset2|{{{utc_offset2|}}} }}}|([[Coordinated Universal Time|UTC{{{utc_offset2|{{{utc_offset2}}}}}}]])}} }} }} | rowclass84 = mergedrow | label84 = <span style="white-space:nowrap"> • Summer ([[Daylight saving time|DST]])</span> | data84 = {{#if:{{{timezone1|{{{timezone|}}}}}}|{{#if:{{{timezone1_DST|{{{timezone_DST|}}}}}}|{{{timezone1_DST|{{{timezone_DST|}}}}}} ([[Coordinated Universal Time|UTC{{{utc_offset1_DST|{{{utc_offset_DST|}}}}}}]])}} }} | rowclass85 = mergedrow | label85 = <nowiki /> | data85 = {{#if:{{{timezone1|{{{timezone|}}}}}}|{{#if:{{{timezone1_DST|{{{timezone_DST|}}}}}}|{{#if:{{{timezone2_DST|}}}|{{{timezone2_DST}}} ([[Coordinated Universal Time#Daylight saving time|UTC{{{utc_offset2_DST|}}}]])}} }} }} To <!-- ***Time Zones*** --> | rowclass82 = mergedtoprow | label82 = {{#if:{{{timezone2|}}}|[[Time zone]]s|[[Time zone]]}} | data82 = {{#if:{{{timezone1|{{{timezone|}}}}}}|{{{timezone1|{{{timezone}}}}}} {{#if:{{{utc_offset1|{{{utc_offset|}}} }}}|([[Coordinated Universal Time|UTC]]{{{utc_offset1|{{{utc_offset}}}}}})}} }} | rowclass83 = mergedrow | label83 = <nowiki /> | data83 = {{#if:{{{timezone1|{{{timezone|}}}}}}|{{#if:{{{timezone2|}}}|{{{timezone2}}} {{#if:{{{utc_offset2|{{{utc_offset2|}}} }}}|(UTC{{{utc_offset2|{{{utc_offset2}}}}}})}} }} }} | rowclass84 = mergedrow | label84 = <span style="white-space:nowrap"> • Summer ([[Daylight saving time|DST]])</span> | data84 = {{#if:{{{timezone1|{{{timezone|}}}}}}|{{#if:{{{timezone1_DST|{{{timezone_DST|}}}}}}|{{{timezone1_DST|{{{timezone_DST|}}}}}} (UTC{{{utc_offset1_DST|{{{utc_offset_DST|}}}}}})}} }} | rowclass85 = mergedrow | label85 = <nowiki /> | data85 = {{#if:{{{timezone1|{{{timezone|}}}}}}|{{#if:{{{timezone1_DST|{{{timezone_DST|}}}}}}|{{#if:{{{timezone2_DST|}}}|{{{timezone2_DST}}} (UTC{{{utc_offset2_DST|}}})}} }} }}

Thanks, Rob984 (talk) 10:21, 13 June 2016 (UTC)

I brought your suggestion to the template's sandbox to make it easier to diff. The diff is Special:Diff/721771151/725099556. — Andy W. (talk · ctb) 15:32, 13 June 2016 (UTC)

@Rob984: In April 2006, the timezone code was updated in Special:Diff/46422131 to [[UTC{{{utc_offset}}}]], which resulted in links like UTC-4 and UTC+8. The reversion to Coordinated Universal Time happened with Special:Diff/656160199 by Mlpearc in April 2015. I wasn't able to find discussion about this in Template talk:Infobox settlement/Archive 25. I'm willing to undo the link retargets unless there are objections. — Andy W. (talk · ctb) 17:42, 13 June 2016 (UTC)

@Rob984: If my edits are somehow disturbing the flow of the template then by all means revert them. Mlpearc (open channel) 17:49, 13 June 2016 (UTC)

None, that would be my preference actually. Thanks, Rob984 (talk) 18:29, 13 June 2016 (UTC)

@Rob984 and Mlpearc: Actually, piping is more fail-safe, to prevent redlinks when (for example) |utc_offset= is "1:30" or "+1:30", or even "hello" (it would need to be "+01:30"). But I think we can trust users to look up the links at {{UTC time offsets}}. — Andy W. (talk · ctb) 19:55, 13 June 2016 (UTC)

Marking done for now. Please ping if there are any issues. — Andy W. (talk · ctb) 20:16, 13 June 2016 (UTC)

Flag image - official v. unofficial

For the field "image_flag", what is the position on use of official v. unofficial community flags? The template documentation currently only mentions the intent of the field as "Used for a flag". I tried locating an applicable policy or guidelines; but WP:MOSFLAG is phrased to address flag icons, while WP:WikiProject Cities appears to omit any guidance as well. I couldn't locate this question in the archives.

The reason for this question; at Bellingham, Washington (edit | talk | history | protect | delete | links | watch | logs | views), there appears to be a dispute over the use of File:Bellingham Flag.svg (edit | talk | history | links | watch | logs). The flag did win a Downtown Bellingham Partnership contest to design a community flag in Sept 2015 (here). However, as of July this year, per a Kickstarter page that promotes the flag (here), "The Bellingham government has yet to adopt any official flag, but with your support we are hoping the City will make this one official".

So, is a non-official but community developed flag appropriate for this field in the infobox? --- Barek (talk • contribs) - 04:07, 25 August 2016 (UTC)

IMO it is not desirable to rigidly define the use of this field here, but it would be better to decide it on a case-by-case basis. I suggest to get a consensus at Talk:Bellingham, Washington, or at Wikipedia talk:WikiProject United States. -- P 1 9 9  ✉ 12:48, 25 August 2016 (UTC)

Official only, otherwise anyone can make up a flag for any community and push it onto Wikipedia. The flag needs to reside on the official community website. • Sbmeirow • Talk • 13:37, 25 August 2016 (UTC)

Dividing line above image_map missing?

I think there should be a dividing line above the map, between it and the abbreviations / symbols (flag, coat of arms and motto). One seems to appear when a pushpin_map is used, but not when a image_map is used. For example at Bristol it is missing, whereas at Barcelona it is shown.

Also there should probably be a dividing line between abbreviations and the symbols, since these aren't really related. Maybe the abbreviations field should be moved up to below the official_name and nickname fields?

Rob984 (talk) 01:11, 7 August 2016 (UTC)

There is also a dividing line missing between seat and parts. Rob984 (talk) 16:31, 14 August 2016 (UTC)

One missing below the time zone when postal_code is not given, but area_code is (for example at Catalonia). I assume due to incautious use of mergerow, not considering that many parameters will not be used. Rob984 (talk)

Rob984, should be fixed now. Frietjes (talk) 19:03, 11 October 2016 (UTC)

Looks better now, thanks. Rob984 (talk) 22:39, 11 October 2016 (UTC)

pushpin_map = Ukraine

Hi,

I've noticed that since the 15th of October 2016 the variable:

pushpin_map = Ukraine

stopped working in Template:Infobox settlement. In fact the map of Ukraine is not shown in the infobox. It have affected all Ukrainian settlements where that infobox is used. (e.g. Sviatoshyn, Ozeryshche (Ukraine), Chernihiv)

Any ideas?

Regards, --TimeWaitsForNobody (talk) 01:32, 16 October 2016 (UTC)

I can see a map on Sviatoshyn, under Firefox. What browser are you using? —hike395 (talk) 02:58, 16 October 2016 (UTC)

Firefox 47.0.1., Oh, I've just checked it in IE and it works and it works when I use the Firefox private mode too. It might be some settings of my Firefox, I reckon. --TimeWaitsForNobody (talk) 06:21, 16 October 2016 (UTC)

• I've found that the problem appears when using the "View -> Zoom In" feature in Firefox otherwise there's OK. --TimeWaitsForNobody (talk) 07:14, 16 October 2016 (UTC)

Yes, I can reproduce that, also, under Firefox 49. I'll look into it -- I can at least report it at the right module/template —hike395 (talk) 12:32, 16 October 2016 (UTC)

Thank you. --TimeWaitsForNobody (talk) 20:36, 16 October 2016 (UTC)

Problems with a customized wrapper

Template:Infobox Municipality BR said any field from this template could work on it as long as it was added there first. I added some code to it then, and previewing the page showed it working fine, but when i saved and opened the page, the field is not showing up. The page i was using is Trindade do Sul. What could be causing this? YuriNikolai (talk) 20:53, 31 October 2016 (UTC)

It's working fine after a WP:NULLEDIT. – Jonesey95 (talk) 23:24, 31 October 2016 (UTC)

Wrong ISO region code for Uttarakhand

According to the template's documentation:

If coordinates_region is omitted or blank, region: will be set according to subdivision_name, using {{Country abbreviation}}. For example, subdivision_name = United Kingdom will generate coordinates with "region:GB". In addition, wherever possible, subdivision_name1 will be used to determine the region. For example: subdivision_name=Canada and subdivision_name1=Ontario will yield "region:CA-ON".

In the case of settlements in the Indian state of Uttarakhand, where "subdivision_name1=Uttarakhand", the template is returning the region code IN-UL. This was correct before 2007, but the region code should now be IN-UT. I can't figure out how the template assigns the region codes for the "subdivision_name1" field (i.e., where it's getting the obsolete region code from). Could someone fix this? Deor (talk) 07:36, 28 November 2016 (UTC)

 Fixed in {{ISO 3166 code India Uttaranchal}}. —hike395 (talk) 13:07, 28 November 2016 (UTC)

Images not displaying

Dear all, images in this template are not displaying properly when "image =" is used example. Could someone please have a look at this problem. Thank you, Taketa (talk) 11:23, 11 December 2016 (UTC)

|image= is an undocumented parameter to the infobox. It only works if you put wikicode for an image, e.g., [[File:Kerk Meerlo.JPG|thumb|200px]]. If you use |image_skyline=Kerk Meerlo.JPG, it should work. Note that |caption= isn't supported at all, it should be |image_caption=RK Kerk Sint Johannes de Doper Meerlo —hike395 (talk) 13:40, 11 December 2016 (UTC)

Question for maintainers: there are about 65 articles that use |image=. One example is Alameda County, California: the photomontage is the argument to |image=. But, this is an artifact of the days before Module:InfoboxImage: now, photomontages (or other wikimarkup) can be fed directly into the |image_skyline= parameter and it should work. I tested Alameda County. I removed |image= from the list of correct parameters (i.e., it will give a warning on preview). Is there consensus to remove the image parameter and replace with image_skyline on those 65 articles? —hike395 (talk) 14:32, 11 December 2016 (UTC)

I found one instance of |image= in the template documentation, at "Complete empty syntax, with comments". You might want to remove it from the documentation if you are removing support for it. – Jonesey95 (talk) 15:11, 11 December 2016 (UTC)

yes, migrate all of them to use |image_skyline= and then either (a) remove it or (b) just make it an alias for |image_skyline= since |image= is a reasonable/common parameter name in other templates. Frietjes (talk) 15:54, 11 December 2016 (UTC)

I moved the tracking to Category:Pages using infobox settlement with the image parameter without any namespace restriction. if I recall, there were/are some wrapper templates using this feature. it will take some time for the category to fill. Frietjes (talk) 15:59, 11 December 2016 (UTC)

I like the idea of keeping it as an alias (so that the infobox will still work as expected, with warning on preview). Thanks, Frietjes, for making a separate tracking category. I'll dig up my Windows box to run AWB. —hike395 (talk) 18:38, 11 December 2016 (UTC)

Invalid output on Samacá

Hi all. Today there was a thread on mediawiki.org mentioning this template - it turns out that when it is used on the Samacá article it produces very strange output. Here is the template invocation:

Template invocation

{{Infobox settlement |name = Samacá |native_name = |nickname = |motto = |settlement_type = [[Municipalities of Colombia|Municipality]] and town |image_skyline = Samacá Boyacá 03.JPG |imagesize = |image_caption = View of Samacá |image_flag = Flag of Samacá (Boyacá).svg |image_seal = |image_map = Colombia - Boyaca - Samaca.svg |mapsize = 250px |map_caption = Location of the municipality and town of Samacá in the Boyacá Department of Colombia |pushpin_map = |pushpin_mapsize = 300 |pushpin_map_caption = Location in Colombia |subdivision_type = Country |subdivision_name = {{flag|Colombia}} |subdivision_type1 = [[Departments of Colombia|Department]] |subdivision_name1 = [[Boyacá Department]] |subdivision_type2 = Province |subdivision_name2 = [[Central Boyacá Province]] |leader_title = Mayor |leader_name = Wilson Castiblanco Gil<br><small>(2016-2019)</small> |established_title = Founded |established_date = 1 January 1556 |founder = [[Juan de los Barrios]] |area_magnitude = |area_total_km2 = 172.9 |area_total_sq_mi = |area_land_km2 = |area_land_sq_mi = |area_water_km2 = |area_water_sq_mi = |area_water_percent = |area_urban_km2 = 1.2 |area_urban_sq_mi = |area_metro_km2 = |area_metro_sq_mi = |population_as_of = 2015 |population_note = |population_total = 19907 |population_density_km2 = auto |population_density_sq_mi = |population_metro = |population_density_metro_km2 = |population_density_metro_sq_mi = |population_urban = 5908 |latd=|latm=|lats= |latNS=S |longd=|longm=|longs= |longEW=W |timezone = Colombia Standard Time |utc_offset = -5 |timezone_DST = |utc_offset_DST = |elevation_m = 2660 |elevation_ft = |website = [http://www.samaca-boyaca.gov.co/index.shtml Official website] |footnotes = }}

And here is what it produces (indented for clarity):

<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">
            <span class="fn org">Samacá</span>
            <tr>
                <td colspan="2" style="text-align:center;background-color:#cddeff; font-weight:bold;">
                    <span class="category">[[Municipalities of Colombia|Municipality]] and town</span>
                </td>
            </tr>
        </th>
    </tr>
    -- snip --
</table>

I'm pretty sure that you're not supposed to put tr tags directly inside th tags, so it looks like something has gone wrong with the child infobox templates this template uses. I might look into this myself at some point in the future, but I don't have the time right now, so I'll just leave this here instead. — Mr. Stradivarius ^{♪ talk ♪} 09:57, 25 January 2017 (UTC)

User:Mr. Stradivarius, when I view the source for Samacá, I see

<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"><span class="fn org">Samacá</span></th>
    </tr>
    <tr>
      <td colspan="2" style="text-align:center;background-color:#cddeff; font-weight:bold;"><span class="category"><a href="/wiki/Municipalities_of_Colombia" title="Municipalities of Colombia">Municipality</a> and town</span></td>
    </tr>
-- snip --
</table>

which is probably because the backend software on this wiki uses html tidy (as you correctly identified in the linked thread). I believe it's well-known that if you turn off HTML tidy then the whole {{infobox|child=yes}} goes haywire, so this isn't really a problem with this infobox, but with all infoboxes which use {{infobox|child=yes}}. assuming you know the context for the embedding, you have the {{infobox|child=yes}} inject a closing </th> and </tr> at the top. but, without knowing the context, you don't know if it should be a closing </th> or </td>. this seems like something which would be better discussed on the talk page for template:infobox. the solution may be to have something like |embedded_in=header and |embedded_in=data and then go around and update all of the uses. Frietjes (talk) 15:57, 25 January 2017 (UTC)

Hmm, I see. This is more difficult than I thought. There might be another way around this if we can safely assume that all infoboxes with |child=yes are used inside another infobox template rendered by Module:Infobox, though. Instead of having |child=yes output HTML, we could have it output JSON and then have the parent infobox render the JSON as HTML with the proper tags for its location. Properly escaping JSON in wikitext sounds like it would be a pain, though. I'll have a bit more of a think about this and then maybe post at Template talk:Infobox if it looks like it's going to work. — Mr. Stradivarius ^{♪ talk ♪} 00:00, 26 January 2017 (UTC)

This discussion is over my head but I recently edited Module:Navbox/sandbox to fix striping of alternate rows with a different background color. A navbox can have child navboxes, and the striping has to take them into account. The parent navbox uses the dreadful hack of testing whether a row starts with '</div><table'—if it does, the row is the output of a child navbox. I mention that in case the technique could be applied here. Johnuniq (talk) 01:17, 26 January 2017 (UTC)

Embedding

I have added an optional parameter, |embed= which allows this infobox to be embedded into another. for an example, see here. let me know if you see any problems. Frietjes (talk) 20:11, 23 February 2017 (UTC)

Thanks. Should be useful in cases where there's two or more infoboxes (such as for old municipalities).♦ Dr. Blofeld 20:25, 23 February 2017 (UTC)

Affecting output of contained templates

The {{When}} template doesn't like it inside this infobox - I assume the problem is there rather than here, but in case there is a wider issue I thought I would mention it here - see discussion at : Template_talk:When#Breaks_inside_Infobox_settlement Le Deluge (talk) 20:11, 27 February 2017 (UTC)

responded there. Frietjes (talk) 21:10, 27 February 2017 (UTC)

@Frietjes: For the record, I've come across the same effect on {{dead link}} on stat2-data/stat3-data at King Khalid International Airport (presumably bot-added?) and a {{dubious}} on population_urban on Machiques. I don't know whether it's possible to do a general exclusion on formatnum'ing any templates in the infobox? Le Deluge (talk) 22:01, 27 February 2017 (UTC)

subdivision_name ?

In the description of the parameter subdivision_name, it says " sample: United States or United States, ". What does this mean? AxelBoldt (talk) 16:47, 9 March 2017 (UTC)

AxelBoldt, it really depends on what is in |subdivision_type=. if |subdivision_type=Country, then |subdivision_name= is the name of the country. Frietjes (talk) 17:09, 9 March 2017 (UTC)

Yes, but why do they say "United States or United States" in the description? Why the repetition? AxelBoldt (talk) 17:17, 9 March 2017 (UTC)

It was changed in this edit back in 2013. That edit looks completely wrong to me. I recommend reverting it, but subsequent changes prevent a straight revert. It will need to be fixed manually. – Jonesey95 (talk) 19:58, 9 March 2017 (UTC)

Kreis Meseritz

Does anyone know how to fix the infobox in Kreis Meseritz so that it doesn't try to populate the non-existent (and obviously incomplete) Category:Former districts of?

The red-linked category pops up in Special:WantedCategories, where I and others are trying to clear a massive backlog.

A quick smple of Category:Districts of Prussia shows none of them using {{Infobox District DE}}. Is the solution here to remove the infobox from Kreis Meseritz? --BrownHairedGirl (talk) • (contribs) 11:20, 20 March 2017 (UTC)

• It seems to me that {{Infobox District DE}} tries to be too smart for its own (or Wikipedia's) good. Its piece of code dealing with "Categorisation" doesn't deal with multiple states (as present in Meseritz) nor with historical states like Prussia or Posen. This "cleverness" again demonstrates the pitfalls of categorisation by template. That section in the template code ought to be removed. -- Michael Bednarek (talk) 13:07, 20 March 2017 (UTC)

I hacked it to add a default to the switch statement. – Jonesey95 (talk) 13:28, 20 March 2017 (UTC)

Widespread abuse of the word census

The word census is popping up everywhere it shouldn't be, its abused all over wikipedia as of 2017. It seems that either the general public or people who edit population information do not understand what is a census, that no nation carries one out annually. There are censuses, intercensal surveys, estimates, and projections, only one is an actual physical count, the others are guesstimates based on a count that itself is prone to error. That makes for a lot of unreliability. Some nations have not bothered to conduct a proper census even once in 30 years, the word census gives the appearance that data is sacrosanct, where it could very well be not even in the ballpark. It seems that a majority of editors of population data on wikipedia attach the word census to any figure without any distinction. For reference, here are listed dates: Population and housing censuses by country. I do not have permission to edit this template documentation, but this guidance should be repeated for quality control, as a minimum in documentation. Doseiai2 (talk) 22:49, 28 April 2017 (UTC)

Please link to an example of an article, or multiple articles, where this alleged abuse is taking place. – Jonesey95 (talk) 00:32, 29 April 2017 (UTC)

settlement_type problem

settlement_type discussion

Hello. I install Mediawiki 1.28.2 on XAMPP. I create this template. But when I try use I see that there is a problem. When I use settlement_type then there is occur additional

</th></tr>

code. How I can fix it? --Drabdullayev17 (talk) 17:33, 6 May 2017 (UTC)

Please post a minimal example of an infobox that works here and does not work in your setup (or which has invalid html). Remove everything from the example that is not needed to demonstrate the issue. If no useful response, try WP:VPT. Johnuniq (talk) 02:00, 7 May 2017 (UTC)

NAME
TYPE

Enter {{Infobox settlement|name=NAME|settlement_type=TYPE}} at Special:ExpandTemplates. Result:

<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"><span class="fn org">NAME</span><tr><td colspan="2" style="text-align:center;background-color:#cddeff; font-weight:bold;">
<span class="category">TYPE</span></td></tr></th></tr></table>

I think the first row should have ended with </th></tr> before the second began like this:

<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"><span class="fn org">NAME</span></th></tr><tr><td colspan="2" style="text-align:center;background-color:#cddeff; font-weight:bold;">
<span class="category">TYPE</span></td></tr></table>

The bad code works here, maybe due to HTMLTidy, but may fail at other wikis. See mw:Manual:Using content from Wikipedia#HTMLTidy. PrimeHunter (talk) 10:05, 7 May 2017 (UTC)

This has been raised also at VPT. @PrimeHunter: Previewing the following wikitext in a sandbox gives the result shown below.

{{#invoke:dump|dumphtml|1={{Infobox settlement|name=NAME|settlement_type=TYPE}}}}

<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">
            <span class="fn org">NAME</span>
            <tr>
                <td colspan="2" style="text-align:center;background-color:#cddeff; font-weight:bold;">
                    <span class="category">TYPE</span>
                </td>
            </tr>
        </th>
    </tr>
</table>

You are saying that it should be:

<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">
            <span class="fn org">NAME</span>
	</th>
    </tr>
    <tr>
	<td colspan="2" style="text-align:center;background-color:#cddeff; font-weight:bold;">
	    <span class="category">TYPE</span>
	</td>
    </tr>
</table>

Later, if no one else has a go, I'll look at where that might be happening. Johnuniq (talk) 11:11, 7 May 2017 (UTC)

When I use old template there is no problem. Can somebody find solution? --Drabdullayev17 (talk) 05:13, 8 May 2017 (UTC)

settlement_type analysis

It appears that all versions of {{infobox settlement}} based on {{infobox}} are mishandling settlement_type. HTMLTidy is correcting the HTML in the output so the problem has not been noticed. See my sandbox2 (permalink) for a demonstration which uses {{infobox settlement/sandbox}} that currently contains the version just before the template was switched to use {{infobox}}.

I think that {{infobox settlement|name=NAME|settlement_type=TYPE}} causes the template to handle settlement_type as below. That causes the HTML output to include the tr row for TYPE in the th header with the NAME.

{{Infobox
...
| above = <span class="fn org">NAME</span>{{infobox|child=yes|decat=yes
  | subheaderstyle = background-color:#cddeff; font-weight:bold;
  | subheader = <span class="category">TYPE</span>
  ...}}
...
}}

This should be fixable. I'll ping a couple of fixers later. Johnuniq (talk) 07:57, 9 May 2017 (UTC)

---

Is the child infobox needed? Using the example input as above in this section, should the output from this template be as follows?

{{Infobox
| above = <span class="fn org">NAME</span>
| subheaderstyle = background-color:#cddeff; font-weight:bold;
| subheader = <span class="category">TYPE</span>
}}

That produces the infobox and HTML below.

NAME
TYPE

'"`UNIQ--templatestyles-00000047-QINU`"'<table class="infobox">
    <tr>
        <th colspan="2" class="infobox-above">
            <span class="fn org">NAME</span>
        </th>
    </tr>
    <tr>
        <td colspan="2" class="infobox-subheader" style="background-color:#cddeff; font-weight:bold;">
            <span class="category">TYPE</span>
        </td>
    </tr>
</table>

Something more would be needed to reproduce the infobox shown in the previous section because it has a box around TYPE.

Johnuniq (talk) 10:38, 9 May 2017 (UTC)

---

Ping Frietjes and Plastikspork and PrimeHunter. The child infobox has a lot more stuff in it, so perhaps it cannot be removed. Can someone work out its purpose and a solution? Note that Template:Infobox#Porting to other MediaWikis says that HTMLTidy is required! Johnuniq (talk) 11:07, 9 May 2017 (UTC)

Johnuniq, the use of many child infoboxes in this template is mostly a vestige of the days before module:infobox, when there was an upper limit on the total number of rows. I put a new version in the sandbox here which doesn't use child infoboxes. the bigger question is what to do about all the other templates which use child infoboxes. we could probably make something which emits valid HTML, and doesn't require tidy to clean it up (in most cases). the problem is that (a) child boxes are sometimes embedded in header rows and sometimes in data rows, and (b) the parent has no knowledge of the embedding. so, we could (1) have the child emit some sort of marker to signal the parent that there is embedded content, and have the parent fix the HTML so that the resulting markup is valid, or (2) have a way to insert html rows directly into an infobox, without the old embedding hack (e.g., {{infobox | labe1 = foo | data1 = bar | row2 = {{infobox|embed=yes|label1 = something | data1 = else ....}} | ...}}). Frietjes (talk) 13:30, 9 May 2017 (UTC)

Frietjes, it looks like the sandbox version is working. We should definitely use a single infobox whenever it works. Thanks! Plastikspork _―Œ^(talk) 20:13, 9 May 2017 (UTC)

Sensational! Thanks Frietjes. I'm afraid I can't think about those points you mentioned at the moment, but I'm probably good for some Lua work later if needed. Johnuniq (talk) 03:34, 10 May 2017 (UTC)

@Drabdullayev17: Frietjes has updated the template and it works well. Johnuniq (talk) 12:10, 10 May 2017 (UTC)

Population estimates

Northern England (Infobox settlement)
Region
Sovereign state	United Kingdom
Country	England
Area
• Region	14,414 sq mi (37,331 km2)
Population  (2011 census)
• Region	14,933,000
• Estimate  (2015)	15,189,032
• Density	1,000/sq mi (400/km2)
• Urban	12,782,940
• Rural	2,150,060
Demonym	Northerner

At present, the way this template handles population estimates is confusing - it mixes them up with census population, making it very difficult to tell what year different counts are from. See for instance this box for Northern England. Why is the 2015 population estimate presented as part of the 2011 census data? Are the urban/rural splits from 2011 or 2015? What about the population density? Can the fields be reorganized (either adding the year to each field, or to have two separate groups - one list of estimated populations, one of counted populations? Smurrayinchester 09:04, 22 May 2017 (UTC)

• I propose to remove estimates altogether. By its very definition, an estimate is unreliable. And as I've noted many times, this field is prone to OR and "guesstimates". -- P 1 9 9  ✉ 16:08, 23 May 2017 (UTC)

Practically all countries publish reliable, official population estimates (see the UK's for instance). In some cases, it's probably necessary to list these (a boom town or ghost town's population may have changed dramatically since the last census - see for instance New Orleans#Changes in population), and even when it's not, if the data is there why not include it? I don't think there's a case for taking it out altogether. Smurrayinchester 09:57, 24 May 2017 (UTC)

Just because the data exists is not automatically a reason to include it (WP:NOTEVERYTHING). But on the other hand, if it's an official estimate and properly referenced, I would support that. Unfortunately, in my observations, that doesn't seem to happen. Most of the time the estimate is just someone's guess (or taken from an unreliable source). True, I don't work on UK-related articles, so hopefully your experience is different. But I still prefer removing it because it is better to have no data than to have wrong data. -- P 1 9 9  ✉ 13:18, 24 May 2017 (UTC)

Deprecated coordinates parameters removed

I have removed deprecated coordinates parameters from this template. See Wikipedia:Coordinates in infoboxes for more information. All existing article-space pages using those deprecated parameters have been converted by a bot, with manual cleanup of remaining articles, as far as I know.

There is a wikidata call in the Coordinates section of this template, and I am not a wikidata expert, so if anything goes wrong with the code that I left behind, please post here or at Wikipedia talk:Coordinates in infoboxes, and someone working on this project will respond as soon as possible. – Jonesey95 (talk) 13:45, 29 May 2017 (UTC)

Jonesey95, the |coordinates_wikidata= and |wikidata= were added before we had |coordinates=. I would like to eventually remove these as redundant to |coordinates={{coord}}, but only after they have all been replaced. Frietjes (talk) 14:36, 29 May 2017 (UTC)

now tracking, and I simplified the code a bit. Frietjes (talk) 14:44, 29 May 2017 (UTC)

Thanks. I'll leave it to you to figure out Marawi and similar articles, which use a lot of wikidata calls. – Jonesey95 (talk) 14:51, 29 May 2017 (UTC)

Jonesey95, sure, I can fix them, but if you want to help it's pretty easy, see here and here and here for examples. Frietjes (talk) 15:07, 29 May 2017 (UTC)

Pushpin map RfC

There is currently an RfC about the use of pushpin maps in the infobox at Talk:Middlebury, Connecticut#RfC about pushpin map in infobox. Thank you. Magnolia677 (talk) 11:21, 14 June 2017 (UTC)

Short version too short

Could somebody add the population line back into the short version? One would think that a major feature of a populated place is its human population. Abductive (reasoning) 18:54, 18 June 2017 (UTC)

Abductive, what exactly are you talking about? I see population_total in both short versions. Thanks! Plastikspork _―Œ^(talk) 20:19, 18 June 2017 (UTC)

Template:Infobox_settlement#Short_version Abductive (reasoning) 20:42, 18 June 2017 (UTC)

WP:SOFIXIT, the doc page isn't protected. Thanks! Plastikspork _―Œ^(talk) 21:09, 18 June 2017 (UTC)

A favor

Hey,

I know this may sound ridiculous, but would it be possible to have someone copy the source of this template and past it into this sandbox subdomain if they get the chance? I'm on mobile and have no access to my computer, and thus can't select in the editor.

Thanks! Jerome501 (talk) 02:43, 30 June 2017 (UTC)

 Done —hike395 (talk) 08:43, 30 June 2017 (UTC)

Thank you. Jerome501 (talk) 13:20, 30 June 2017 (UTC)

Edit request

I think that the word 'flag', 'seal', 'coat of arms' should not write in bold, like Template:Infobox country and Template:Infobox U.S. state. Hddty. (talk) 13:25, 4 August 2017 (UTC)

I'd second this, it's a caption not a label. Should be formatted the same as other image captions. Rob984 (talk) 13:53, 4 August 2017 (UTC)

done. Frietjes (talk) 15:00, 4 August 2017 (UTC)

Consensus on How to Render Population Density for US Places

As I've been getting highly conflicting opinions on how to render population densities and areas in the Infobox settlement templates I've been updating with the help of my semi-updated CenPop script, I figure this is a good place to see what people think (I'll try to tag everyone who commented on my recent update spree). @Alansohn: @Criticalthinker: @Hanyou23: @Imminent77: @Frietjes: @Sbmeirow: @Ɱ: and I'll hold off for a few days before doing more updates. In particular, we need to figure out

• How many decimal places to round to (for both area and density), or whether to round to a certain number of significant digits but always include at least a certain number of decimal places (to ensure that, say, 0.01 sq mi doesn't round to 0). As you can see from what I updated in Alabama, Alaska, Arizona and Arkansas, I have been rounding to two digits after the decimal place, but I'm very open to other suggestions.
• Which Census Bureau numbers to use for the area fields and for the population density fields. I believe we ought to be using the most up-to-date (as of June 23, 2017) Gazetteer file numbers] for area rather than the numbers associated with the 2010 Census as some suggested, as places fairly regularly annex (and sometimes shed) territory, and in particular there are a number of places which did not exist as of the 2010 Census, making it the only real option for consistency across all US incorporated places. Given the use of the 2016 Gazetteer file numbers for area, I then believe that we should also be using the 2016 Census Bureau estimates for population to compute population density, as it would look wrong to use density numbers from 2010 that were computed using the (no longer accurate or present on the page) 2010 data for place area. (Admittedly we still have an inconsistency between the Geography section "According to the Census Bureau, consists of" blah blah blah and the Infobox, but that's going to be challenging to automate replacements for as it's prose, though I'll take a stab at it since it is in a "regular format" for most pages and the others can probably be done manually).

— Preceding unsigned comment added by DemocraticLuntz (talk • contribs) 16:57, 23 June 2017 (UTC)

Just a suggestion. For readability, I'd prefer to see density rounded to the nearest hundred per square mile. For the same reason, rounding the area to the nearest tenth would be better than the nearest hundredth if there are no settlements smaller than 0.05 square mile, 32 acres (13 ha). Are there any such tiny places for which the area is reported by official sources? Disclosure: I'm a content editor, not a programmer. Finetooth (talk) 00:07, 24 June 2017 (UTC)

You may want to retag again, I didn't get a ping. Will comment on this more when I can. ɱ (talk) · vbm · coi) 13:12, 24 June 2017 (UTC)

• I saw this on the user's talk page and didn't see a ping.
  All of the data that I've loaded for population density has been based on data from the Census Bureau's table GCT-PH1 (see sample for New Jersey), I believe that this data should be based on the Census Bureau's data as of 2010, and should *NOT* be recalculated, let alone by using census estimates for population and updated gazetteer data for area. Given the tens of thousands of articles being updated, and the ability to do mass edits in short periods of time, there is no reason to rush towards a solution without clear and broad consensus for these changes. Let's stop, take a giant step backwards and discuss before taking any further action. My strongest suggestion is that we use the 2010 data, straight from the Census Bureau. Alansohn (talk) 05:00, 25 June 2017 (UTC)
  • I second this. To be consistent and since Census estimates can be incredibly unreliable, at least in a city's infobox, what should be used are the numbers from the most immediate Census. What is done in the body of the paragraph, whether it be the opening paragraph, the demographics section, and/or the geography section, I don't really care. I've often simply added on to these sections when a city has made significant annexations in between Censuses and folks usually post population estimates in the historic population table. But, I think the infoboxes should reflect as accurate information as possible, and in the case of the density in particular, it is really not difficult to caculate it on a calculater if it's a Census or two behind where it should be. If there is a way with a template to make the "auto" accurate to the tenth or hundreth, I guess I wouldn't mind. Otherwise, leave it alone. To recalculate using such huge rounding when folks have taken much time to hand calculate these to the nearest tenth in most cases is irresponsible and unnecessary. --Criticalthinker (talk) 10:13, 25 June 2017 (UTC)
    • First, @Criticalthinker:, I agree about the huge rounding problem. plan to (and essentially already have) updated my script to calculate on the fly, so that's not a problem. I just need to know what you want it rounded to. Sounds like you're okay with tenth or hundredth. Secondly, as far as I know, the Gazetteer square miles are accurate, and many pages have already updated past the 2010 Census numbers for area.
      • Sorry, saw this late ;p . 2010 numbers may work for some places (now seven years prior ;o )... but my city has been growing at roughly 15% or more since 1950 (or thereabouts). So if you compare the last census count in 2010 to the estimate in 2016 - the count will be 258,379 vs. 280,364 and thus, the 2010 calculation will be grossly outdated ;o . Long story short, I think the latest estimate is the best number to deal with ;) . Also, hundredths seems like a good number to round off - at least for me :) . Anyways, going to hit the sack - late night -o-; . Cheers ^_^ ~ Hanyou23 (talk) 09:01, 26 June 2017 (UTC)
• Any progress on this? Forcing these infobox density numbers through the existing template negatively effected A LOT of pages. --Criticalthinker (talk) 01:57, 11 July 2017 (UTC)
  • ⬆️ 👍🏼 Hanyou23 (talk) 21:18, 19 July 2017 (UTC)
• This still hasn't be corrected, and your page is full of complaints from your edits up to literally yesterday. Why have you not taken the hint? Stop messing with things that aren't broken. --Criticalthinker (talk) 23:34, 12 August 2017 (UTC)

Coat of arms in mobile site too small

I don't know where exactly the source code that need to be edited but there is a similar problem in Infobox country. Hddty. (talk) 15:09, 30 August 2017 (UTC)

It's fixed at Template:Infobox country. The relevant code is here: Template:Infobox country/imagetable. Basically the mobile site does not handle tables within the infobox well. I fixed it by using divs which function like tables. This is actually more efficient then single row tables anyway:

<div style="display:table; width:100%;">
    <div style="display:table-cell; width:58%; vertical-align:middle;">
        [IMAGE]
        <div style="font-size:90%;">[CAPTION]</div>
    </div>
    <div style="display:table-cell; vertical-align:middle;">
        [IMAGE]
        <div style="font-size:90%;">[CAPTION]</div>
    </div>
</div>

To fix it, I'd need to have access to the "Preview page with this template" feature, but I'm not a template editor yet.

Rob984 (talk) 17:25, 30 August 2017 (UTC)

Rob984, can you fix it by changing Template:Infobox settlement/columns/sandbox? I believe that's the analog of Template:Infobox country/imagetable. any changes to the sandbox should be viewable in the testcases. Frietjes (talk) 20:52, 30 August 2017 (UTC)

Template-protected edit request on 27 September 2017 - Location Map "outside"

Same issue as at Template talk:Infobox airport#Location map parameters. Please add |pushpin_outside=, MB 14:48, 27 September 2017 (UTC)

added. Frietjes (talk) 14:53, 27 September 2017 (UTC)

Add field for mobile app?

I was looking at VRTS ticket # 2017060510014175, which requested that a field for a link to a mobile app be included in the template. The requester suggested that several cities (at least in India) have their own mobile apps.

This may be useful on other templates also. The simplest implementation would be a text field like most other fields, although a more complicated one would include URLs for iOS and Android apps. Or, this field could appear when viewing Wikipedia from a mobile device. ~Anachronist (talk) 21:55, 19 July 2017 (UTC)

It is unlikely that we can make such a field compliant with WP:EL, besides the possibility for spam, and I would oppose on that account. --Izno (talk) 23:43, 19 July 2017 (UTC)

The initial suggestion was just a text field showing the name of the app. In the case of linking, we already include such a field for the company website. Since Google reports that the majority of its search traffic is from mobile devices, the trend is pretty clear. It would make sense for a link to an app instead of (or in addition to) a website. ~Anachronist (talk) 05:11, 20 July 2017 (UTC)

Android? iOS? Microsoft? Some other OS? All? None? "An app" without the URI is nearly meaningless, and with the URI looks like spam. As for official website, I've meant for a long long time to see that removed--it's uncharacteristic for us to bend WP:EL so badly just for the article topic's website. --Izno (talk) 11:28, 20 July 2017 (UTC)

I would like to see at least two examples. Once they are available, I might ask for views at WP:ELN. The general procedure is that an entity has one official link. If there is an official app, the one official link should prominently mention it. It is not the role of Wikipedia to act as a web directory to compensate for deficiences in official websites. Johnuniq (talk) 23:16, 20 July 2017 (UTC)

Why not have it link to a page similar to the coordinates pages, just instead of listing all maps services, list all available platforms the app is offered on. ɱ (talk) · vbm · coi) 17:30, 27 September 2017 (UTC)

"Area code" field

Could we add in the notes in the description (no change to the actual template) copy along the lines of "Local exchanges do not belong in this field"? I remove instances of this at least three times a month from various US settlement articles. The concept of the local exchange is an archaic concept these days anyway. John from Idegon (talk) 03:38, 2 October 2017 (UTC)

How about simply removing the field? It seems like low-value data, plus editors seem to be confused. —hike395 (talk) 04:13, 2 October 2017 (UTC)

The field seems just as helpful as postal codes. It certainly can be notable feature (see Area code 212 in general and Area Code 212 (album) specifically for example). Occasional erroneous usage is no argument to remove the field. -- Michael Bednarek (talk) 10:22, 2 October 2017 (UTC)

I agree with Michael Bednarek completely. If you know more than 10 people in the US under thirty, you most likely know at least one who has their area code tattooed on their body somewhere. To get back on the subject, care to address your feelings about my OP? John from Idegon (talk) 18:11, 2 October 2017 (UTC)

Alternate Flag / Logo field

I'd like to be able to have the ability to add an alternate flag, unofficial flag or alternate logo for a community, but there is a limit to one using this template. Another option would be to add a shield_type field, to change the coat of arms text to any other type of alternative logo or flag for an infobox. Would it be possible to add a field like this or even a flag_2 field category?

Thanks Maximilian77 (talk) 05:26, 23 December 2017 (UTC)

lang attribute for identically spelled names

Hi,

There are many places in non-English-speaking places that have native names written in the Latin alphabet identically to English. Adding native_name to them is unnecessary because it will just look repetitive. However, it still makes sense to mention the name's language in a structured way.

Does this change make sense?

• If native_name_lang is defined
  • and native_name is not defined
    • then apply lang="{{{native_name_lang}}}" to the name at the top of the box

--Amir E. Aharoni (talk) 08:16, 18 February 2018 (UTC)

Template-protected edit request on 10 March 2018

Can you update the links for ZIP code to ZIP Code and Federal Information Processing Standard to Federal Information Processing Standards Thanks! Nessie (talk) 22:42, 10 March 2018 (UTC)

Nessie, to make the change, you need to change the articles directly. the labels are added in the article, not by this template. you can find many of them with insource search 1 and insource search 2, including the article you just edited: Athens (village), New York. you may wish to make a WP:BOTREQ since there are so many. Frietjes (talk) 17:43, 11 March 2018 (UTC)

oops, sorry I missed that. Thanks for the info about the bot requests though! Nessie (talk) 19:07, 11 March 2018 (UTC)

adding the category "|HighestPoint ="

Hello reader! I am trying to make a worthwhile change to the Template talk:Infobox Province of China (PRC) Infobox template- adding the category "|HighestPoint =". Do you know anyone that edits infoboxes that can help me add this to the Province of China Infobox? I tried to do it myself but failed miserably. I asked some other people, but they didn't know either. Thanks for any help. Geographyinitiative (talk) 12:58, 7 April 2018 (UTC)

Examples out of date

Some of the example articles linked no longer use the listed infobox parameters; for example, Windsor, Ontario doesn't use "population_blank1_title" in its infobox anymore. The examples should be updated. --Avg W (talk) 02:32, 28 April 2018 (UTC)