Template talk:Infobox settlement/Archive 6

Changes made to main template

As discussed above, I have created some "subtemplates" and used them to simplify the code of the main template, and also to allow the use of auto as a value for all population density fields. I have also implemented the category idea - the value of the category parameter (if any) is now displayed under the name at the top of the Infobox, in bold italics. The changes should have no effect on the Infoboxes in existing articles. I have checked this with the testcases, but if Infoboxes elsewhere are being messed up, please revert my change.--Kotniski 20:37, 2 November 2007 (UTC)

Hmm, I"m not sure what happened to the test cases when I moved my code from the sandbox to the main template, so I've reverted the change for now. Maybe it was just a caching/purging problem. Everything looks fine now (with the changes made in the sandbox only), but when I copied from the sandbox to the main template, some of the test cases got messed up (Hull in particular).--Kotniski 21:06, 2 November 2007 (UTC)

(Comment on MJCdetroit's changes to sandbox.) This way of doing it certainly seems nicer and more logical - my only worry is that the settlement_type parameter may be being used inappropriately in some existing articles. I mean, up to now it has functioned in practice as the label for the total population and area rows, and may have been set appropriately to that function, and not as something suitable for display at the top. For example, I think at London I noticed that settlement_type was set to Greater London, which isn't a type in fact, its just a label to clarify what the total population and area refer to. There may be more cases like that (though perhaps not many). Have you any way of checking and correcting?--Kotniski 08:32, 3 November 2007 (UTC)

I think that London is a one-of-a-kind special case. The settlement_type used to be blank because the infobox used to include The City of London which is one square mile and has a population of 9,200. The article is about "Greater London" which is referred to as just London and is much larger in area and population. The editors of that article decided to remove the reference to the City of London from the infobox in this edit: on October 21 and they discussed it here.—MJCdetroit 16:03, 3 November 2007 (UTC)

I've made a few more minor changes in the sandbox - perhaps you can take a look. I think we may as well go live with the changes and see what reaction they get. If people start objecting strongly to the new layout we can roll that part back, but it would be useful (at least for me and my Poland articles) to have the new features like automatic density available.--Kotniski 13:48, 6 November 2007 (UTC)

While the colored header is nice (I like it), it is not going to work. I've tried something similar two or three times and it has been reverted every time. Try it, but it will get reverted.

The reason that the testcase of Kingston upon Hull failed was simple— the page ran out of pre-expand template size.

Here's what the page source looked like:

Pre-expand include size: 2047983 bytes

Post-expand include size: 689653 bytes

Template argument size: 223604 bytes

Maximum: 2048000 bytes

It seems like the sub-templates actually slightly increases the pre-expand size of the template [in the Hull example] from 588,732 to 646,823. —MJCdetroit 21:31, 6 November 2007 (UTC)

I see. Presumably then this is only an issue because there are so many infoboxes on the testcases page? Though looking at your figures I would expect even four old-style infoboxes to overload the parser (4 x 588,732 > 2048000), so I probably still haven't fully understood this. I would expect (intuitively) that it's not so much the fact that subtemplates are used which increases the size, but the fact that extra functionality has been introduced. In any case I wouldn't expect this to be an issue on article pages, which would typically have only one infobox.

If people get upset by such things as colored headers, I fear some will start complaining when they notice the settlement_type being displayed at the top like we've done (although I certainly think it's an improvement). Maybe it will be necessary to make this optional to begin with. And there may also be cases (like London, or other metropolises) where something other than Total needs to appear on the total population/area line. I'll see if I can come up with something to enable this.--Kotniski 09:13, 7 November 2007 (UTC)

I've made a few more edits in the sandbox and now transferred it all to the live template. Effect on existing articles should be minimal (I've made a slight correction to London). I think the following list summarizes all the changes:

• New field called name. Can be used instead of (or as well as) official_name. If name is used, then it is displayed at the top instead of official_name, and the settlement_type is displayed below the names in a separate colored row, and official_name (if set) is displayed next (in smaller font). If name is not used then the header is displayed as it was before.
• New fields, in a separate section, called seat, seat_type, parts, parts_type. These are intended for displaying the seat of government and subdivisions ("parts") of the settlement/municipality. It seems logical to distinguish these "parts" from the subdivisions of the world in which the settlement lies (for which the fields subdivision_name etc. are used).
• New way of labeling the total population/area rows. If the (new) field total_type is set, then that will be used as the label. Otherwise, if corresponding urban/metro rows are present, then the label will be the value of settlement_type. In other cases the label is Total.
• Elevation in a new section (i.e. with a ruled line above). Elevation "footnotes" not displayed bold. Also new fields: elevation_max/min_m/ft, for displaying highest and lowest elevation instead of just a single value.
• Population density fields may contain the value auto, provided the corresponding population and area fields have numerical values. This will calculate the density automatically.
• Ruled line above the section for blank fields.

I have also updated the template documentation based on the above changes. --Kotniski 11:59, 7 November 2007 (UTC)

Though the way of handling names is just my suggestion; it could be modified. I've just realized that more changes will have to be made to the template (e.g. in the code for the image captions) if official_name is no longer to be a required field.--Kotniski 16:04, 7 November 2007 (UTC)

Parts section

Can you provide an example (even if you make it up) of the use of "seat" and "parts"? I'm thinking that you may just be able to use {{Collapsible list}} as we have in the past. —MJCdetroit 17:33, 7 November 2007 (UTC)

Sure, an example can be seen at Gmina Stronie Śląskie. I guess the list of parts could be collapsed, but there doesn't seem any need to unless it starts to get huge (in that case the collapsing could be done on the article page rather than in the template code).--Kotniski 17:47, 7 November 2007 (UTC)

I've edited Gmina Stronie Śląskie to not use the "parts" and instead use the subdivisions. I've also used the collapsible list template for Gmina Kamienna Góra to put all the villages into an actual list that collapses and not the paragraph style that is used on Gmina Stronie. I don't think that the "parts" and "seat" fields are necessary when the subdivision fields are more than adequate and with the use of the collapsible list make it neater. Let's not add extra fields that we don't really need. It will only bloat the template. —MJCdetroit 18:10, 7 November 2007 (UTC)

Sorry, I can't agree with you here. Surely there's a huge logical distinction between a world/country subdivision in which our settlement lies, and a subdivision of that settlement? It could be very confusing to group these pieces of information together - how is the reader supposed to know which is which? And the seat is different again (although to avoid too many ruled lines I would group it together with the parts). Regardless of whether the collapsible list/paragraph format is used (I think that depends on the individual case), it seems to be worth the few extra bytes of template code to make this distinction clear.--Kotniski 18:30, 7 November 2007 (UTC)

If others don't object then I won't either. However, we should recommend that it always be used with the collapsible list when more than 5 entries are present. —MJCdetroit 20:05, 7 November 2007 (UTC)

OK, though I wouldn't be so categorical - I think whether the list is collapsed depends also on how crowded the rest of the infobox is. Hiding information would seem to be a necessary evil rather than a positive feature (particularly since I'm one of those users who often fail to notice the tiny [show] button). Anyway, editors will doubtless decide for themselves. Would you be in favor of including something in the template code to facilitate collapsing (e.g. a parameter called something like parts_collapse which when filled would automatically place the value of parts inside a Collapsible List)?--Kotniski 15:12, 8 November 2007 (UTC)

It can't hurt to at least see what it would look like in the sandbox. —MJCdetroit 15:22, 8 November 2007 (UTC)

Change made in sandbox; tested at Gmina Stronie Śląskie.--Kotniski 16:08, 8 November 2007 (UTC)

(outdented)Having the <br>'s in there may present a problem with WP:WAI, more specifically Wikipedia:WikiProject Usability/Infobox accessibility. You may want to try and have a 1= 2= 3=... type of situation. —MJCdetroit 16:32, 8 November 2007 (UTC)

As far as I can see the situation described at W:WU/IA is a different case; that problem wouldn't arise here. But having separate fields called part1, part2 etc. is another possible way of doing things; it's also the method used in Geobox, so that would make converting/merging easier.--Kotniski 17:56, 8 November 2007 (UTC)

I've now introduced separate fields called p1, p2, ..., p50, to contain the individual parts. This increases the code length somewhat, but it enables automatic creation of the collapsible list and improves compatibility with Geobox. Instead of parts_collapse I've gone for a parameter called parts_style. This can take the values para (for paragraph style), coll (for a ready-collapsed list) or list (for a list which starts out not collapsed). The default is coll if the list contains 10 items or more (specifically if p10 is filled - this number can easily be changed to 5 or something else if you prefer), otherwise list. The parts parameter has been retained (if used in combination with p1... it serves as the header for the list). For examples you can check out (and play with) Gmina Kamienna Góra and Gmina Stronie Śląskie.--Kotniski 10:29, 9 November 2007 (UTC)

There have been complaints about the physical length of infoboxes in the past. Therefore, I think setting it to 5 will help avoid those complaints in the future. Otherwise, Great job! —MJCdetroit 15:44, 9 November 2007 (UTC)

OK, I've set the maximum for no default collapse to 5. --Kotniski 19:18, 9 November 2007 (UTC)

Kudos and Request for Bot for New York

This is the best, most powerful, most useful and most flexible template I've ever seen on Wikipedia. Many, many, many thanks!

Now for a request for a bot to run through New York state entries using the template. New York has notoriously lacked locator maps. One line of code from this template would solve that!

|pushpin_map = New York

Again, many, many thanks! (I sure wish the Template:Infobox U.S. County was as flexible and useful).Americasroof 18:08, 6 November 2007 (UTC)

I'm not sure how that one line would solve the problem without knowing the mapping of lat/long coordinates to map pixel coordinates. If you know, please let me know, so I can use it in Colorado!

Otherwise, Arkyan has been using ArkyBot to generate very nice maps of cities and towns in the US. I'm sure he'll get there eventually; but you could ask him why he's skipped New York so far.

-- Ken g6 20:56, 13 November 2007 (UTC)

Oh, wow, I found it!

"The coordinate fields (eg. latd and longd) position a pushpin coordinate marker and label on the map automatically."

I'll have to go use that. CapitalBot could add that in no time! For the incorporated and Census-designated places it covers, though, Arkyan should probably be consulted to make sure it doesn't interfere with his work. -- Ken g6 21:12, 13 November 2007 (UTC)

Dot Map

The dot on the dot maps keep moving around .--Cherry1000 22:40, 6 November 2007 (UTC)

Medicine Hat, Alberta uses a dot map and it looks perfect to me in Firefox and IE (for WinXP pro). —MJCdetroit 13:35, 7 November 2007 (UTC)

Named for

Any objections to going ahead with these optional fields?

• Founder
• Named for

The "named for" field, which is supported in the U.S. County infobox, would be particularly useful IMHO, and is one I've been using quite a lot lately in Indiana county infoboxes. I'd heard a yea or two when I'd floated it before, and no objections, but I wanted to make sure this is cool doing anything. If someone with more experience editing the template wanted to make the addition, that'd be even better. :-) Thanks! Huwmanbeing ★ 19:27, 9 November 2007 (UTC)

Seems a good idea to me.--Kotniski 09:38, 10 November 2007 (UTC)

I agree -- good idea! Omnedon 14:20, 10 November 2007 (UTC)

No objection here. —MJCdetroit 03:18, 11 November 2007 (UTC)

Named for would be useful (should probably go in the history/incorporation year sector). Founder seems too much of a detail to go in the infobox (better just in a history section in the text), or in a blank field at the most. --Qyd 14:57, 13 November 2007 (UTC)

I see that both of these fields have now been added, in line with what seems to be the majority opinion.--Kotniski 10:48, 14 November 2007 (UTC)

Two small changes

I've made two more small changes to the template:

• I've restored the default label for total population and area, in cases where settlement_type is not defined but urban or metro figures are also present, from "Total" to "City" (since that was until recently documented as the default for settlement_type). "Total" remains in cases where no urban or metro figures are present (and setting total_type overrides all of these).
• I've added a parameter coor_type which can be set to define more precisely what coordinates are given. For example, set coor_type=Charing Cross to display Coordinates (Charing Cross):... in place of the usual Coordinates:....

If no-one objects to these changes, I'll make the necessary changes to the documentation shortly.--Kotniski 10:48, 14 November 2007 (UTC)

Coordinates Issue

As mentioned earlier I really love this template. I am starting to put it on some more esoteric locations that are not CDP. I ran into a quirk on this version. The location map dot shows correctly in Firefox but is wildly off in IE6. I am kinda lazy in adding the locations based on the googlemap coordinates and didn't want to do the conversion for latd and longd so just added the google decimal and it worked fine in Firefox. As a side note it would be nice if it would make the conversion to the nice dd.mm.ss format in the display. If this can't be done. I can go back to the more time consuming practice of putting the cooridnates in properly. Thanks. Americasroof (talk) 14:47, 21 November 2007 (UTC)

It looks fine in IE7 &FF2.0 (WINXPpro). It maybe some IE6 thing; ahhh the joys of microsoft. It sounds similar to a problem we had a while ago with the "dot" maps; but that was fixed (old discussion here). —MJCdetroit (talk) 16:12, 29 November 2007 (UTC)

Definitions for classes

Hi, there

Could anyone tell me where class="infobox geography vcard" is defined? I assumed it was in the monobook.css or the common.css, but I can't find it there. I'm translating the template for the Afrikaans Wikipedia and obviously need to include the definitions as well. Any help or advice would be appreciated. Anrie (talk) 13:39, 29 November 2007 (UTC)

Look for "infobox geography" class. "vcard" is a separate class, used for microformats, and is not wikipedia specific. --Qyd (talk) 19:38, 29 November 2007 (UTC)

Thanks for the quick reply. I'll have a look and post here if I run into any trouble. Anrie (talk) 19:48, 29 November 2007 (UTC)

Precision of square miles and square kilometers

This infobox automatically converts square kilometers to square miles (or vice versa) which is great -- but it uses the default precision, which is one tenth of one unit. This gives the illusion of greater accuracy than really exists. For instance, Jeddah has a metro area of 3,000 square kilometers, and this obviously has only one (or possibly two) significant digits. But this is converted to 1,158.3 sq mi, when 1,000 or maybe 1,200 would be less deceptive. I'm not sure the best way to handle this. Should it default to a precision of -2 (for use in {{km2 to mi2}})? Or should it have yet another optional parameter for the precision of each value? What do you think? – Quadell ^{(talk) (random)} 20:48, 8 December 2007 (UTC)

It is possible to specify both metric and imperial quantities in cases like this, which overrides the default conversion. But it might also be a good idea to introduce a precision parameter like you suggest. I don't think a default precision of -2 would be a good idea though (it would cause an unnecessary loss of precision in the majority of cases).--Kotniski (talk) 10:40, 9 December 2007 (UTC)

Locator map template in infobox

Redvers, Saskatchewan when adding the Saskatchewan template locator map to the city infobox, the statement [[Image:|250px|none|]] shows up in the infobox. Is there a way to add the locator map without the extra line of textSriMesh | talk 03:11, 10 December 2007 (UTC)

You would have to use pushpin_map instead of image_map (pushpin map calls up {{Location map}}).

|pushpin_map            = Saskatchewan
|pushpin_label_position = 
|pushpin_map_caption    =
|pushpin_mapsize        =200px

instead of

|image_map              = 
|mapsize                = 
|map_caption            = 

You would also have to add the coordinates as

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

I've been fixing this problem on some of the SK pages, but there's just so many of them.--Qyd (talk) 03:47, 10 December 2007 (UTC)

Qyd beat me here, but I fixed the article. Here's the diff —MJCdetroit (talk) 03:51, 10 December 2007 (UTC)

Disambiguation

Hi. In this template, when rendered is the title "Founded" which in turn links to Settlement. Could this be disambiguated to Settlement (migration) please as Settlement is a disambiguation page? Thanks. I would do it myself, but have zero experience in editing templates. -Seidenstud (talk) 08:50, 12 December 2007 (UTC)

Are you sure? I can't find any such link in the template code. Can you give an example of an article in which this occurs?--Kotniski (talk) 09:36, 12 December 2007 (UTC)

You couldn't find it because this template does not do that. In Seidenstud's contrib's his edit to Quebec City, which uses "|established_title= Founded", he did not edit the infobox, only a link in the text. Here is the diff. We'll definitely need a little clarifying of this. —MJCdetroit (talk) 16:09, 12 December 2007 (UTC)

Iowa settlements and "unit_pref"

This is an issue with several different templates used within this template, so I'm posting it here for now as it seemed the most relevant place.

In Iowa settlement infoboxes, such as for Des Moines, Iowa, metric appears first and imperial second. I know that template:areadisp, template:lengthdisp, and template:densdisp all check to see if the subdivision_name field equals "[[United States]]" (among other possibilities), and put imperial units first if it does; however, many (and from what I've seen, perhaps nearly all) of the Iowa city articles have this in the subdivision_name field:

[[Image:Flag of the United States.svg|20px]] [[United States]]

The extra flag-related text causes the templates to conclude that these are not United States articles, and so metric goes first. Technically, perhaps the flag should not be there; but on the other hand, it does seem a nice visual addition.

Currently the "among" template is used to see if the subdivision_name equals "[[United States]]". Is there a similar existing template that would check for a substring within the subdivision_name?

Another solution would be to add the "unit_pref" field to each of the affected Iowa articles, but since the code is already there and simply would need modification to allow for this situation, perhaps that would be easier, faster, and more elegant (if it can be done and if it doesn't have any negative impact). Omnedon (talk) 02:18, 17 December 2007 (UTC)

Detroiterbot was supposed to switch that (today infact) but it's hard to program it for every situation and I seen why it missed the unit_pref in the infobox in Des Moines; it caught it here and in many other IA locations. Therefore, I'll tweak it a little to run back through, if needed.

I think that [[Image:Flag of the United States.svg|20px]] [[United States]] can be added to the "catch list" as well. —MJCdetroit (talk) 03:24, 17 December 2007 (UTC)

I added [[Image:Flag of the United States.svg|20px]] [[United States]] to the three subtemplates listed above and that worked. —MJCdetroit (talk) 03:38, 17 December 2007 (UTC)

That was fast -- thanks! Nice work with your bot, by the way. Omnedon (talk) 03:45, 17 December 2007 (UTC)

Fast—no. My wife is watching that stupid show Survivor and I'm bored. Luck I guess.—MJCdetroit (talk) 04:02, 17 December 2007 (UTC)

In any case, your solution was even simpler than what I was suggesting. Don't know why it didn't occur to me. Omnedon (talk) 04:15, 17 December 2007 (UTC)

Something's not quite right

For cases where no website is given, there's now a short <hr> bar near the bottom of the infobox, with nothing underneath it. Examples: Divide, Colorado, Dumont, Colorado. -- Ken g6 (talk) 20:48, 23 December 2007 (UTC)

This resulted from Malyctenar's recent edits. It also messed up the "parts" section of the template as well. It seemed to have added Template:P37}; from Springfield (The Simpsons): Springfield Keys...Little Bangkok.. Template:P37}... This should be easy to fix, but I suspect that there maybe more errors. That being said, I reverted the changes until Malyctenar is 100% positive that they'll work. He seems to have a solution in the Template:Infobox Settlement/sandbox that works, but not knowing what he's got planned, I'll leave the testing of that to him. Remember that this template transcludes on over 40,000 pages; so be careful. —MJCdetroit (talk) 03:58, 24 December 2007 (UTC)

As for the URL, the problem was only in the second edit, and it was not a HR, it was an empty TR/TD - apparently another problem coming from mixing HTML table tags with the MediaWiki pipe ones, easily fixable. As for the P37, it should be a display of the parameter p37; have I mistakenly deleted a curly brace somewhere? I'll try to look into it when I have the time, and of course returning to the earlier state and treading lightly is the safest option. Thanks for letting me know, and sorry for the complications. --Malyctenar (talk) 13:03, 25 December 2007 (UTC)