Template talk:Infobox settlement/Archive 23

Archive 20

Archive 21

Archive 22

Archive 23

Archive 24

Archive 25

→

Archive 30

Edit request on 3 December 2012

Please increase the number of leaders to six or more.

Askeuhd (talk) 09:11, 3 December 2012 (UTC)

Not done: I don't think we can automatically assume that there is a consensus for this change. If you want to put more than six leaders in the infobox, it may just be better to put a summary of, for example, "Six leaders" in the infobox, and then include the detailed information in the article body. If other editors also support the change, then we can implement it if someone wants to write the code in the template sandbox. Please leave some time for people to comment, and notify people of this discussion at the relevant WikiProjects. (Be careful not to canvass, however.) — Mr. Stradivarius ^{(have a chat)} 10:28, 3 December 2012 (UTC)

Can we add <center>...</center> around image_sky? John of Cromer in China (talk) mytime= Mon 17:45, wikitime= 09:45, 3 December 2012 (UTC)

Not done: That html is no longer standard, so it's probably not a good idea. If you want to work up some standards-compliant code in the template sandbox, though, then we might be able to implement it. Before we do, we should wait for a few days to see if there are any objections to the change. — Mr. Stradivarius ^{(have a chat)} 10:28, 3 December 2012 (UTC)

I knew that – see my point above. I just thought that a quick-and-dirty would be OK. Obviously not. John of Cromer in China (talk) mytime= Mon 22:23, wikitime= 14:23, 3 December 2012 (UTC)

Why do you need six or more leaders? • Sbmeirow • Talk • 19:04, 3 December 2012 (UTC)

Explanation needed for Category:Infobox US maintenance and Category:Infobox Settlement US maintenance

These two temporary maintenance categories have been around for 3+ years and are placed in all articles by this template with subdivision_name = United States (50,000 articles). Category:Infobox Settlement US maintenance appears for transclusions that provide latd, Category:Infobox US maintenance appears for those that don't.

The category descriptions link to a brief discussion with unclear guidance. The category text "{{Infobox Settlement}} used on US cities." and the ubiquitous maintenance categories imply that US cities shouldn't be using {{Infobox settlement}} or shouldn't be using the term "United States" (try alternatives such as "USA") – seemingly not the intended message!

What is the maintenance advice for editors? Thanks. —Mrwojo (talk) 19:18, 2 December 2012 (UTC)

I'll put in an edit request to remove that part of the template if there's no use for it. —Mrwojo (talk) 22:03, 9 December 2012 (UTC)

go ahead an kill these, just make sure we keep Category:Settlement articles requiring maintenance. Frietjes (talk) 16:28, 10 December 2012 (UTC)

That'll be kept. —Mrwojo (talk) 16:50, 10 December 2012 (UTC)

Edit request on 11 December 2012

See above – two old maintenance categories are included on all U.S. settlement articles with no known maintenance required. See Averill, Vermont and Mesa, Washington as examples of the two categories being transcluded.

There's some unrelated testing going on in the template sandbox so I've dropped the template's code with edits into my own sandbox: Edited version.

The following code should be removed from the template:

{{#ifeq:{{NAMESPACE}}||{{#ifeq:{{{subdivision_name}}}|United States|{{#if:{{{latd|}}}|[[Category:Infobox Settlement US maintenance]]|[[Category:Infobox US maintenance ]]}}|}}{{#ifeq:{{{subdivision_name}}}|[[United States]]|{{#if:{{{latd|}}}|[[Category:Infobox Settlement US maintenance]]|[[Category:Infobox US maintenance]]}}|}}}}

Thanks. —Mrwojo (talk) 16:53, 11 December 2012 (UTC)

Done. Let me know if I made a mistake, and I'll revert myself. Nyttend (talk) 14:00, 18 December 2012 (UTC)

coord

 Request withdrawn
I'd like to have the option like:

| coord = {{coord|8|54|54|N|79|35|58|W|display=inline,title|name=)}}

-DePiep (talk) 22:02, 17 December 2012 (UTC)

so you would like to remove the name from the coordinates link or remove the ISO region information? Frietjes (talk) 22:39, 17 December 2012 (UTC)

Which link, which region? I propose a parameter. -DePiep (talk) 22:51, 17 December 2012 (UTC)

It's usually better to code the latitude and longitude into the infobox directly so that they can be used with a locator map. —Stepheng3 (talk) 22:55, 17 December 2012 (UTC)

"better" I understand. But does not mean I take the effort. Why should I manual what the computer is for? (Must say, I could not find yet the example of my initial proposal, in another template. Maybe later ;-) ). -DePiep (talk) 23:06, 17 December 2012 (UTC)

You can achieve what you suggest above with the following parameters: |latd=8 |latm=54 |lats=54 |latNS=N |longd=79 |longm=35 |longs=58 |longEW=W |coordinates_display=inline,title and the type/region will be set automatically. --Redrose64 (talk) 00:12, 18 December 2012 (UTC)

I got that. It's just I remember (or phantasize?) that the param I suggested was actually used in some serious template. I owe you all the proof/example. Untill I do so, let's forget (as in: don't waste any more time). -DePiep (talk) 00:19, 18 December 2012 (UTC)

OK, this is my example:

{{Infobox organization}} has option

| coords = {{coord|31|15|25|N|32|18|30|E}}

(used in this article)

And not by individual numbers. I resurrect my request. -DePiep (talk) 19:33, 23 December 2012 (UTC)

I would still argue that it's preferable to code latitude and longitude directly. Just because other infoboxes have a coord parameter doesn't mean that it's a good idea. If you really need to embed a {{Coord}} in this infobox, you could put it in one of the blank fields. —Stepheng3 (talk) 19:48, 23 December 2012 (UTC)

I know and like the {{coord}} input. Separate input requires me doing up to 6 (or 12) options and so mental steps. And that does not guarantee the template has a "name=" &tc. option. Could you describe why it is "preferable", or "[not] a good idea"? -DePiep (talk) 20:15, 23 December 2012 (UTC)

Actually, specifying lat/long directly requires only two parameters, not six: latd= and longd=. This approach is preferable mainly because it makes the coordinates available for the infobox's {{Location map}}. Additionally, in most cases, the infobox provides the correct type and region code for the coordinates, and changes to the population_total= parameter will be reflected in the Geohack link. —Stepheng3 (talk) 00:19, 24 December 2012 (UTC)

Where does it get the region code from? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:41, 24 December 2012 (UTC)

@Pigsonthewing: the region code may be explicitly set using |coordinates_region=; if that is blank or absent, it's determined by pushing |subdivision_name= and |subdivision_name1= through {{CountryAbbr}}; but note that both of those methods are defeated if |coordinates_type= is non-blank. --Redrose64 (talk) 16:28, 24 December 2012 (UTC)

OK Stepheng3, I see the merits so I rest my case. -DePiep (talk) 13:45, 24 December 2012 (UTC)

{{Coord}}'s |name= should not be used inside an infobox. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:37, 24 December 2012 (UTC)

How would that be in HVDC Itaipu? -DePiep (talk) 13:45, 24 December 2012 (UTC)

If there isn't one set of coordinates which can represent the whole entity; don't put any in the infobox. I've removed them, for now. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:15, 25 December 2012 (UTC)

You removed coords from infobox? That was temporal. -DePiep (talk) 00:55, 26 December 2012 (UTC)

And you've restored them. Why? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:43, 26 December 2012 (UTC)

You deleted correct facts from the page, which is not the way to go. And my question here was: what to do with that situation? A line is not a point. That powerline essentially has a begin and endpoint. When such a situation does not comply with your (as yet unexplained) one-name-one-point-only rule, the rule should give way. -DePiep (talk) 12:22, 26 December 2012 (UTC)

I didn't delete any facts from the article, since what I removed from the infobox is also, correctly, elsewhere in the article. I have already answered your question. I have referred to no "one-name-one-point-only rule"; but the point that "|name= should not be used inside an infobox" is explained in the coordinates template's documentation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:56, 26 December 2012 (UTC)

You wrote: If there isn't one set of coordinates which can represent the whole entity; don't put any in the infobox. That is not an answer to my uestion. And it is a rule applied without argument. Of course, when the infobox is about a line we should be put be able to put two points in it. Again: why not? -DePiep (talk) 13:01, 26 December 2012 (UTC)

Etymology

We should add an |etymology= parameter, for settlements where we have a cited explanation of the derivation or meaning of the name. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:27, 29 December 2012 (UTC)

How about using blank1_info_sec1, blank2_info_sec1, etc.? —Stepheng3 (talk) 00:31, 30 December 2012 (UTC)

That's not suitable, as noted in the preceding section. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:51, 10 January 2013 (UTC)

Pronunciation

I propose that we add a pronunciation parameter, to take a copy of the IPA pronunciation of a place's name; for example "rɛdɪŋ" for Reading). This will make them machine readable, so that others can import and reuse them. A use case for such a facility is in this blog post about sat-nav devices mispronouncing names. As noted above, the generic "spare" parameters are not suitable for this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:07, 10 January 2013 (UTC)

Good idea. Let's define it being IPA (nothing else, no {{respell}} &tc.). Don't we need to add a secondary one right away, say for a local dialect or whatever? Without that some editor could write, in good faith, both pronounciations in the single parameter. Future question: when IPA is in the infobox, should it stay in the lead? -DePiep (talk) 13:14, 10 January 2013 (UTC)

Airport, railway station

I'd like a new parameter, airport, where we could add a suitable airport (or two) for people wanting to travel to the settlement. Maybe we could add railway station also. Of course, in areas where people can't or avoid travelling by train, the railway station field can be omitted. --BIL (talk) 21:37, 28 December 2012 (UTC)

How about using blank1_info_sec1, blank2_info_sec1, etc.? —Stepheng3 (talk) 00:31, 30 December 2012 (UTC)

The problem with using blank parameters for such information is that they are not easily machine readable – the labels may vary, and so people can't write scripts to read and re-use the information contained in them. Specific named parameters, on the other hand, are machine readable, and can be imported into systems like DBpedia and our own Wikidata. Also, because they don't appear in the documentation and its bank copy people aren't aware of the emerging convention to use them. Finally, we can't place them at a logical position in the template. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:50, 10 January 2013 (UTC)

Still, adding the specific info this way is better than omitting it for the secondary reasons you mention. -DePiep (talk) 13:17, 10 January 2013 (UTC)

I decided to add the field airport to the template, because no one has objected its addition, only objecting using blank1_info_sec1 etc for this. However, the template is protected. If an admin includes the field airport, I will update the documentation, and start adding this info to settlement articles. --BIL (talk) 17:34, 13 January 2013 (UTC)

Infobox is too damn big

Really screws up trying to organize a page because the infobox bleeds too far down the page. Can we make it collapsible? Maybe provide a smaller version of it? --ColonelHenry (talk) 18:47, 21 January 2013 (UTC)

Which article are you seeing this on? --Redrose64 (talk) 18:55, 21 January 2013 (UTC)

too many, but right now I'm working on Stillwater Township, New Jersey, and quite frankly none of the related articles I see it on have a lede long enough to keep the infobox from jambing its way into subsequent sections. Makes it hard to reorganize and add to an article if the infobox dominates it. I'm not a fan of infoboxes to begin with.--ColonelHenry (talk) 19:40, 21 January 2013 (UTC)

you could always move one or both of the maps to another section in the article. Frietjes (talk) 20:24, 21 January 2013 (UTC)

There is a graph, then a picture and then a table. These were all on the right with the infobox and were therefore shoved into the wrong sections. A solution is to move some of them to the left. I gave it a try. JIMp _talk·cont 23:30, 21 January 2013 (UTC)

If the issue is right-aligned images or tables being pushed below the infobox, one trick I have found is to use the {{Stack}} template, which will allow an image or table to be placed right of the text and left of the infobox. I updated the article for Stillwater Township, New Jersey to move the history section to the top (where it should be anyway) and used {{Stack}} to keep the gristmill image to the right of the history. That moved the remaining sections down away from the infobox and therefore the climate table and population table are to the right of the appropriate sections. -- Zyxw (talk) 05:14, 29 January 2013 (UTC)

The infobox is a problem, but I doubt anyone would make major changes to this infobox since it's used by many ten's of thousands of articles. I wish MediaWiki had a simple solution for this mess. The typical solution is move things up or down the article, move photos to the left side, or use the Stack template. {{ Stack | <objects> | float=left/right | clear=true/false }} • Sbmeirow • Talk • 05:47, 29 January 2013 (UTC)

Over-rounding in conversion of square miles to km2

Infobox settlement
Area
• City	10,000 sq mi (30,000 km2)
• Land	1,000 sq mi (3,000 km2)
• Water	100 sq mi (300 km2)
• Urban	10 sq mi (30 km2)
• Rural	1 sq mi (3 km2)
• Metro	0.1 sq mi (0.3 km2)
• blank1	0.01 sq mi (0.03 km2)
• blank2	0.001 sq mi (0.003 km2)

While updating the documentation for the supporting templates of Infobox settlement, I noticed the infobox is over-rounding the conversion of square miles to square kilometres, such that an area of 10,000 sq mi displays 0 km² as the conversion (see examples to the right). The template which needs to be corrected is Template:Infobox settlement/areadisp. I have an edit request with more details at Template talk:Infobox settlement/areadisp#Edit request: Fix over-rounding in conversion of square miles to km2. Posting this here for those who don't watch the sub-template talk pages. -- Zyxw (talk) 02:02, 5 February 2013 (UTC)

Incorporated from parameter

I've been thinking that there should be an incorporated-from parameter in the template, which would be filled in with whatever municipality the settlement is incorporated from. Any thoughts?^King Jakob _C2 23:10, 14 February 2013 (UTC)

• Already exists. Use this parameter: |established_title = Incorporated (the word "from" is obviously redundant). See for example Brockville. -- P 1 9 9  ✉ 13:18, 15 February 2013 (UTC)
  • What I meant by incorporated from was like Main Township, Columbia County, Pennsylvania was formed from part of Mifflin Township, Columbia County, Pennsylvania.^King Jakob _C2 13:59, 15 February 2013 (UTC)
    • Maybe it's best to describe that in the history section... -- P 1 9 9  ✉ 14:21, 15 February 2013 (UTC)

Electoral district

Is there a parameter to indicate which seat the place falls under in a legislature? It doesn't quite fit "subdivision_typeX". –HTD 16:26, 13 February 2013 (UTC)

I have seen editors put this in the government section, using the leader_title/leader_name fields or the government_type/governing_body fields. Frietjes (talk) 16:33, 13 February 2013 (UTC)

Looks semantically wrong. Better create and use a generic label/data option. -DePiep (talk) 16:46, 13 February 2013 (UTC)

It's really bad practice to shoehorn data into inappropriate fields. Anything which scrapes our pages, or parses our metadata, will get bad data. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:59, 13 February 2013 (UTC)

I was referring to putting a link to the constituency/district seat per se, not on the person occupying the seat, as that would've been more appropriate on district articles. For an example, see Wagga Wagga (that doesn't use this template). It has two parameters for the national lower house and the state legislature. I'd agree on a new field for this. –HTD 17:36, 13 February 2013 (UTC)

I think putting it under the government section works fine, like municipalities in Ontario and Quebec, Canada, see for instance Gatineau. -- P 1 9 9  ✉ 17:41, 13 February 2013 (UTC)

Unfortunately not. Your example asserts that a person called "Marc Bureau" has the job of Mayor of Gatineau; a person called "Gatineau, Hull—Aylmer and Pontiac" has the job of Federal riding of Gatineau; and a person called "Gatineau, Hull, Papineau and Pontiac" has the job of Prov. riding of Gatineau. There's a difference between "looks nice" and "works fine". Your example does not "work". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:44, 15 February 2013 (UTC)

Yeah there should be a horizontal line between the local leadership and electoral districts. –HTD 14:52, 19 February 2013 (UTC)

This is not about visual presentation, but the the meaning of the parameters. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:03, 19 February 2013 (UTC)

Yes. That's why I said at the top of the discussion that "'subdivision_typeX' isn't a right fit". –HTD 18:39, 19 February 2013 (UTC)

The discussion has gone stale. There are three important issues here:

1. Are electoral districts important enough to be on an infobox
2. If they are, how should they be presented in the infobox
3. How the parameters would be worked upon.

–HTD 18:52, 27 February 2013 (UTC)

more leaders

Currently the infobox supports five leader_nameN and leader_titleN parameters. In certain parts of California, these parameters are used to present the legislators associated with populated places. When the place is an incorporated municipality, editors can run out of parameters, as has happened for instance in Livermore, California. It would be helpful to have additional fields — at least seven, maybe as many as ten. —Stepheng3 (talk) 22:45, 17 March 2013 (UTC) Another example is Ione, California.—Stepheng3 (talk) 18:39, 18 March 2013 (UTC)

I've coded the suggested changes in {{Infobox settlement/sandbox2}} and tested them in Template:Infobox settlement/testcases. If there are no objections, I will raise a protected edit request and backport the changes into {{Infobox settlement/sandbox}}. —Stepheng3 (talk) 18:30, 18 March 2013 (UTC)

Aren't the state-level or country-level legislators not essentially theoretically involved in the governance of a particular place, unless s/he is a legislator of that place's legislature? A state-level legislator that represents a particular place may object to what the mayor is doing but he can't do anything by himself by virtue of his position... although this would look like executive branch bias.

Thank you for bringing that up. I believe that, in the United States, Federal law generally overrides state law and state law overrides municipal law. Thus state legislators and Federal legislators are involved in the government of the entire state, including municipalities. I live in a city, and when I had issues with state taxes, I wrote to my state assemblyman, not my city council, for help. —Stepheng3 (talk) 19:39, 18 March 2013 (UTC)

Your state taxes don't directly go to the city per se, so, like I said earlier, it's not really related to the governance of that particular city. In city governance, mostly the primary issues are things like traffic, garbage collection, zoning and the like. State taxes have no direct effect to how the city is being governed (aside from the fact that state taxes usually return to the city at some form), which means state legislators should go to state-level articles. –HTD 04:50, 19 March 2013 (UTC)

Elevations and postal codes have no effect on how the city is being governed either, but they have a place in the infobox. In the case of California, there are 53 congressional districts, 40 state senate districts, and 80 assembly districts, each with its own legislator, so connecting cities with their legislators is non-trivial.—Stepheng3 (talk) 14:46, 21 March 2013 (UTC)

However, it is relevant for a place to know what electoral district (in any level) it belongs to. This is the subject of #Electoral district, above. –HTD 19:04, 18 March 2013 (UTC)

This seems like a slightly different issue, since the infoboxes I'm working on emphasize the legislator (person) rather than the electoral district. Personally, I'm not thrilled with having legislators' names (which change frequently) replicated across dozens of articles. However, when it comes to deciding where to display information, I tend to respect the wishes of the editors who came before me, who may know the locality better than I do. If they put something in the infobox, I try to leave it there. {{Infobox settlement}} tries meet the needs of many diverse localities. We should allow for the fact that there will be regional variations in how the infobox is used. —Stepheng3 (talk) 19:39, 18 March 2013 (UTC)

Field for Patron Saint

We can add the info to the Footnotes, but it looks bad. Needs a separate field in the formatting. — LlywelynII 15:30, 14 March 2013 (UTC)

Have you tried using the blank fields (such as blank1_name_sec1 and blank1_info_sec1) to present this information? —Stepheng3 (talk) 16:27, 14 March 2013 (UTC)

Isn't this a bad idea? Unless it's Vatican City, patron saints have nothing to do with governance of a place. What's next, first ladies of the mayors? –HTD 19:28, 14 March 2013 (UTC)

I think the big problem is that patron saints aren't always (and I'm guessing usually aren't) officially recognized by the government itself. Things like flags, coats of arms, and even things like tartans or official flowers are approved by the government, whereas saints are chosen by the Vatican. Including the emblems chosen by an unrelated organization implies a relationship that might not exist and might create a slippery slope of allowing too much other third-party information. —Arctic Gnome (talk • contribs) 20:29, 14 March 2013 (UTC)

Telephone prefixes have nothing to do with governance, but they're still good infobox fodder. Likewise municipal flowers, in some parts of the world. (I'm thinking Japan.) I'm sure that, in some places, patron saints are notable enough to include in an infobox (though not where I live, thanks to separation of church and state). —Stepheng3 (talk) 20:33, 14 March 2013 (UTC)

In the Philippines, patron saints are quite a big deal (with feast days becoming unofficial local holidays), but I dunno if the article will be better served if there's a place in the infobox for that, although most articles about places do discuss these things under the religion or culture section. –HTD 19:08, 18 March 2013 (UTC)

There are several countries in which patron saints are a big deal, but this is not the case in the majority of countries. The blank fields provide the opportunity to add these kinds of things to the infobox, without adding more optional fields. What would be against using a blank field in this case when there is consensus for the article to include the patron saint? CRwikiCA (talk) 19:33, 18 March 2013 (UTC)

But there's already an issue on those blank fields, and whether it is a slippery slope to add even more fields. A few years ago, I fought off an attempt to put "first ladies" on a similar infobox which is now deleted and is supposedly merged here. Patron saints now, first ladies tomorrow, what's next? Although I'm for "official" birds, animals and the like... –HTD 04:42, 19 March 2013 (UTC)

I do agree with you that if the saint has no official position, and only a minority of people in the city would even acknowledge it, then it's inclusion could even be seen as WP:NPOV as it basically states that the city is catholic. If there are, however, festivals celebrating the patron and it is officially recognized, then a point could be made to include it. I would say, omit it, unless there are very good reasons to include it, and the article also mentions the saint with more than a single short sentence about it. CRwikiCA (talk) 13:27, 19 March 2013 (UTC)

We should avoid shoehorning data into blank fields, because it is not covered on the template's documentation and not easily mapped or parsed by services such as DBpedia and Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:43, 19 March 2013 (UTC)

Technically, the blank fields are documented, but I think I get what you're trying to say. I agree we shouldn't make things harder for Wikidata and DBpedia without a legitimate reason, but keep in mind that the template primarily serves human users; making life easier for automated tools isn't its main purpose. Different regional WikiProjects have different notions of what should appear in an city's infobox, and blank fields provide a practical solution to supporting their diverse requirements without further inflating the number of parameters. In this way we've made progress supplanting regional infoboxes such as {{Infobox city Japan}} and {{Infobox South African municipality}}, which I'm guessing are even more problematic for DBpedia and Wikidata. —Stepheng3 (talk) 19:10, 21 March 2013 (UTC)

actually templates with no blank fields, like {{Infobox city Japan}}, are easier for DBpedia, since the information is more structured. parsing this template is harder, since the subdivision fields are basically blank parameters. If we really wanted to make things easier for DBpedia we would make more wrapper templates, and then help them out by creating more mappings. there is clearly a trade-off between fewer templates and specificity of templates. if you check the mapping for infobox settlement, you will see that it thinks all the numbered subdivision_name fields indicate generic membership. however, you will see editors frequently using these fields for other things (e.g., for the number of subdistricts in a district article, where they should be using the 'parts' parameter). DBpedia does nothing with the subdivision_type fields, which could theoretically be used to weed out false uses. If you don't care if the information in the blank fields is used by DBpedia, you can certainly safely use it, since it is not currently being parsed. You can check to see what is currently being parsed here (note that even 'seat' is missing). By the way, I didn't know that wikidata was sudden parsing infoboxes. Frietjes (talk) 14:29, 22 March 2013 (UTC)

We could – should – use Lua to check for numerical values in those fields, and generate an error message/ category. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:41, 22 March 2013 (UTC)

The blank fields may be documented, but their use for any given purpose is not. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:41, 22 March 2013 (UTC)

Edit request on 25 March 2013

I suggest adding Demonym(s) and Language(s) to the Infobox list of features. These two items might be inserted immediately before or after or between Nickname(s) and Motto. Many thanks.

Laird of abbeyhill (talk) 19:24, 25 March 2013 (UTC)

for demonym, try |population_demonym=. Frietjes (talk) 19:36, 25 March 2013 (UTC)

for languages, the documentation suggests using the demographics section. Frietjes (talk) 19:39, 25 March 2013 (UTC)

Odd size in Chrome, apparently

Per this discussion, can anyone suggest a fix (for the technically challenged). Thanks in advance. RashersTierney (talk) 18:29, 27 March 2013 (UTC)

Do you have a screenshot? Does it happen on all screen resolutions? Does it occur for all instances of this infobox? Does it happen for other infoboxes too? CRwikiCA talk 19:30, 27 March 2013 (UTC)

Infobox settlement Chile

9 Feb sandbox version

A long time ago we discussed about the problem regarding long countries like Chile and how could be displayed a two-columns-table instead of every-image-down-under-the-previous-image in order to make the infobox more compact and shorter. We reach an agreement to merge the new {{infobox settlement Chile}}-features in the general infobox.

As far as I know, until now no one proposal has been made to merge both boxs.

I worked out a solution for the merge. Simply we add four new parameters (for four images) and build up a two-column-table with this images. The code is in {{Infobox settlement/sandbox}} version of 14:52, 9 February 2013 (current version today), and the results are shown in Template:Infobox settlement/testcases (please use the (current) version 15:09, 9 February 2013‎). The example is the infobox for the City of Linares in Chile.

I had elaborated also a solution with only one new parameter but I decided to propose the 4-new-params solution.

I think the solution with 4 new parameters is better than a solution with only one new parameter, because the new code for 4 new params doesn't interfere in the logic of the "old" template or at least interfere less than the code with only one new parameter.

I ask you to inspect the new code in sandbox and, if you find it good, to support the merge. --Best regards, Keysanger (what?) 13:54, 15 February 2013 (UTC)

• Well done! I support your solution for Chilean places. -- P 1 9 9  ✉ 14:20, 15 February 2013 (UTC)

Are there other editors interested in this issue?. If not, I would like to proceed to improve {{infobox settlement Chile}} and leave {{infobox settlement}} to its own destiny. --Best regards, Keysanger (what?) 12:09, 20 February 2013 (UTC)

You have already noted earlier discussion , which is at Template talk:Infobox settlement/Archive 22#A large image and Wikipedia:Templates for discussion/Log/2012 May 15#Template:Infobox settlement Chile. The outcome of the later is unequivocally recorded as "merge with {{Infobox settlement}}, adding the ability to place the location map next to the other flags/shields/maps". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:37, 20 February 2013 (UTC)

Great, you got it!. And now, what do you think about my proposal to merge with {{Infobox settlement}}, adding the ability to place the location map next to the other flags/shields/maps? --Best regards, Keysanger (what?) 10:42, 23 February 2013 (UTC)

can you provide a link to the new code? I don't see any of the test cases showing the map on the side of the other images. Frietjes (talk) 22:55, 28 February 2013 (UTC)

The code is in {{Infobox settlement/sandbox}} version of 14:52, 9 February 2013 (current version today, again), and the results are shown in Template:Infobox settlement/testcases (please use the (current) version 15:09, 9 February 2013‎). The example is the infobox for the City of Linares in Chile, that is case 0. There are some other people testing the population density. (I reverted their changes today, sorry).

The diff is [1], but there are two changes regarding:

• #ifeq:{{{coordinates_display|}}}|inline|μ
• #ifeq:{{NAMESPACE}}||{{#ifeq:{{{subdivision_name}}}|United States|{{#if:{{{latd|}}}|[[Category:Infobox Settlement US maintenance]]|[[Category:Infobox US maintenance ]]}}|}}{{#ifeq:{{{subdivision_name}}}|[[United States]]|{{#if:{{{latd|}}}|[[Category:Infobox Settlement US maintenance]]|[[Category:Infobox US maintenan ...

This changes (in the current version of infobox settlement) should not be reverted. --Best regards, Keysanger (what?) 16:20, 1 March 2013 (UTC)

okay, I see, the changes are just to the map section, and not the native_name or tracking stuff. this seems like it's very close, but can we do this with just one new parameter, namely the |pushpin_map_cl= would trigger the code fork to go the the pushpin-on-the-side? this way we could re-use the image_flag (rather than needing image_flag_cl) and image_shield (rather than needing image_shield_cl). although, I think we probably want to keep image_map_cl, since we are significantly resizing the default map. also, is there a reason for having the map between the shield and the flag? and, why _cl and not _right or _side or _narrow? otherwise, no objections here. Frietjes (talk) 22:35, 1 March 2013 (UTC)

1. I worked out also a solution with only one new parameter, namely the |pushpin_map_cl=. The code is in the sandbox version of "21:21, 11 December 2012" and the testcase version of "21:29, 11 December 2012‎". But I would prefer the 4-new-params solution because it doesn't interfere with the old-code. the 4-p solution is a new block of code, full separated from the old params. It is easier for the maintenance.
2. *_cl or *_right or *_narrow or *2: no problem, use it as you like it.
3. on the left side we can put the images in every sequence shield/map/flag or map/flag/shield or any other.
4. I prefer the 4-p solution but I would accept also the 1-p approach. --Best regards, Keysanger (what?) 11:25, 2 March 2013 (UTC)

• I've marked the edit request as answered while discussion here is still ongoing. Please reactivate it when there is a consensus for what to do. — Mr. Stradivarius ^{♪ talk ♪} 09:38, 2 March 2013 (UTC)

• Keysanger asked me for input, but I don't understand things like parser functions at all, so I can't comment intelligently on the merits of the current sandbox revision. Nyttend (talk) 22:31, 13 March 2013 (UTC)

Support: {{infobox settlement Chile}} should be merged here and the best way of doing this is to make this template such that it accommodates countries like this. It looks to me like Keysnager has achieved this. It's true the four-parameter version would be easier to maintain but perhaps the one-parameter version would be easier when editing the articles. Easier still for article editors might be a zero-parameter solution, i.e. have the two-column set-up produced automatically when the country is Chile (or Norway, Sweden, etc.), of course, that'd be even more complicated to code on this end. JIMp _talk·cont 07:50, 18 March 2013 (UTC)

Thanks Jimp. A zero-parameter solution would change existing articles layout without to consult. I presume, we would get not only congratulations from some editors. I think that the strong side of the new params is, it doesn't change articles without the new params. --Best regards, Keysanger (what?) 10:40, 6 April 2013 (UTC)

Problem with auto density

There seems to be something going wrong with automatic density calculation: it produces "Formatting error: invalid input when rounding". You can see this on, for example, Acapulco. I suspect it may have something to do with the most recent edit on {{Rnd}}, but I don't have the template coding skills to figure it out myself. - htonl (talk) 22:47, 22 February 2013 (UTC)

Iloilo too John of Cromer in China Philippines (talk) mytime= Sat 07:07, wikitime= 23:07, 22 February 2013 (UTC)

The same problem shows up in Calistoga, California and St. Helena, California and many others. It seems to be widespread and recent. —Stepheng3 (talk) 23:12, 22 February 2013 (UTC)

The problem will lie in one or more of the following: Module:Math; Template:Max; Template:Max/2; Template:Precision; Template:Precision/a; Template:Rnd. Nothing else remotely relevant has been altered today. --Redrose64 (talk) 23:21, 22 February 2013 (UTC)

I reverted Template:Rnd on the basis of someone's guess that this was the problem, and that seems to have fixed it, but I'm not particularly sure why. Nothing at Template:Rnd/testcases suggests a problem. Dragons flight (talk) 23:28, 22 February 2013 (UTC)

• See also Wikipedia:Village pump (technical)#densdisp template is now broken. --Redrose64 (talk) 23:14, 22 February 2013 (UTC)

I've used sandboxes to recreate the problem: User:Stepheng3/sandbox, Template:Infobox settlement/sandbox, Template:Infobox settlement/densdisp/sandbox, and Template:Rnd/sandbox. —Stepheng3 (talk) 23:46, 22 February 2013 (UTC)

I've isolated the problem. It's actually Template:Infobox settlement/densdisp that is essentially broken. It is throwing error messages, due to malformed calculations for precision. Previously, {{rnd}} silently ignored such error messages in the precision field, and rounded values to around 2 significant digits by default (though the actual amount of rounding if precision is left blank is not officially specified and somewhat unpredictable). As presently implemented, the Lua version requires an actual number in the precision field, and hence it was exposing the calculation errors that were being silently hidden before. Dragons flight (talk) 23:53, 22 February 2013 (UTC)

Thanks for the quick revert and debug. I'm in favor of fixing Template:Infobox settlement/densdisp! —Stepheng3 (talk) 23:59, 22 February 2013 (UTC)

I added parens to Template:Infobox settlement/densdisp/sandbox with this edit [2] to make the precision expressions syntactically valid (i.e. no error message), but looking at Stephen's sandbox, it seems that the calculation is probably erroneous (i.e. asking for too much precision) and/or the missing parens need to be somewhere else in the expression. I'm not sure what calculation you guys actually want to have there, so I let you all figure that out. Dragons flight (talk) 00:03, 23 February 2013 (UTC)

I moved the parens in Template:Infobox settlement/densdisp/sandbox so that the rounding (of the number of decimal places) occurs last. This seems to me more likely to be correct. For the Calistoga test case (in my sandbox), this gives reasonable results. However, I'm not sure whether it's what the creators of densdisp intended. I've left pleas for help with both User:Jimp and User:Plasticspork in the hope that they can confirm or correct my fix. —Stepheng3 (talk) 01:46, 23 February 2013 (UTC)

After further testing in my sandbox, I'm almost certain that densdisp/sandbox still isn't correct. I leave this problem for others more expert at template coding. —Stepheng3 (talk) 02:32, 23 February 2013 (UTC)

I'm going to go ahead and suggest that what you probably want is something for precision like:

{{#expr: {{ min| {{#expr: {{precision|{{{pop}}}}} + {{order of magnitude|{{{pop}}}}} }} | {{#expr: {{precision|{{{area}}}}} + {{order of magnitude|{{{area}}}}} }} }} - {{order of magnitude|{{#expr: {{{pop}}}/{{{area}}} }} }} }}

With appropriate formatnum and scale factors added in for converting area into the right units, etc.

For example, area = 654.2, pop = 123456, gives density = 188.7

Or, area = 650, pop = 123000, density = 190.

Dragons flight (talk) 02:49, 23 February 2013 (UTC)

Replacing {{order of magnitude}} everywhere above with log base 10 probably also works, though then you need to round the result to the nearest integer at the end. Dragons flight (talk) 03:01, 23 February 2013 (UTC)

I put something in Template:Infobox settlement/densdisp/sandbox that may work for you guys. It added another template to the mix but you can subst that out if you want. I'm not 100% sure that I got all the conversion factors and in the right place, so someone should double check. Dragons flight (talk) 05:15, 23 February 2013 (UTC)

For the record, I added error trapping and converted back to the Lua version of {{rnd}}. This will allow existing pages to render in much the same way they did before. Rather than displaying a visible error (which may be disruptive to readers), now bad pages will be added to the hidden category Category:Pages with bad rounding precision and display a number rounded to 1 - {{order of magnitude}}, which approximates the prior behavior. It is still a good idea to fix Template:Infobox settlement/densdisp and other templates that are sending bad precision values, but now we should be able to do that without being too distracting. Dragons flight (talk) 18:13, 23 February 2013 (UTC)

Fixed unclosed "))" to get /densdisp/sandbox2 to work

By using a second "/sandbox2" (as Template:Infobox settlement/densdisp/sandbox2), I have corrected the typos in the 5 population-density formulas to get the complex calculations to work, by inserting the 2 missing right parentheses brackets ") )" into each {rnd} where the decimal-digit count (expected "2") was causing an expression error instead. Compare results:

• /densdisp (error):     43/km² (110/sq mi)
• /densdisp/sandbox2: 43/km² (110/sq mi)
• /densdisp/sandbox:       43/km² (110/sq mi)
   
• /densdisp (error):     35/km² (90/sq mi)
• /densdisp/sandbox2: 35/km² (90/sq mi)
• /densdisp/sandbox:       35/km² (90/sq mi)

This was a classic case of having the correct matching curly braces "{_}" but also mismatched parentheses brackets "(_(_(___)" so then the overall logic flow was coherent, but the value of each decimal-count parameter was garbage. To find the mismatched symbols, I had to echo the text value of each expression and count the nested parentheses. Because of the extreme complexity, where this problem persisted for nearly a year, then the logic should be rewritten, perhaps next month in /sandbox, to not require such complex formulas with "(_(_()_(__)_()_)_)" nesting. Meanwhile, we need to install the fixed "/sandbox2" version, for correct rounding, to unclutter the maintenance category which has other articles buried in the ocean of invalid {rnd} pages. A few hours after installation, then the prior 44,000 invalid pages will be reduced, by thousands, to leave almost none in "Category:Pages with bad rounding precision". IMPACT: Used in 95,286 transclusion pages. In large categories, expect the reformatting to spread across 3-5 days, to clear the final pages. -Wikid77 (talk) 01:17, 27 February 2013 (UTC)

In your examples above, why does sandbox2 give very different rounding for the per km^2 and per mile^2? I'm not sure what the answer should be, but I would at least think that the two halves would end up with similar precision. Dragons flight (talk) 03:52, 27 February 2013 (UTC)

• Rounding is set by the template: The example with 5-digit precision actually yields "110.00" but which displays as "110" to give the illusion of 2 significant digits. Other numbers will show more digits, such as 10 people in 0.28016 sqmi, as {../densdisp/sandbox2|...} = 14/km² (36/sq mi). Consider a spare population: {../densdisp/sandbox2|...} = 3.9/km² (10/sq mi). Perhaps I should have listed more examples but I just wanted to show the rounding errors were fixed in /sandbox2. -Wikid77 (talk) 18:44, 27 February 2013 (UTC)

You missed my point. Yes, the template sets the precision, but a correct version of that template really ought to give appropriate precision for both numbers. Sticking in some extra parens makes the expression syntactically valid, thus eliminating the error message, but I'm not sure that the output is actually correct. Consider:

{{Infobox settlement/densdisp|/km2=auto|pop=1234567|sqmi=777.7777}}

• /densdisp (error):     610/km² (1,600/sq mi)
• /densdisp/sandbox2: 610/km² (1,600/sq mi)
• /densdisp/sandbox:       610/km² (1,600/sq mi)

{{Infobox settlement/densdisp|/km2=auto|pop=1234560|sqmi=777.777}}

• /densdisp (error):     610/km² (1,600/sq mi)
• /densdisp/sandbox2: 610/km² (1,600/sq mi)
• /densdisp/sandbox:       610/km² (1,600/sq mi)

{{Infobox settlement/densdisp|/km2=auto|pop=1234500|sqmi=777.77}}

• /densdisp (error):     610/km² (1,600/sq mi)
• /densdisp/sandbox2: 610/km² (1,600/sq mi)
• /densdisp/sandbox:       610/km² (1,600/sq mi)

{{Infobox settlement/densdisp|/km2=auto|pop=1234000|sqmi=777.7}}

• /densdisp (error):     610/km² (1,600/sq mi)
• /densdisp/sandbox2: 610/km² (1,600/sq mi)
• /densdisp/sandbox:       610/km² (1,600/sq mi)

{{Infobox settlement/densdisp|/km2=auto|pop=1230000|sqmi=777.}}

• /densdisp (error):     610/km² (1,600/sq mi)
• /densdisp/sandbox2: 610/km² (1,600/sq mi)
• /densdisp/sandbox:       610/km² (1,600/sq mi)

{{Infobox settlement/densdisp|/km2=auto|pop=1200000|sqmi=770}}

• /densdisp (error):     600/km² (1,600/sq mi)
• /densdisp/sandbox2: 600/km² (1,600/sq mi)
• /densdisp/sandbox:       600/km² (1,600/sq mi)

{{Infobox settlement/densdisp|/km2=auto|pop=1000000|sqmi=700}}

• /densdisp (error):     550/km² (1,400/sq mi)
• /densdisp/sandbox2: 550/km² (1,400/sq mi)
• /densdisp/sandbox:       550/km² (1,400/sq mi)

Your sandbox2 seems to leave the /km^2 and /sq mi numbers with significantly different precision in most cases. In addition, in the low precision cases at the end your version seems to be giving rather more precision than is warranted. I know we can "fix" the math by adding in a few parentheses, but frankly I am inclined to think that the computation needs a more serious overall so that the results it generates are actually sensible and not just syntactically complete. It would be rather nice if someone actually familiar with this infobox would chime in with what they actually want to see as output. Dragons flight (talk) 20:50, 27 February 2013 (UTC)

• I've marked the edit request as answered, as there doesn't seem to be a consensus to implement these changes yet. Please reactivate it when you've reached an agreement about what to do. Best — Mr. Stradivarius ^{♪ talk ♪} 10:20, 2 March 2013 (UTC)

It would be nice if someone who understands what densdisp is trying to do would develop a fix. However, since that doesn't seem to be happening, I propose we round population densities to two significant digits. Or maybe three. Given how much a settlement's population typically varies from year to year, there's scant justification for more than three significant digits, even if a source has reckoned its area to five or six significant digits. With this simplification of the requirements, I believe I could implement a robust version of densdisp. —Stepheng3 (talk) 14:56, 21 March 2013 (UTC)

Shrug, if no one who understands it is going to participate, then by all means, just do whatever. It would be nice to stop cluttering rounding error tracking category. Dragons flight (talk) 17:54, 21 March 2013 (UTC)

I'll construe the absence of further discussion as consensus for two significant figures.—Stepheng3 (talk) 15:28, 11 April 2013 (UTC)

My two penn'orth – I don't believe in fractions of a person, so would expect whole numbers only. I.e. ceiling John of Cromer in Philippines (talk) mytime= Fri 23:24, wikitime= 15:24, 12 April 2013 (UTC)

John, do you understand that we're talking about average population density? I think most people would expect the average density to deal in fractions of a person per unit area. —Stepheng3 (talk) 19:33, 13 April 2013 (UTC)

Indic scripts in settlement infobox

Abhishek191288 tells me that the prohibition at WP:INDICSCRIPT should apply not only to the lead sentence but also to infoboxes. I disagree. There is a place in the settlement infobox for native names, and it seems appropriate to place the native script there. See edits and reversions by Abhishek191288 at Munirabad, Chikkaballapur, Chikmagalur, Bellary and Belgaum. Comments pro or con? --Bejnar (talk) 07:31, 11 April 2013 (UTC)

It's perfectly acceptable to put both non-Western scripts an anglicised transliterations of native names there – that's what its for. Multiple values should be separated using {{Plainlist}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:07, 11 April 2013 (UTC)

I would even say that it is desirable to have the native script in the infobox. CRwikiCA talk 13:31, 11 April 2013 (UTC)

There was also no blanket ban on the use of Indic scripts in that discussion, the use for geographic locations was specifically approved in that discussion: See here. So consensus was that WP:INDICSCRIPT does not even apply in the cases you name. CRwikiCA talk 13:37, 11 April 2013 (UTC)

That was my conclusion as well, but Abhishek191288 was not the only one to construe WP:INDICSCRIPT over-broadly. Dendrite1 in this edit at the Belgaum article went so far as to remove the native_name parameter in the infobox template and add a comment to discourage its addition. --Bejnar (talk) 19:35, 11 April 2013 (UTC)

• Would someone be so kind as to restore the native name in the Belgaum article infobox? Thanks. --Bejnar (talk) 23:02, 14 April 2013 (UTC)

Bug In Population Rankings

If you look in the Tampa Bay Area article there is a typo in the Population Section. The Urban section puts a comma in the year. For example "2,783,243 (19th as of 2,008)". This comma should not exist. Chotchki (talk) 20:06, 19 April 2013 (UTC)

The rank is entered in the population field itself, which automatically typesets numbers as if it were population numbers, there also is the "population_rank" field, maybe it would be a better option to use that. CRwikiCA talk 20:29, 19 April 2013 (UTC)

New code for Chile

Per this thread, I have added functionality to allow the pushpin map to appear to the right of the flag, shield, emblem, logo, and one map. To enable this feature, you just need to use |pushpin_map_narrow=yes or any non-blank value. The changes should have no visible appearance on existing transclusions. This will now enable {{Infobox settlement Chile}} to be merged with this template per the outcome of the associated TfD. Please let me know if anything goes haywire. Thanks! Plastikspork _―Œ^(talk) 22:32, 11 May 2013 (UTC)

What's up with this?

The 2010 census population citation is outside the parentheses, but any estimation population citations (2011 or 2012) are inside of the parentheses. Example here. TCN7JM 06:48, 28 May 2013 (UTC)

What exactly are you proposing? Or is it more of a comment? CRwikiCA talk 13:31, 28 May 2013 (UTC)

Sorry, I thought it was obvious. My bad. (not being sarcastic, for the record) The citation should go outside the parentheses on the estimations. It looks better and makes the two parameters identical instead of what they are now. TCN7JM 18:56, 30 May 2013 (UTC)

As things stand, the value passed in |pop_est_as_of= may or may not include a reference, as in |pop_est_as_of=2010<ref>the source for that</ref> or |pop_est_as_of=2010 This value has parentheses wrapped around it by the template before being displayed; and because of that, the closing parenthesis is necessarily after the </ref> should the latter be present. To move the closing parenthesis between the year and the <ref> would require either of two things to happen:

1. We remove the hard-coded parentheses from the template and expect that editors will supply them instead, something like |pop_est_as_of=(2010)<ref>the source for that</ref>
2. We provide a new parameter, say |pop_est_note= and display that immediately after the closing parenthesis. Editors will then need to split existing instances of |pop_est_as_of=2010<ref>the source for that</ref> into |pop_est_as_of=2010 |pop_est_note=<ref>the source for that</ref>

Pending discussion, I don't think this {{edit protected}} should be open, so I've deactivated it. --Redrose64 (talk) 19:21, 30 May 2013 (UTC)

I see the issue. With regard to the proposed solutions, I do not think that expecting editors to include the parenthesis would work, so option 1 is out in my opinion. Alternative 2 would be an option and it would not cause any problems with existing templates.
The question is whether you would want to put the estimate reference in that position, or whether it should be in the same position as the reference(s) for the normal population, possibly directly following the word Population. CRwikiCA talk 19:43, 30 May 2013 (UTC)

I like Option 2. Option 1 seems a bit too cryptic. And what I mean by that is that editors are definitely not going to know to insert the parentheses themselves. The new parameter seems like it would be the best option. TCN7JM 19:56, 30 May 2013 (UTC)

The best solution is to put the reference, with the number, in the body of the article, and have the number alone in the infobox. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:16, 30 May 2013 (UTC)

unless you think that references for the values are part of the meta-data. Frietjes (talk) 21:19, 30 May 2013 (UTC)