Template talk:Infobox settlement/Archive 21

Archive 15

←

Archive 19

Archive 20

Archive 21

Archive 22

Archive 23

→

Archive 25

Geobox

I have proposed that we delete {{geobox}}. That may effect this template. You are invited to participate in the Geobox deletion discussion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:53, 3 January 2012 (UTC)

There are 2 things that Geobox has that this template doesn't: 1) a link to Commons within the infobox and 2) a link to a river or landmark within the infobx. Maybe a Commons link could be added? The river link could probably be added using a blank parameter. --Funandtrvl (talk) 02:00, 7 January 2012 (UTC)

I'm ambivalent to both of these (though I'd prefer a dedicated parameter to a blank one, whatever the subject). What do other people think? Are there other types of infobox with commons links? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:19, 8 January 2012 (UTC)

Also, note that the Geobox has links for Unesco, etc., whereas this tmp doesn't. --Funandtrvl (talk) 20:11, 9 January 2012 (UTC)

Native names

I've nominated {{Native name}} for deletion as redundant. Once that's gone, can we set up a tracking category for instances of this template with |native_name= but no |native_name_lang=? Then we can get them added; by a bot where possible. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:29, 16 December 2011 (UTC)

Be advised, this template has mainly been used in {{Infobox country}}, many country articles have it included: Special:WhatLinksHere/Template:Native_name. Styath (talk) 13:17, 17 December 2011 (UTC)

This is addressed in the TfD, and has no bearing here. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:04, 17 December 2011 (UTC)

The TfD failed for an unrelated reason, which is being addressed (an after which I will renominate), but in the meantime the tracking category would still be useful, please. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:50, 11 January 2012 (UTC)

Representation in higher levels of government

Could we add a section for representation in higher levels of government? Now I use the blank fields to add the fields "federal electoral district" and "provincial electoral district", but I would like that section to be right below the government section rather than tucked away at the bottom under the postal code. I think it would look something like this:

<!-- ***Representation in higher levels of government*** -->
{{#if:{{{rep_level1_house1_name|}}}{{{rep_level1_house2_name|}}}|
<tr class="mergedtoprow">
<th colspan="2">'''Representation in {{{rep_level1_legislature|National legislature}}}'''</th>
</tr>
{{#if:{{{rep_level1_house1_name|}}}|
<tr class="mergedrow">
<th>{{{rep_level1_house1_name}}}</th>
<td>{{{rep_level1_house1_seat}}} {{#if:{{{rep_l1h1_person1|}}}|{{Collapsible list|title=Members|1={{{rep_l1h1_person1|}}}|2={{{rep_l1h1_person2|}}}|3={{{rep_l1h1_person3|}}}|4={{{rep_l1h1_person4|}}}|5={{{l1h1_person5|}}}|6={{{rep_l1h1_person6|}}}}}}}</td>
</tr>
}}{{#if:{{{rep_level1_house2_name|}}}|
<tr class="mergedrow">
<th>{{{rep_level1_house2_name}}}</th>
<td>{{{rep_level1_house2_seat}}} {{#if:{{{rep_l1h2_person1|}}}|{{Collapsible list|title=Members|1={{{rep_l1h2_person1|}}}|2={{{rep_l1h2_person2|}}}|3={{{rep_l1h2_person3|}}}|4={{{rep_l1h2_person4|}}}|5={{{l1h2_person5|}}}|6={{{rep_l1h2_person6|}}}}}}}</td>
</tr>
}} }}{{#if:{{{rep_level2_house1_name|}}}{{{rep_level2_house2_name|}}}|
<tr class={{#if:{{{rep_level1_house1_name|}}}{{{rep_level1_house2_name|}}}|"mergedrow"|"mergedtoprow"}}>
<th colspan="2">'''Representation in {{{rep_level2_legislature|Regional legislature}}}'''</th>
</tr>
{{#if:{{{rep_level2_house1_name|}}}|
<tr class="mergedrow">
<th>{{{rep_level2_house1_name}}}</th>
<td>{{{rep_level2_house1_seat}}} {{#if:{{{rep_l2h1_person1|}}}|{{Collapsible list|title=Members|1={{{rep_l2h1_person1|}}}|2={{{rep_l2h1_person2|}}}|3={{{rep_l2h1_person3|}}}|4={{{rep_l2h1_person4|}}}|5={{{l2h1_person5|}}}|6={{{rep_l2h1_person6|}}}}}}}</td>
</tr>
}}{{#if:{{{rep_level2_house2_name|}}}|
<tr class="mergedrow">
<th>{{{rep_level2_house2_name}}}</th>
<td>{{{rep_level2_house2_seat}}} {{#if:{{{rep_l2h2_person1|}}}|{{Collapsible list|title=Members|1={{{rep_l2h2_person1|}}}|2={{{rep_l2h2_person2|}}}|3={{{rep_l2h2_person3|}}}|4={{{rep_l2h2_person4|}}}|5={{{l2h2_person5|}}}|6={{{rep_l2h2_person6|}}}}}}}</td>
</tr>
}} }}

In my example, the available fields are:

Parameter name	Usage	Description
rep_level1_legislature	optional	e.g. Parliament, Congress
rep_level1_house1_name	optional	e.g. Senate, House of Lords
rep_level1_house1_seat	optional	If there is only one seat you can name it or give the name of the seatholder, if there are several you can give the number of seats
rep_l1h1_person1 to rep_l1h1_person6	optional	The names of seat-holders (put in a collapsible list)
rep_level1_house2_name	optional	e.g. House of Representatives, House of Commons
rep_level1_house2_seat	optional	If there is only one seat you can name it or give the name of the seatholder, if there are several you can give the number of seats
rep_l1h2_person1 to rep_l1h2_person6	optional	The names of seat-holders (put in a collapsible list)
rep_level2_legislature	optional	e.g. State Congress, Provincial Parliament
rep_level2_house1_name	optional	e.g. State Senate, Legislative Counsel
rep_level2_house1_seat	optional	If there is only one seat you can name it or give the name of the seatholder, if there are several you can give the number of seats
rep_l2h1_person1 to rep_21h1_person6	optional	The names of seat-holders (put in a collapsible list)
rep_level2_house2_name	optional	e.g. State Assembly, Legislative Assembly
rep_level2_house2_seat	optional	If there is only one seat you can name it or give the name of the seatholder, if there are several you can give the number of seats
rep_l2h2_person1 to rep_l2h2_person6	optional	The names of seat-holders (put in a collapsible list)

For example, for the city of Kingston, Ontario, it would look something like this:

Representation in Parliament of Canada
Senate	Part of Ontario senatorial region
House of Commons	Kingston and the Islands
Representation in Ontario legislature
Legislative Assembly of Ontario	Kingston and the Islands

And the state of New York (if U.S. states used this template) would look something like this:

Representation in United States Congress
U.S. Senate	Members Charles Schumer (D) Kirsten Gillibrand (D)
U.S. House delegation	21 Democrats, 8 Republicans

—Arctic Gnome (talk • contribs) 07:12, 26 November 2011 (UTC)

This has been here for almost a month. Are there no objections to me unilaterally implementing it? —Arctic Gnome (talk • contribs) 19:30, 24 December 2011 (UTC)

I haven't had the opportunity to test this yet. For now, I'll leave a note here so that when I do test it, the proposal itself will not have been archived. —Arctic Gnome (talk • contribs) 18:42, 24 January 2012 (UTC)

I support this addition, in principle. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:25, 3 February 2012 (UTC)

Issues

Precision

What's going on with the autoconversions in this template? Let's have a look at a few transclusions. I've just gone to the "What links here" and clicked on the first half dozen links. Here's what I found.

• The Ankara article converts 2,516.00 km² to 971.4 sq mi and 1,551.00/km² to 4,017.1/sq mi. The area input was precise to the nearest hectare, the output to the nearest tenth of a square mile, about 26 time less precise. The precision of the density, on the other hand, was reduced by a quarter, which is reasonable. Of course, we might wonder whether the input precision is correct in the first place. It probably isn't. I looked at what we get when we use 2,516 km² and 1,551/km². We get the same: 971.4 sq mi and 4,017.1/sq mi, an almost fourfold inrease in precision in the area and a twenty-sixfold inrease in the density precision.
• The Amsterdam article converts 219 km² to 84.6 sq mi, 166 km² to 64.1 sq mi, 53 km² to 20.5 sq mi, 1,815 km² to 700.8 sq mi and 3,506/km² to 9,080.5/sq mi. Again we're getting four times the area precision and twenty-six times the density precision.
• The Aarhus article does the same: the precision of areas given to the nearest square kilometre is quadrupled by rounding the conversion to the nearest tenth of a square mile and the precision of densities input as individuals per square kilometre is increased twenty-six times.
• The Ames, Iowa article has a different problem. Inputs to the nearest hundreth of a square mile are converted to the nearest tenth of a square kilometre. This is perfectly reasonable most of the time but it means the 0.01 square miles is converted to 0.0 square kilometres.
• The Anbar (town) and Abydos, Egypt articles had no units.

The problem is that the template defaults to rounding to one decimal point regardless of the input precision. This has been mentioned before ...

• Template talk:Infobox settlement/Archive 5#Two Elevation Equations
• Template talk:Infobox settlement/Archive 6#Precision of square miles and square kilometers
• Template talk:Infobox settlement/Archive 17#Rounding

... but the best solution offered so far seems to be to specify both. If, though, we're specifying both whenever the autoconversion gives us inapproprite precision, we'd just about always be doing so. This won't do. I suggest we use input-sensitive rounding like that of {{convert}}. JIMp _talk·cont 06:20, 6 February 2012 (UTC)

If the conversion is told what precision to use, it's more efficient than if it tries to work out the precision based on the number of significant figures. Omitting the precision can even cause the conversion to break: see discussion at Template talk:Infobox#Infobox historic site. --Redrose64 (talk) 14:35, 6 February 2012 (UTC)

At present we have just that: the template code is telling us what precision will be used. What we have is areas and densities converted to the nearest one decimal place and elevations to zero decimal places. In general this is inappropriate. The only way around this currently offered by the template is to do the conversion yourself. This is very inefficient. Inefficient, that is, on the user's end, but I think you're talking about efficiency in terms of keeping within template limits. The problem they talk about on the page you mention is one of transclusion depth. Too many transclusions within transculsions within transclusions eventually breaks the template. This is a known problem. It can be avoided. JIMp _talk·cont 15:53, 6 February 2012 (UTC)

Density calculation

If no density is given, the template will calculate it for you ... if you ask it to. For this calculation you have to set the density parameter to auto. Why not just make it the default behaviour? Would it be not better to ask it not to do the calculation if you don't want it to?

Well, that's something to mull over, but again we've got the situation where the calculation is rounded to one decimal place regardless of the input. To fix this I suggest using {{pop density}}, which bases its rounding on the precision of its inputs (both the area and population). JIMp _talk·cont 05:36, 8 February 2012 (UTC)

Linking

It's interesting that whilst the template as a whole takes a one-size-fits-all attitude to rounding its conversion subtemplates currently allow for the precision to be specified. Another thing they allow for is linking of units. Neither of these capacities are being used. Specifying one's desired precision is one capacity I'd ditch replacing it with autoprecision as I'm suggesting above. Linking units, on the other hand, is undesireable (except for the little known dunum but that doesn't make it to the conversion subtemplate). I'm suggesting we just forget about unit linking altogether. JIMp _talk·cont 03:23, 7 February 2012 (UTC)

Area magnitude

Whilst we're talking about linking; it is possible to get the total area to link up to one of the orders of magnitude pages. All you have to do is set the area magnitude parameter to the appropriate code (e.g. 1 E8) ... which is kind of tedious when the template could be recoded to calculate the appropriate code itself ... then a link appears on the total number of square kilometres. Why on the number? The unit is part of the area too. It would be better to link the whole thing. Perhaps it was set this way so as not to get in the way of a link to the unit but there is no such link now. Why on the square kilometres? If square miles are being used as the main unit, why not link from them? These order of magnitude pages are based on SI, yes, so what? An area's an area regardless of the unit it's measured in. JIMp _talk·cont 05:36, 8 February 2012 (UTC)

Addressing the issues

I've been playing in the sandpit. I've started with dunums. Some of the changes I've made so far are just reorganising the code so it's easier to read. Some of the changes simplify the code. Some changes, though, change what the template does. Here they are:

• The live version will give you "1 dumums", where it should, of course, be "1 dumum". The version in the sandbox deals with this.
• When converting from dumums the live version separates the square kilometres and square miles with slash. Since slashes look like division, I changed this to an "or".
• The default precision is one decimal place with the live version regardless of the input. The sandbox uses {{convert}} to convert dumums and so uses the default precision of {{convert}}. This means the output precision is now dependant on the input precision.
• Whilst I was at it I made the {{{name}}} parameter optional. If neither {{{name}}} nor {{{official_name}}} are specified, it defaults to the page name.

JIMp _talk·cont 15:53, 6 February 2012 (UTC)

The sandbox is now using quite a different code: new subtemplates, new code at some old subtemplates (lenghtdisp, areadisp & densdisp currently have both old & new code) and some old subtemplates are unused. I've made the changes mentioned above. Using {{pop density}} turned out to be impossible: it looked like I hit the template depth limit; this is the problem discussed above. I got around this by subtsing the algorithm out of {{pop density}} and then simplifying the resultant calculation. So here are the new changes to what the template (i.e. the sandbox as yet) does.

• The rounding of the output is dependent on the precision of the input. This goes for simple conversions as well as for density calculations from population & area (two inputs mean we've got to consider the precision of both).
• The order of magnitude link is turned on by setting the parameter to any non-blank string (the user doesn't have to calculate it). The correct link is calculated from the input. The link is from the main unit (whether metric or not). The whole value is linked (not only the number but the unit as well).

JIMp _talk·cont 13:30, 9 February 2012 (UTC)

Implimentation

I have checked to see whether the new code is working properly. Everything looks okay. I'll be putting the new code in place in a few moments. If anything is broken, please let me know. JIMp _talk·cont 22:55, 9 February 2012 (UTC)

Edit request on 11 February 2012

Please change "{{{name|{{{official_name|{{PAGENAME}}}}}}}}" back to "{{#if:{{{name|}}}|{{{name}}}|{{{official_name}}}}}". folks often cut and paste the blank version of this template and only fill in one of these two fields. This has screwed up many articles including Pretoria.

Frietjes (talk) 16:57, 11 February 2012 (UTC)

Done. Plastikspork _―Œ^(talk) 19:29, 11 February 2012 (UTC)

I see what happened. Because the {{#if:}} is gone the blank space which name is set to becomes the infobox title. How about {{#if:{{{name|}}}|{{{name}}}|{{#if:{{{official_name|}}}|{{{official_name}}}|{{PAGENAME}}}}}} then? JIMp _talk·cont 16:56, 12 February 2012 (UTC)

Yes; it's sometimes forgotten that a blank parameter is not the same as an absent parameter. The construct {{{a|{{{b}}}}}} means "if |a= is absent, use the value specified by |b=, but if |a= is present, use that and ignore |b= even if |a= is blank". As you surmise, the more complex construct {{#if:|{{{a|}}}|{{{a}}}|{{{b}}}}} gets over the problem of |a= being present but blank. So, I agree that the proper fix is

{{#if:{{{name|}}}|{{{name}}}|{{#if:{{{official_name|}}}|{{{official_name}}}|{{PAGENAME}}}}}}

(Is this a good time to mention a similar problem with |coordinates_type=?) --Redrose64 (talk) 19:05, 12 February 2012 (UTC)

Yes, it's easy to forget. I s'pose it's a fine time to mention the simialr prob. JIMp _talk·cont 04:48, 13 February 2012 (UTC)

Density = auto

It used to be that the placement of the 'auto' in the density field would determine which units were used to compute the density. This shouldn't be a major problem, but for some places, the area is so small, that the area in square miles is zero. The result is division by zero if we use the square miles to determine the density. I have now fixed about two dozen of these, for example here. I don't think it's a problem in any of the cases that I have seen, but something to look out for. Thanks! Plastikspork _―Œ^(talk) 21:37, 11 February 2012 (UTC)

If the area in square miles is zero ... really zero, then the place doesn't exist. If we get zero square miles after rounding, we're using the wrong rounding. If we're inputting a wrongly rounded number, we're inputting bad data. This falls under the heading of garbage-in garbage-out. Users should not be putting such values into the template ... but, of course, they are. There is, however, a solution. We can check for zeros. If a zero is input, we can just ignore it ... better still we can track it down and remove it too. Now, here's another point worth considering. If the place is so small, why are we using square miles and square kilometres? "25 acres (10 ha)" makes more sense to me than "0.04 sq mi (0.1 km²)". JIMp _talk·cont 04:21, 12 February 2012 (UTC)

I've added a check for zeros in the input to densdisp. JIMp _talk·cont 16:35, 12 February 2012 (UTC)

Tracking and fixing the division by zero is not a bad idea. I found all of them by checking Category:ParserFunction errors, which appears to be fairly routinely patrolled. If there is another mechanism for finding them, then that's fine as well, but the original method seems to work too. Thanks! Plastikspork _―Œ^(talk) 16:50, 12 February 2012 (UTC)

Great, if you've found them, we don't have to search for them. What I'd had in mind was calling an empty subtemplate whenever we get a zero in the input and we could then track down the offending page by checking the subtemplate's what links here. Note that the template won't produce these parser errors now that I've recoded densdisp to ignore zeros. JIMp _talk·cont 17:07, 12 February 2012 (UTC)

So long as we have a mechanism for finding them when the pop up, that works for me. I cleared about 80 or so errors, but these things frequently don't show up until the server recaches the pages, so we should keep a method for finding them latter as well. Plastikspork _―Œ^(talk) 17:34, 12 February 2012 (UTC)

I see what I can do. I suppose people might still keep putting garbage in especially when we recognise it and don't put garbage out. Perhaps we need a big red error message. JIMp _talk·cont 17:40, 12 February 2012 (UTC)

Infobox Townlands TfD

Discussion at TfD:Infobox Townlands may be of interest; in particular the proposed addition of name derivation parameters to this template; and suggestions that this template is misnamed; and difficult to use. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:23, 20 February 2012 (UTC)

flagcons in settlement infoboxes

First, there was a discussion on this template regarding flag usage back in 2010. The issue was mainly regarding technical aspects (metadata, etc.) Since then the template documentation has had an admonishment to not use flagcons in the lines for higher level political entities for communities. Next, this discussion is limited to the posting of flags or flag icons other than the flag of the particular community. With this background, I will point out that there's been some other debate about the usage of such icons. (Specifically, the Wikipedia talk:WikiProject Geography.) Of note, many settlement articles (perhaps thousands) have such icons. But very few (if any) Featured Articles for settlements have them. (Also, in a random check of 10 settlement articles I saw only one of the ten with such icons.) This is not an earth shaking issue for me, but my view is to keep such icons out of the infoboxes. They simply serve to clutter the box and impart very little useful information. This view is in keeping with WP:MOSFLAG#Avoid flag icons in infoboxes and WP:IBX#Purpose_of_an_infobox If we can reach a consensus that such icons do not belong, then edits to remove such icons will be justified. My proposal is to leave the admonition as is. --S. Rich (talk) 01:31, 13 February 2012 (UTC)

Could you provide examples of articles where they are being used?--JOJ ^Hutton 01:43, 13 February 2012 (UTC)

Will do. Give me a few minutes. In the meantime, the specific admonition is here: Template:Infobox_settlement#Location.2C_established.2C_seat.2C_subdivisions.2C_government.2C_leaders.

Look at Detroit, Michigan (a FA); El Cajon, California; Mission Viejo, California --S. Rich (talk) 02:16, 13 February 2012 (UTC)

Also Santee, California ;-) --S. Rich (talk) 02:18, 13 February 2012 (UTC)

This has been discussed before here Template:Infobox settlement/doc and at WP:GEOGRAPHY. That WikiProject permits the usage. Whether it's clutter, or an appropriate use of the multimedia nature of the WP, seems to be more opinion than anything else. There was at one time a technical reason for the admonition, that has since been fixed. There are hundreds of thousands of articles with flags in infoboxes, of one form or another - so 1 out of 10 is just a small sampling. In any event, putting guidelines in documentation pages of templates seems hardly the way to go - once the technical reason for the language was overcome it's retention is cruft. Since the WP GEOGRAPHY permits icons, we'll just construct different templates with different documentation if the WIKILAWYERS make us. Carlossuarez46 (talk) 03:23, 13 February 2012 (UTC)

" That WikiProject permits the usage" - Per WP:LOCALCONSENSUS, wikiprojects do not have it in their gift, to permit or prohibit anything. And rightly so. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:28, 20 February 2012 (UTC)

If you know anything about how I edit, you will know that I am a huge opponent of flags in infoboxes. They are way overused, distracting, unnecessary, and in no way convey any information that cannot be stated with simple text. That said however, I do recognize instances where flags may be appropriate. Geographic/settlement articles may be one of those few exceptions, and when I come across them, I usually leave them in. I would not however stand in the way of creating a guideline that discourages their use in these articles and may even support one. Until that time, however, there is no guideline or MOS that discourages them at this time.--JOJ ^Hutton 03:38, 13 February 2012 (UTC)

Seems to me that the template page is the best place to discuss, not a Project page. Indeed, in this particular template the admonition has been in place for a few years while the Project "guideline" is much more recent. And where does it say that Projects are the place where WP promulgates guidelines? The discussion I initiated at Project GEOGRAPHY was to get the issue moved to the proper page, e.g., the template or MOS. Also, saying that thousands of articles have a poor presentation is not a well-founded rationale for poor editing! (So, please leave the template as is (with the admonition about keeping icons out) until we reach consensus on this page.) --S. Rich (talk) 03:47, 13 February 2012 (UTC)

Further comment -- as linked above, the MOS:FLAG does discourage flagcon usage.--S. Rich (talk) 04:05, 13 February 2012 (UTC)

Yes, and WikiProjects can opt out of the "discouragement" - as has been done by the military project, the olympics folks, and the geography folks. Carlossuarez46 (talk) 04:09, 13 February 2012 (UTC)

• This statement is incorrect. Per WP:CONSENSUS#Level_of_consensus "... For instance, unless they can convince the broader community that such action is right, participants in a WikiProject cannot decide that some generally accepted policy or guideline does not apply to articles within its scope." [Emphasis added.] --S. Rich (talk) 20:03, 14 February 2012 (UTC)

• The statement may be technically correct but as a matter of common practice it is heavily used on wikipedia. Projects and administrators routinely igmore guidelines and go with a project's consensus all the time. Tennis project has always used flag icons in the infoboxes per tennis project consensus and hockey project uses guidelines that go against wiki guidelines all the time. And don't even get me started on the policy of using diacritics. The point is that I have found overwhelmingly that consensus within a project rules at wikipedia. Fyunck(click) (talk) 22:35, 14 February 2012 (UTC)

When this was discussed previously, as I pointed out above - it was decided to remove the comments. Now people like User:Srich32977 put them back in without any supporting discussion supporting their re-introduction, merely that a discussion is ongoing. If we're discussion something, that doesn't give a basis to readd material that prior discussion had removed; it's this intellectual dishonesty that makes the wikilawyers and nitpickers ruin this project for the regular contributors. But, they can by brute force do what they please because when they cannot win consensus in any intellectual discussion - that's what they resort to. Carlossuarez46 (talk) 04:09, 13 February 2012 (UTC)

[1] --S. Rich (talk) 04:29, 13 February 2012 (UTC)

That discussion is ongoing is good enough reason not to remove a comment which exists for years. I am not aware of wide consensus to remove these comments, so what's the hurry? --Muhandes (talk) 14:39, 13 February 2012 (UTC)

To get this discussion back on track -- are flag icons appropriate on the settlement template? If not, the document admonition to leave them off should remain unchanged. If they are appropriate, even if optional, the documentation should be revised. (Also, there is no rush to revise the guideline. We can certainly wait a few days or weeks to see what other editors think.) --S. Rich (talk) 04:43, 13 February 2012 (UTC)04:45, 13 February 2012 (UTC)

I'll pick off a low-hanging fruit and suggest, in line with MOSFLAG, that sub-national flags (for the examples above, US states) are never acceptable. They are neither widely recognized nor, at icon resolutions, even recognizable; nearly all state flags are of the format "blue with splotch in the middle". Jpatokal (talk) 04:55, 13 February 2012 (UTC)

• I don't see why this template should not comply with MOS:FLAG. The reasons stated there mostly apply: flag icons do not convey any extra information in addition to the text, they are visually distracting and they lead to unnecessary disputes. In other words there is zero benefit in the flags, and only what to lose. I have not heard from any of the editors supporting the flags any argument explaining what we are gaining from allowing them against MOS:FLAG, other than WP:ILIKEIT. --Muhandes (talk) 14:33, 13 February 2012 (UTC)

• For one thing that MOSFLAG statement has not been static very long and people have added to it with no input whatsoever. The line "flag icons do not convey any extra information in addition to the text, they are visually distracting and they lead to unnecessary disputes" was added without anyone realizing it... there was no discussion, there was no consensus. Once someone did realize it it was removed but the original writer complained and somehow it's still there when it shouldn't be. So MOSFLAG is not some carefully constructed, well argued guideline for everyone to follow blindly. Fyunck(click) (talk) 22:35, 14 February 2012 (UTC)

• I haven't heard of a rationale for MOS:FLAG other than WP:IDONTLIKEIT. Disputes? Does anyone dispute that Detroit is part of the United States and Michigan? Hardly. We're multimedia, which means liberal use of images, icons, etc. adds not detracts from our articles. If any of you feel that flags are distracting remove them from The Championships, Wimbledon and List of titles and honours of Queen Elizabeth II and see how long those edits will last. If debating guidelines aesthetic or otherwise on a talk page of a documentation page of a single template seems odd to anyone else, feel free to chime in. Carlossuarez46 (talk) 16:11, 13 February 2012 (UTC)

• The example "List of titles & honours for QEII" is off-point. The article certainly has a variety of flagcons, but this discussion is about flagcon usage in the settlement infobox. As for the Grand Slam, the exemplar infobox has flagcons, but most other tennis topic templates do not. Also, the Wimbledon template is very small/short. The settlement infobox is quite long and complex. (Besides, saying that other infoboxes -- however few -- have flagcons is akin to a WP:OSE argument.) While this discussion is about a particular template, MOS:FLAG mentions that flagcons are explicitly prohibited in certain other infoboxes. The question here is whether the explicit prohibition in the settlement infobox guideline should remain as is. --S. Rich (talk) 17:22, 13 February 2012 (UTC) 18:01, 13 February 2012 (UTC)

• Since your whole argument is based on MOSFLAG, examination of what logical underpinnings it has - whether any consensus has developed on it and whether it reflects the community's usage - is not OSE, its part and parcel of the debate. Apparently, you take the position that if we just set up a different template and call it "inbofox geographic place" that this entire debate is irrelevant - cause this would just be OSE in any discussion at that template. Carlossuarez46 (talk) 18:30, 13 February 2012 (UTC)

• I do not take the position that "we just set up a different template". The suggestion that I do is a distortion. I initiated this discussion IOT resolve whether template guidance -- the explicit guidance for this infobox -- should remain. The logical underpinnings for not using flags in infoboxes are set forth in MOSFLAG: "Generally, flag icons should not be used in infoboxes, even when there is a 'country', 'nationality' or equivalent field: they are unnecessarily distracting and give undue prominence to one field among many.... Flag icons are visually distracting in infoboxes and lead to unnecessary disputes when over-used." --S. Rich (talk) 19:01, 13 February 2012 (UTC)

As I have repeatedly said - show me the discussion where consensus was established on that text. Carlossuarez46 (talk) 21:01, 13 February 2012 (UTC)

I've repeatedly asked for this consensus to be produced in discussions at Wikipedia talk:Manual of Style/Icons, but none was ever forthcoming. Chunks of MOSFLAG appear to have been added with no consensus whatsoever, particularly the "visually distracting" argument, which is utterly spurious. Massive overuse and repetition is sanctioned by the MOS in some articles/infoboxes, regardless of the so-called "visual distraction", yet in other articles even one single flag is deemed inappropriate. If no consensus debate can be produced, then there is no consensus for the MOS. Bretonbanquet (talk) 21:08, 13 February 2012 (UTC)

In response, the MOSFLAG guideline started off as an essay back in 2006, after a few hundred edits it evolved to a proposed guideline and then guideline [2] in October 2007. Off and on there were various icon discussions, but they did not address the use of flagcons in the settlement infobox. (Nor did they reach consensus.) Throughout its' history the MOSFLAG guideline has been generally critical of flagicons. (And since it has been published as an "official" guideline, it does have weight.) But I bring up the topic here because of the template guidance that explicitly bans such icons. Perhaps it should be changed, and if so changed then the MOSFLAG guideline can be modified to reflect the exception. As for this discussion, I see 19 a discussion that mainly involves the technical aspects of icon placement. It did not seem to change the admonition about non-use of flagcons. In any event the lack of prior discussion (or consensus) does not support an argument for or against usage of flagcons in this template. To garner interest from concerned editors, I've posted invitations to different city related Project talk pages about this discussion. Let's see what input we get.--S. Rich (talk) 23:12, 13 February 2012 (UTC)

• In looking at 40 of the WP:GA places articles listed on WP:Good_articles/Geography_and_places#Places, I counted 33 article infobox templates without flagcons, 6 infobox templates with flagcons, and 1 that had sister city icons both in the infobox and text. My survey was limited to US cities. For WP:FA#Geography_and_places, I looked at 19 articles. 15 did not have flagcons and four (Detroit, Kent OH, Loch Haven PA, & Stephens City NV) had flagcons. Again, my survey was limited to US settlements. Of 5 former WP:Former_featured_articles with infoboxes, none had flagcons. --S. Rich (talk) 02:00, 14 February 2012 (UTC)02:35, 14 February 2012 (UTC)

• Expanding my icon/no-icon survey to non-US articles, I found the following: FA's -- 40 without flagcons, 7 with, and 1 with twin city flagcons; Former FA's -- 14 without flagcons, 5 with; GA's -- 138 without flagcons, 20 with.
• Grand total: 245 articles without flagcons, 42 with flagcons, 2 with twincity flagcons
• Total for US cities: 71 articles, 60 without icons, 11 with; 15% of the US articles have flagcons
• Percentages: 15% of the 289 articles (US + non-US) have flagcons
• Those settlements with flagcons are spread around the world
• FYI, Redrose, I think Birmingham is the only UK settlement with flagcons -- UK articles constituted the majority/plurality of non-US articles I looked at.
• --S. Rich (talk) 19:45, 14 February 2012 (UTC)

• Speaking as a Limey, I recognise very few US state flags and actually care about just one of them - the flag of President Obama's native state has our national flag in the canton (although I do like California's - the name of the state is clearly readable, and there's a nice picture of a bear too). So, to me, state flags in infoboxes are just WP:ICONDECORATION. --Redrose64 (talk) 10:37, 14 February 2012 (UTC)

• Well said, and exactly my point of view. --Muhandes (talk) 13:08, 14 February 2012 (UTC)

• Guidelines promulgated absent consensus have little to no weight; that's why we have WP:IAR. Carlossuarez46 (talk) 16:51, 14 February 2012 (UTC)

Personally, thinking specifically of settlements -- I don't feel that the presence of flags in infoboxes is "distracting", and I do not see that they give "undue weight" to some fields compared to others, though both of these are given as reasons to omit the flags. In general, I feel that the inclusion of flags benefits the reader. Omnedon (talk) 17:08, 14 February 2012 (UTC)

• Since User:Srich32977 concedes that WP:LOCALCONSENSUS applies: nothing decided here can have any bearing on usage of this template or whether flags should or should not be in geographic articles. Any editors found removing flags do so with no consensus to support their position. Carlossuarez46 (talk) 21:58, 14 February 2012 (UTC)
  • Sorry, but at 16:51, 14 February 2012 you mentioned WP:IAR. Removal of flags may therefore be done with impunity. And what does "Guidelines promulgated absent consensus" mean, exactly? --Redrose64 (talk) 22:37, 14 February 2012 (UTC)
  • You misunderstand IAR. Otherwise someone may block you with impunity by ignoring all rules. Isn't that what your position also allows? Carlossuarez46 (talk) 23:08, 14 February 2012 (UTC)
    • The other comment above is a misapplication of LOCALCONSENSUS. That policy says Project members cannot override guidelines or policies. As this particular template is of interest to several groups and projects, it is certainly appropriate to work towards consensus as to proper format for this template. And the discussion here is to determine if the template guidance to avoid flagcons in settlement infoboxes should remain. (The MOSFLAG guidance was reached after a long series of edits -- which certainly indicates consensus building was at work. This discussion is regarding a particular admonition in a particular template about adding flagcons, and the admonition is supported by existing, published guidance. (Whether that guidance is followed is another question.) To cite IAR only invites (more) edit wars! Let's reach a consensus so that template guidelines can be resolved! Today is Tuesday -- this discussion can certainly remain open for a week to allow weekend Wikipedians to participate. Until then any attempt to close this discussion or to change MOSFLAG guidance is premature.--S. Rich (talk) 22:54, 14 February 2012 (UTC)
• Again, you misapply policy. If this only has to do with this template, than creating a different template to serve different needs will be wholly unaffected by this discussion. You cannot have it both ways. Carlossuarez46 (talk) 23:08, 14 February 2012 (UTC)
  • This comment is difficult to understand. What discussion has there been about creating a "different template"? If we can resolve the admonition in this template about flagcons, then we either reach a consensus that they are not appropriate or we reach a consensus that they are. If this discussion decides they are appropriate, then an exception to MOSFLAG can be implemented. --S. Rich (talk) 23:51, 14 February 2012 (UTC)

(outdent)Since I was one of the editors whose actions resulted in this section, I figured I should finally make a statement here. I feel that the use of flagicons in the settlement infobox adds no encyclopedic information that is not convened with just using the link. I do not think saying thousands of articles use flagicons is a compelling argument because it points out that there are thousands, and probaly more, articles that do not use. I appreciate S.Rich for compiling the data so we have some measurable definitions and that showed the majority of FA/GA articles do not use flagicons. Aspects (talk) 06:23, 23 February 2012 (UTC)

Proposed compromise

Duh! S. Rich, didn't you notice how a significant of FAs & GAs have passed various reviews and received accolade status even though they contain flagcons in the infoboxes?

Why, yes I did, S. Rich. That's why I did the research and put up the numbers. What do you think this means?

Well, as I have thought about this, it seems the various reviewers who looked at those articles didn't give thumbs down because of the flagcons – maybe it's time to propose a compromise. Besides, I'm getting sick of the discussion. Please tell me, S. Rich, what do you propose?

Well, S. Rich, here is my idea. We add the following to the template parameter descriptions:

1. "Flagcons are allowed [in infoboxes] for the nation and the political entity immediately below the national level. Lower level flagcons (for example, counties, parishes, etc.) are not allowed. Mixed presentation of lines with and without flagcons is not allowed."

2. "Flagcons for twin cities are allowed in either the infobox or article text, but not both. Such flagcons (in the infobox) must be for the twin city and not the nation of the twin city."

Rationale -- The number of flagcons will be limited to two. Clutter from entity flagcons and twin city flagcons will be reduced.

My gosh, S. Rich, that is absolutely brilliant! Why don't you click the "Save page" button.

Thank you, S. Rich. I shall. --S. Rich (talk) 02:27, 15 February 2012 (UTC)

• You're welcome and I can compromise on those lines. Carlossuarez46 (talk) 06:19, 15 February 2012 (UTC)

• Modification to proposal:

1. "Flagcons are allowed for the nation and the next lower political entity. Lower level flagcons (e.g., counties, parishes, etc.) are not allowed. Mixed presentation of lines with and without flagcons is not allowed. Use short county names ({{flagcountry|USA}} → United States), not country codes ({{flag|USA}} → USA) or full country names ({{flag|United States of America}} → United States of America)."

2. "Flagcons for twin cities are allowed in either the infobox or article text, but not both. Flagcons in the infobox must be for the twin city and not the nation of the twin city."

Rationale -- The number of flagcons will be limited to two. Clutter from entity flagcons and twin city flagcons will be reduced.

Further Rationale -- Shortens verbage, gives examples, and clarifies that we do not see entries like USA or United States of America mixed with Virginia.--S. Rich (talk) 16:41, 15 February 2012 (UTC)

• I think this proposal is very much US centric. Did you think how it will look for Indonesia? Yemen? Israel? I don't think even the local population of some nations is aware of the flags of the "next lower political entity". Are we seriously going to add to the documentation text that explicitly allows the inclusion of flag icons for the Provinces of Indonesia, Governorates of Yemen and Districts of Israel? To what end? --Muhandes (talk) 18:40, 15 February 2012 (UTC)

• My use of these flagcons in the proposed documentation was not intended to be US-centric -- it was simply easier to find these icons IOT illustrate the proposal. But your comment does illustrate how, in general, allowing or using icons below the national level becomes a US/Canadian- centric practice. That is, all of the US states & Canada provinces have flagcon templates available. But do flagcon templates exist for those divisions of Indonesia, Yemen, Israel, etc? I think not. With this in mind, displays of flagcons or flag images of lower level political divisions allows more and more flag waving depending upon how many lower division flagcons (or images) are available. border|25px . So is the best compromise a documentation that simply allows national flags?--S. Rich (talk) 20:40, 15 February 2012 (UTC)
• @Muhandes, those subdivisions have no flags, so your question answers itself. Carlossuarez46 (talk) 17:49, 16 February 2012 (UTC)

There really is no consensus not to use flags. People who don't like em just invent a user preference to hide flag icons, plain and simple.♦ Dr. Blofeld 18:54, 15 February 2012 (UTC)

• Actually here are the instructions for that user preference: WP:WikiProject_Flag_Template#User_preference_to_disable_display_of_flag_icons. We might add that to the documentation. What I hope to reach is a decision to either remove the "don't use" admonition or add something that does allow flagcons within reason. (Having the present prohibition just generates edit-wars.) As just stated above, how about national flags only?--S. Rich (talk) 20:40, 15 February 2012 (UTC)

• Preferences can't be used by readers without accounts, which may amount to most our readers, so it's half a solution at best. I have no problem with removing the "don't use" admonition if there is no consensus for it. I think the de facto standard (and hence consensus) for many nations (I randomly sampled France and Netherlands for instance) is not to use them, so allowing them explicitly, even in the national level, would seem like being against consensus too. I can support too solutions. a) Leave it empty. Editors will war, but the standard for each nation will prevail. b) Something like "regarding the use of flag icons in this field, use the standard for the nation, and consider the general guidelines for use of flag icons." That way we stick to current de facto standard but also give the rationale for not using where it isn't used. --Muhandes (talk) 07:38, 16 February 2012 (UTC)

• Users without accounts haven't stated an opinion on whether they perceive clutter or not - so it's nothing but conjecture. If they do, they can always set up an account - having the ability to set preferences is one of many benefits of them doing so. Moreover, many countries have no flags for their highest level of subdivision: Iran, Azerbaijan, Israel, Turkey, Indonesia, China, among many other countries, so only one flag will appear on articles for places in those countries. Carlossuarez46 (talk) 17:46, 16 February 2012 (UTC)

• Casa Blanca, California is an example where lots of flags can be inserted. ;-) --S. Rich (talk) 18:09, 16 February 2012 (UTC)

• Without retracting my agreement on your compromise - the flags did add information, because I didn't know that Riverside County nor that Riverside city even had flags. See they can be educational... ;-) Carlossuarez46 (talk) 22:26, 16 February 2012 (UTC)

• You missed the main point of my argument. If one brings the abundance of infoboxes with icons as proof that the de facto consensus is to allow them, one must also accept that the de facto consensus for many nations is not to allow them. Adding an explicit statement that allows them is against consensus. --Muhandes (talk) 07:14, 17 February 2012 (UTC)

• It's a bit of a stretch to suggest that Turkey, Israel, and Iran (who agree on little), have decided not to have flags for their first order subdivisions because they want to show consensus to have infoboxes on wikipedia to not display their flags. An interesting assertion, but one that I have a hard time believing. Carlossuarez46 (talk) 17:40, 17 February 2012 (UTC)

• I think you mis-read the point (or perhaps Muhandes did a poor job in expressing it). We really don't know if various nations allow or don't allow/have or don't have flags for their lower division entities. An absence of available flagcons on WP does not point one way or the other on that off-topic question. Muhandes makes a better point when s/he says the majority of articles do not have flagcons in their settlement infoboxes, thus pointing to a tacit consensus not to use them. I am thinking if the settlement infobox parameter "bans" infoboxes, it only invites edit wars because one side says "Look - icons!" while the other says "Look - banned!" --S. Rich (talk) 18:14, 17 February 2012 (UTC)

• It's an interesting question whether more articles do or don't have them - indeed many created by me don't, but they were created at a time when there was a bug in the template that crashed when included or before I knew that the bug has been fixed. What is the ratio post bug-fix? Again, permitting them is not requiring them. Carlossuarez46 (talk) 18:50, 17 February 2012 (UTC)

• The fact remains that there is a de facto standard, and explicitly adding a comment saying "you can go against the standard" seems counterproductive to me. I proposed to either a) Remove the admonition and add nothing instead, or b) add something like "regarding the use of flag icons in this field, use the standard for the nation, and consider the general guidelines for use of flag icons." --Muhandes (talk) 16:41, 21 February 2012 (UTC)

• Removing the admonition is what will stop the edit warring and unproductiveness. As for what is the std for the nation, I can take or leave; because the std for some is basically whatever the last editor to touch the article makes it - an no one should be made to count how many articles in any country do, or don't, have flag icons before s/he edits. Carlossuarez46 (talk) 18:08, 21 February 2012 (UTC)

(outdent)I have three main problems with the proposed compromise. First, it seems to ignore four editors who expressed a national flag is appropriate, but that subnational flags are not. Second, it does not really seem like a compromise since what I see as current use at the most is two flagicons, the national flagicon and a state/province/region flagicon. Through my editing I have only found one article, Los Angeles County [3], that had three flagicons.Third, the point about twin cities seems to come out of nowhere. I honestly feel this is one of the most trivial pieces of information about cities in the articles and do not think they need to be mentioned in the infobox since it should summarize the main points of the article. Do many of the articles that use this template contain flagicons for twin cities in the infobox, because I have not seen any that have.

For the most part, the use of subnational flagicons seems to be a US/Canadian focus. So taking into account all of the opinions expressed, I would say that consensus could be formed for just allowing the national flag in the infobox and removing the part about twin cities because there have been no opinions about them. Aspects (talk) 06:23, 23 February 2012 (UTC)

Well said, and thanks for your input. (I've been wondering when you'd chime in.) As you have restated a/the consensus quite well, I'll add the appropriate admonitions – tomorrow.--S. Rich (talk) 07:15, 23 February 2012 (UTC)

Name derivation parameters

I propose that we copy the name derivation parameters from {{Infobox Townlands}}, to this template. any comments? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:11, 22 February 2012 (UTC)

Automatic density calculation

Do we really need FOUR decimal figures in the density field? This kind of accuracy is rarely warranted except maybe for semi-deserted places like Greenland. See Sancti Spíritus Province for an example of this issue.--Nero the second (talk) 14:05, 22 February 2012 (UTC)

It's rarely warranted even in those cases; can anyone tell the difference between 0.3528 people per sqkm and 0.3527 or 0.3529? Carlossuarez46 (talk) 17:19, 22 February 2012 (UTC)

It had been designed to base output precision on that of the input. So the figures were very precise but not falsely precise. I've adjusted it so that it ignores any more than four sig figs in the input. That should get things looking nicer. JIMp _talk·cont 19:00, 25 February 2012 (UTC)

Civil parishes

Since {{Infobox Townlands}}'s TfD was closed, with a recommendation to "refactor the template as a frontend, and then discuss the merits of having the template as a frontend vs. substituting it", its documentation has been re-written, suggesting that it also be used for civil parishes. These are aleady adequately catered for by {{infobox settlement}} (or {{Infobox UK place}} / {{Infobox NI Civil Parish}} in some cases). Duplicating templates in this way is harmful; it increases the burden on those who maintain them, and forces editors to make unnecessary choices.

Please discuss at Template talk:Infobox Townlands#Civil parishes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:07, 28 February 2012 (UTC)

There is no duplication but rather a decrease in actual redundancy. If you checked {{Infobox NI Civil Parish}} you'd see that its up for deletion as i've merged it with {{Infobox Townlands}}. I merged the two templates (which i both created) together simply as {{Infobox NI Civil Parish}} was redundant considering {{Infobox Townlands}} only needed the addition of one parameter to make it do the same job. So more burden? I think not. All articles that had the now proposed for deletion {{Infobox NI Civil Parish}} have been replaced with {{Infobox Townlands}}. Mabuska ^(talk) 15:34, 28 February 2012 (UTC)

[ec] As indicated above, I've answered your duplicated comment at Template talk:Infobox Townlands#Civil parishes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:47, 28 February 2012 (UTC)

Request: add length, width in geography section

I am working on settlements/islands in the Maldives, and I have awkwardly inserted length/width these at the end of the infobox. It would be useful if they were available in the geography section, or if there were any freeform fields (or linear fields) in the geography section that I could adapt for these. ("Elevation" would even be fine, as long as I could rename it using a template wrapper.) Thanks, Calliopejen1 (talk) 02:46, 1 March 2012 (UTC)

{{Infobox settlement}} doesn't have any length/width fields, so not sure what you mean about having "awkwardly inserted length/width these at the end of the infobox". --Redrose64 (talk) 12:40, 1 March 2012 (UTC)

I put them in the custom fields at the bottom, but it is strange for them to be there because you would expect them to be in the geography section with the area, elevation, etc. Calliopejen1 (talk) 16:21, 1 March 2012 (UTC)

I assume that by "custom fields", you mean |blank_name_sec1=|blank_info_sec1= etc. These are supposed to be at the bottom. --Redrose64 (talk) 16:57, 1 March 2012 (UTC)

Yes, I know those go at the bottom... My point is that it would be nice to have custom fields (or set length/width fields) in the Geography section of the template because there is a need for custom fields that are grouped there. Length/width logically belong in the geography section with the area and elevation, not at the very bottom below the website listing. Calliopejen1 (talk) 19:09, 1 March 2012 (UTC)

an example always helps, see Template:Infobox Maldives. Frietjes (talk) 18:13, 1 March 2012 (UTC)

In-use example: Villingili (Malé). Calliopejen1 (talk) 19:13, 1 March 2012 (UTC)

Sortkey

There seems to be a problem with how this template handles US counties that have a capital letter within the name, such as DeKalb, DeWitt, etc. It is causing the settlement to be sorted at the end of its category section (like the "C" section). Please see Category:Unincorporated communities in Illinois, and look at the end of the "C" section to see what I mean. Is there a way to fix this? Thanks, --Funandtrvl (talk) 07:43, 5 March 2012 (UTC)

It's not this template: I removed {{Infobox settlement}} from Carle Springs, Illinois and checked the cat, the page was still just under Curtis, Illinois. The most likely expln would be a {{DEFAULTSORT:}} inside one of the templates, but the only template that has one is {{Location map USA Illinois}}, where it is enclosed by <noinclude>...</noinclude>. Suggest you ask at WP:VPT. --Redrose64 (talk) 16:38, 5 March 2012 (UTC)

Twin towns in infobox

Putting twin towns in the infobox seems like undue weight to me. I propose they be removed. They can of course still be in the article, if referenced, but they should not appear here. Any takers? --John (talk) 06:55, 8 March 2012 (UTC)

We hashed this a little bit above. My proposal was to allow for flagcons either in the article or infobox. You are quite correct -- the most a twintown or sistercity will get in an article is a mere mention. Info about the various cultural exchanges that twinners or sisters undertake is minutae. Adding the flagicons is overweighting their significance. --S. Rich (talk) 01:21, 10 March 2012 (UTC)

I am going to quote what I said in the discussion above "I honestly feel this is one of the most trivial pieces of information about cities in the articles and do not think they need to be mentioned in the infobox since it should summarize the main points of the article." The twin towns usually appear in a list with no reliable sources and no further description. In my opinion it is one of the least helpful information about the cities and does not need to be summarized in the infobox since they are not that important to the cities. While I do not think the information is necessary, I know others think the opposite so I think the best way to present the information is in a list in the article and if there need to be flagicons it should simply be national flagicons used in the list. Aspects (talk) 15:44, 11 March 2012 (UTC)

Agree that twin towns should be removed from settlement infoboxes. I'll repeat what Aspects says just above, twins/sisters is almost totally useless, usually badly or un-sourced, changed at random, includes "cultural agreements", "education exchanges", "busioness cooperation" agreements and whatever other cruft people want to shoehorn in. That's to say nothing of the flagicons for twins, which people seem to find pretty (unless it's one of those Scotland/Great Britain battles). I see no way at all that twin towns rate mention in an infobox, and for cities with 20 or more of these agreements it would be overwhelming anyway. Not a sufficiently pertinent fact about a settlment to warrant an infobox summary. </rant> Franamax (talk) 16:55, 11 March 2012 (UTC)

Flag icon trouble

I know that removal of flag icons is controversial... but that's what I've had to do to Cameron Highlands in order to get the infobox coords to pick up the correct ISO 3166 country code (Malaysia is MY; MZ being Mozambique). What was generating the incorrect code MZ? --Redrose64 (talk) 20:17, 15 March 2012 (UTC)

it appears the problem is with {{CountryAbbr2|{{flag|Malaysia}}}}. fix that and the problem will probably be solved. Better still would be to add 'coordinates_region = MY' to the article, which will bypass that template. Frietjes (talk) 21:25, 15 March 2012 (UTC)

I found the problem, there is an = missing before the MY in {{CountryAbbr2}}. Frietjes (talk) 21:31, 15 March 2012 (UTC)

now fixed here. Frietjes (talk) 22:59, 15 March 2012 (UTC)

Hectares and acres

I have added capacity for areas in acres and/or hectares. I have yet to connect these with density. JIMp _talk·cont 03:15, 2 March 2012 (UTC)

The density connexion which I've got in mind comes in two parts.

1. If either the per-square-kilometre or per-square-mile parameter are set to auto, use the area in acres and/or hectares along with the population to calculate the per-square-kilometre or per-square-mile density. This could also be calculated from the area in dunums.
2. Introduce the capacity to display per-acre and per-hectare density. Auto per-acre and per-hectare density calculations would be made from one to the other or from population and area if either the per-acre or the per-hectare parameter is set to auto.

The first seems definitely like a good idea. The second assumes that we want per-acre or per-hectare density. It might seem a bit odd to talk about inhabitants per square kilometre/mile when the place is only a few hectares/acres in size but is it? You go for a ten-minute drive but the speedometer gives your speed in kilometres per hour. Perhaps we can do without per-acre or per-hectare density. If we want to compare densities of two places, having one in inhabitants per hectare and per acre and the other in inhabitants per square kilometre and per square mile just makes things more difficult. JIMp _talk·cont 05:35, 2 March 2012 (UTC)

wow, that's great. I agree that we really only need to report density in per-square-km or per-square-mile. Having the auto parameter in per-square-mile would by default take the area from square-miles, but if it's not there, then take from acres. similarly for per-square-km and hectares. or, really whatever you think is the best way to do it. I'm just glad you added the acres and hectares, since now we can move forward on the conversion of template:infobox townlands. thank you. Frietjes (talk) 17:20, 2 March 2012 (UTC)

Yeah, no, let's forget about per-hectare & per-acre density but calculating per-square-kilometre & per-square-mile density from population and area in hectares, acres and/or dunums is still a goer. JIMp _talk·cont 09:40, 14 March 2012 (UTC)

It's working. JIMp _talk·cont 17:01, 18 March 2012 (UTC)

awesome. thank you. Frietjes (talk) 17:04, 18 March 2012 (UTC)