Template talk:Infobox settlement

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Kotniski (talk | contribs) at 07:23, 20 May 2008 (→‎UN/LOCODE code insertion). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

List of articles using this template


Archive
Archives
  1. March 2005 – May 2006
  2. June 2006 – July 2006
  3. August 2006 - December 2006
  4. January 2007 - March 2007
  5. April 2007 – October 2007

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)[reply]

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)[reply]
(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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
It can't hurt to at least see what it would look like in the sandbox. —MJCdetroit 15:22, 8 November 2007 (UTC)[reply]
Change made in sandbox; tested at Gmina Stronie Śląskie.--Kotniski 16:08, 8 November 2007 (UTC)[reply]

(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)[reply]

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)[reply]

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)[reply]

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)[reply]
OK, I've set the maximum for no default collapse to 5. --Kotniski 19:18, 9 November 2007 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]

Dot Map

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

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)[reply]

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)[reply]

Seems a good idea to me.--Kotniski 09:38, 10 November 2007 (UTC)[reply]
I agree -- good idea! Omnedon 14:20, 10 November 2007 (UTC)[reply]
No objection here. —MJCdetroit 03:18, 11 November 2007 (UTC)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
Qyd beat me here, but I fixed the article. Here's the diffMJCdetroit (talk) 03:51, 10 December 2007 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
That was fast -- thanks! Nice work with your bot, by the way. Omnedon (talk) 03:45, 17 December 2007 (UTC)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]

Image_map error

Does anyone know why in Santa Cruz de la Sierra infobox the map Image:Distritosdesantacruz.png which is in the image_map field is not displaying? It's odd. BTW, I'm not talking about the pushpin_map which is displaying. — — MJCdetroit (yak) 17:18, 11 January 2008 (UTC)[reply]

This image file doesn't seem to display at all at sizes of less than 252px. I've changed the map size in the article to 260px and it appears OK. --Kotniski (talk) 10:38, 12 January 2008 (UTC)[reply]
Purged image, seems to work now at any size. --Qyd (talk) 16:55, 19 January 2008 (UTC)[reply]

Budget

I propose the addition of annual budget to the info box. This is valuable information. I realize that there are currency problems but the reader can work that out for him/herself. Student7 (talk) 13:27, 19 January 2008 (UTC)[reply]

You can you one of the "blank" fields for such an addition.
|blank_name             =
|blank_info             =
|blank1_name            =
|blank1_info            =
|blank2_name            =
|blank2_info            =

etc...—MJCdetroit (yak) 13:31, 19 January 2008 (UTC)[reply]

Thanks. I think this needs to be permanent for everyplace. The use of blanks suggests a local peculiarity that needs to be addressed. I think the need is universal. Student7 (talk) 13:41, 19 January 2008 (UTC)[reply]
I think it'd be appropriate for large cities, but it shouldn't be a permanent or universal feature. Many places that use the infobox don't have budgets at all – I'm thinking particularly of unincorporated towns and other small communities, of which there are a great many. Huwmanbeing  14:11, 19 January 2008 (UTC)[reply]
I agree with Huwmanbeing. —MJCdetroit (yak) 14:16, 19 January 2008 (UTC)[reply]
For those few villages without a budget (also without fixed boundaries and a number of other requirements, but we won't go there!) budget would be a skipped item. We skip items all the time that aren't important. Budget is important. Student7 (talk) 14:34, 19 January 2008 (UTC)[reply]
I don't think it's so important that it requires a dedicated field in the infobox. It might also be hard to define consistently, and to keep updated year after year.--Kotniski (talk) 15:19, 19 January 2008 (UTC)[reply]
Personally, I do agree that budgetary info is important for cities, but it's just not something that's applicable in the majority of cases. I say "majority" because, in the regions I'm familiar with, most counties tend to have several times as many small towns with little to no government as they do large incorporated cities. I suspect this is true throughout much of the U.S. However, as MJCdetroit mentioned, you can go ahead and include budget figures where available by using the blank fields provided. Even better, you could include it in the body of the article. (After all, not everything in the body necessarily needs to be in the infobox.) Huwmanbeing  15:49, 19 January 2008 (UTC)[reply]
If you are suggesting that the budget is irrelevant to the settlement, I suppose that the government could be broken out from it. On an average, the government is only 20% (usually much less) of an impact on the Local Domestic Product. If the government were broken out, the new article could concentrate more easily on number of employees, taxation, budget, etc. The former article would be free-er to concentrate on what the people do and maybe with less restrictions on geographic boundaries. Student7 (talk) 15:15, 19 January 2008 (UTC)[reply]
I'm not sure what you're saying here, or what it has to do with the Infobox.--Kotniski (talk) 15:19, 19 January 2008 (UTC)[reply]
The blank fields are more than enough for this issue, as well as for many other things that can be said about a city. Regardless of how important they are or appear to be. In fact, the convoluted syntax could be simplified by cutting down on parameters that can easily be accommodated by blank fields. --Qyd (talk) 16:51, 19 January 2008 (UTC)[reply]

Logo box

Does anyone else think that a logo image would be beneficial? I know that my city has a logo, and it would be nice to be able to put it in the top of this infobox. —Preceding unsigned comment added by 76.64.210.126 (talk) 23:49, 21 January 2008 (UTC)[reply]

You can use the image_blank_emblem parameter (and optionally blank_emblem_type for the caption, but it already defaults to Logo).--Kotniski (talk) 07:58, 22 January 2008 (UTC)[reply]

I think there should be an example.

I want an example of a settlement. Dinokid (talk) 23:14, 3 February 2008 (UTC)[reply]

"Settlement" is a very generic name that is used by this template that could refer to a wide variety of settlement types; some examples: see Town, Village, Hamlet, Governorate, Reservation, A country's political divisions (states). Here are 40,000+ examples that you can also look atMJCdetroit (yak) 15:22, 4 February 2008 (UTC)[reply]

UN/LOCODE

next to

|postal_code_type
|postal_code
|area_code

a field

|un_locode 

could be added. The UN/LOCODE database contains more than 50 000 locations worldwide. This way, it could also be checked whether wikipedia misses some (provided someone is able to run a DB query that does that, but from the DPL extension I know that this is possible). TimCod (talk) 00:52, 16 February 2008 (UTC)[reply]

The Issue 2007 contains 58.875 codes. I support the idea of adding a variable un_locode. We can see, maybe a bot can help filling the field. UnLoCode (talk) 12:17, 7 April 2008 (UTC)[reply]

I think the quality of Wikipedia and of the UN/LOCODEs can be increased, if these two databases are tight closer together. WP would have an official reference for existence of a settlement and the UN would have nice articles related to their codes :-). A lot of articles have already a UN/LOCODE redirect, which allow websites running with UN/LOCODE to link to WP, see Category:Redirects_from_UN/LOCODE. Adding the UN/LOCODEs to all settlement articles would help the process of creating redirects. UnLoCode (talk) 19:53, 8 April 2008 (UTC)[reply]

I changed the code over at the sandbox. Everyone can compare the infoboxes on the testcase page.
Now that people can see what it will look like, the question I had is how will this benefit us? Let's say that there is an entry in this UN database for São Vicente Ferrer, Maranhão but the wikipedia entry does not have an infobox, will a bot be able to insert an infobox based on the UN database? I guess that I am failing to see the benefit at the moment. —MJCdetroit (yak) 01:32, 9 April 2008 (UTC)[reply]
Can an url be automatically created using the code?--Qyd (talk) 02:23, 9 April 2008 (UTC)[reply]
Over at {{Infobox German Location}} we have a UN/LOCODE field (called simply "LOCODE"), but it is not displayed in the box itself (e.g. code is given for Frankfurt, but not shown). Echoing the above comments, simply displaying this code doesn't really bring much. If it could be used in some sort of url (i haven't found one yet, but even something that tells you the current weather there would be nice), then the extra functionality would be worthwhile. It should also be noted that these codes are not only for places, but for other locations such as airports.
Thinking longterm, it is a worthwhile addition since a use for it is sure to arise one day. But I wouldn't actually display the information. 52 Pickup (deal) 06:25, 9 April 2008 (UTC)[reply]
http://unlocode.hmap.info/?loco=CHGVA is one application that allows incoming locode links. They also have outgoing links to Wikipedia - if there is a redirect ( Category:Redirects from UN/LOCODE has around 6500 ). So we need a bot like Rambot did for the US, to create the redirects. But if we don't know where the redirects should point to, because the UN/LOCODE is not in the article, then it is hard to create them. The info should be shown, otherwise readers that go around cannot check the accuracy - they simply won't see that the LOCODE is there. UnLoCode (talk) 19:20, 10 April 2008 (UTC)[reply]
They have shorter links now: http://unlocode.hmap.info/CHGVA , http://unlocode.hmap.info/USNYC UnLoCode (talk) 12:38, 19 May 2008 (UTC)[reply]

What has to be done to add the variable un_locode to the article, let's assume hidden for now? UnLoCode (talk) 12:22, 25 April 2008 (UTC)[reply]

If it's to be hidden for now, then nothing needs to be done with the template (except perhaps a note on the documentation page). You can simply add a line "| un_locode = xxxxxx" within the Infobox code on each article page. The template could be modified later to display the code somewhere if that was felt to be useful. --Kotniski (talk) 12:47, 25 April 2008 (UTC)[reply]
Yes :-). I only wanted it more official. Do we have some agreement for this value to be added to the infoboxes? If I ask for bots to insert the values, maybe the bot owner wants something more official. If it is in the doc, then this maybe is sufficient. UnLoCode (talk) 11:39, 26 April 2008 (UTC)[reply]

UN/LOCODE code insertion

After the Area Code section

}} }}<!-- ***** Area Code(s) ***** -->
{{#if:{{{area_code|}}}|
	<tr class="mergedrow">
		<th>[[Telephone numbering plan|Area code(s)]]</th>
		<td>{{{area_code}}}</td>
	</tr>

it should be inserted

}} }}<!-- ***** UN/LOCODE ***** -->
{{#if:{{{un_locode|}}}|
	<tr class="mergedrow">
		<th>[[UN/LOCODE]]</th>
		<td>{{{un_locode}}}</td>
	</tr>

Edit link: http://en.wikipedia.org/w/index.php?title=Template:Infobox_Settlement&action=edit

UnLoCode (talk) 14:48, 7 April 2008 (UTC)[reply]

Quick note: I have declined this bot request as the parameter has not yet been added to the template. When it is, please contact me and I'll be more than happy to run a script to add it to articles. RichardΩ612 Ɣ ɸ 20:16, May 19, 2008 (UTC)
The idea seems to be that, for the moment, the parameter is not to be displayed (see above discussion). This means that nothing effectively needs to be done to the template code itself. If we add this parameter to the template documentation, will that be enough?--Kotniski (talk) 07:23, 20 May 2008 (UTC)[reply]

Settlement

Hihi

Working on the DAB pages for Settlement and discovered this in the infobox:

 + |subdivision_type = Country 
 + |subdivision_name = China 
 + |subdivision_type1 = Region 
 + |subdivision_name1 = Tibet 
 + |subdivision_type2 = Prefecture 
 + |subdivision_name2 = Xigaze Prefecture 
 + |subdivision_type3 = County 
 + |subdivision_name3 =  
 + |subdivision_type4 = Nearby settlements (distance)  
 + |subdivision_name4 =  


Here under "Subdivision type 4" it links to Settlement which is the DAB page, this should probably go to Human settlement although that page needs help too :) anyway, I've no clue how templates work, if we change it here will it change throughout WP or would I still go through and fix the links? THANK YOU for your help!! Legotech (talk) 05:02, 23 February 2008 (UTC)[reply]

You don't say on which page you discovered this. You should change the link on that page (those pages?) only. The link to settlement is not in the template, just on certain page(s) that call the template. Hope this makes sense.--Kotniski (talk) 10:57, 23 February 2008 (UTC)[reply]


I didn't say which page because its well over 100 pages[[1]]. I can fix them now no worries, but if its going to happen everytime someone uses the infobox, welll.... So is someone just putting that line in each time they use the infobox? I'm confused. This line isn't automatic?

+ |subdivision_type4 =Settlement|Nearby settlements (distance)

(wiki markup removed for visibility)

Thanks! Legotech (talk) 17:27, 23 February 2008 (UTC)[reply]

Right, someone who's been working on Tibet articles seems to have been putting that line in. (The search string you cited above is the wrong one I think, but I found 127 articles by just searching for "subdivision_type4 = Nearby", and they all seem to be Tibetan.) It certainly doesn't come automatically with the template.--Kotniski (talk) 17:45, 23 February 2008 (UTC)[reply]

Drat...was hoping this was easy :) Thanks! I'll fix em! Legotech (talk) 17:50, 23 February 2008 (UTC)[reply]

If it's Tibet, then it sounds like User:Blofeld of SPECTRE's work. —MJCdetroit (yak) 20:05, 23 February 2008 (UTC)[reply]

I don't know, I know a few other editors have been adding settlement type to the infoboxes. I;ll be sure to remember that it is human settlement in future though. Thanks ♦Blofeld of SPECTRE♦ $1,000,000? 21:05, 23 February 2008 (UTC)[reply]

Thank you! Is there a project page or something that we can let peoples know about it? Thanks again! Legotech (talk) 21:09, 23 February 2008 (UTC)[reply]

A few suggestions

I am considering adding the following to the Settlement infobox:

 + |congressional_district
 + |senate_district
 + |assembly_district (for states with a State Assembly; I am specifically working on California)
 + |house_district (for states that have a State House of Representatives)

Also a box for registered voters for each party:

 + |percent registered Democratic
 + |percent registered Republican
 + |percent registered Green
 + |percent registered Libertarian
 + |percent registered American Independent
 + |percent registered Peace and Freedom
 + |percent Independent

Socal gal at heart (talk) 10:06, 7 March 2008 (UTC)[reply]

Interesting idea, but it seems to apply only to U.S. locations, and this Infobox is used for places all over the world. Would it be possible to put this political information into a separate infobox template, to be added below Infobox Settlement on U.S. pages? --Kotniski (talk) 10:50, 7 March 2008 (UTC)[reply]
the firs part can be accommodated by the existing fields/parameters. The second batch, in my opinion, belongs in the text, not in the infobox. --Qyd (talk) 14:44, 7 March 2008 (UTC)[reply]
Ditto to Qyd's comments. See my edits to San Luis Obispo, California and East Porterville, California. The second "percent" batch seems a little much for the infobox and belongs in the text. If you really must have them, there are "blank_fields" for such things and ways to make it look a little neater using {{Collapsible list}}, but I can foresee such additions being reverted by editors. —MJCdetroit (yak) 15:08, 7 March 2008 (UTC)[reply]
Thanks for the suggestions. I thought about adding the percent registered by party because I thought it would be similar to the ethnic composition that is in the infoboxes of the U.S. Congressional Districts. I'll just experiment with a separate infobox. Socal gal at heart (talk) 09:11, 8 March 2008 (UTC)[reply]
Try playing with the generic {{Infobox}} instead of trying to create a new infobox. Also, such an infobox would need to be updated every election (every 2-4 years). —MJCdetroit (yak)
I can update the boxes after every election. Socal gal at heart (talk) 14:12, 12 March 2008 (UTC)[reply]

Infomation

Please change the misspelled word infomation, which occurs three times (of which twice in section titles), to information.  --Lambiam 11:35, 7 March 2008 (UTC)[reply]

Those errors ocurred at Template:Infobox Settlement/doc. The /doc page is not a fully protected page but I made the corrections anyway. —MJCdetroit (yak) 12:26, 7 March 2008 (UTC)[reply]

Area code link?

{{editprotected}} How about turning the words "Area code" into a wikilink?

 DoneJon513 (talk) 16:28, 9 March 2008 (UTC)[reply]

Harvard referencing

Apparently this infobox produces two endnotes. This is not compatible with articles that use Harvard referencing, which is an acceptable citation method in Wikipedia. How can the infobox be used in such articles? (The article where this was a problem was Ira, Vermont. --Gerry Ashton (talk) 03:22, 13 March 2008 (UTC)[reply]

I am assuming that the endnotes you refer to are the "FIPS code" and "GNIS feature ID". Those are not produced per se by the coding of this template. They were inserted by User:CapitalBot in this edit.
As far as using Harvard referencing within the infobox, technically I guess it could be done. However, infoboxes, any infobox that is, are supposed to be quick and neat overviews of statistics, maps, facts, et cetera. To use Harvard referencing would surely clutter the infobox with unnecessary text like: (Smith 2005, p. 1). I am sure there are many articles that use both styles contrary to what WP:Cite#How says to do. Perhaps, you should see what the editors over at WP:Cite feel about two styles in the same article; maybe Harvard for the text and in-line (or whatever it's called) for infoboxes and tables. —MJCdetroit (yak) 16:20, 13 March 2008 (UTC)[reply]
Before the edit pointed out by MJCdetroit, there was no infobox at all. In one edit, the infobox, including the endnotes, appeared. There are no <ref> tags in the infobox invocation. Can MJCdetroit please explain why the statement "those are not produced per se by the coding of this template" is true? I don't know much about coding templates. --Gerry Ashton (talk) 17:33, 13 March 2008 (UTC)[reply]
It's produced by {{GR|2}} and {{GR|3}}, which are invoked inside the "blank_info" and "blank1_info" fields in the mentioned edit. --Qyd (talk) 18:01, 13 March 2008 (UTC)[reply]

Fact tag in population_total parameter

Does anyone know why adding a {{fact}} tag to the population_total parameter causes it to go into a category with a comma inserted oddly? For example, Funningsfjørður is being put into Category:Articles with unsourced statements since January 2,008 for some reason. -- Ricky81682 (talk) 01:12, 6 April 2008 (UTC)[reply]

This is because the field is coded to automatically format any numbers, hence January 2008 becomes January 2,008. The field is intended to only have numbers entered. There is actually a "Important Note" about only using RAW unformatted numbers on the template page. I advise that you place the {{fact}} tag in the |population_footnotes field. See my changes to Funningsfjørður. —MJCdetroit (yak) 01:26, 6 April 2008 (UTC)[reply]

Auto-linking?

This template appears to be automatically linking the names of the city mayors and the like, as seen on College Station, Texas. This really needs to be rethought or the instructions clarified on how to stop this. Most city mayors are not going to have Wikipedia articles, and there needs to be a way to be able to put in customized links. Collectonian (talk) 23:07, 7 April 2008 (UTC)[reply]

I agree that this behaviour is not necessarily desirable, but if a lot of articles are currently assuming automatic linking, it might be hard work to change. I don't think there is any problem putting in customized links; a problem might arise if the mayor doesn't have an article but has a name which is the name of an article (or disamb page). A workaround in this case would presumably be to add an HTML no-break space to the mayor's name in the infobox.--Kotniski (talk) 09:34, 8 April 2008 (UTC)[reply]
I suspect most people haven't noticed. I didn't until someone tried to "fix" the link in the CS article because the mayor shares a name with a rugby league player. How long as it been doing the automatic linking? Is there anyway to check and see how many are actually linking to the right place? (the adding an non-breaking space worked to remove the link at least :) ) Collectonian (talk) 14:29, 8 April 2008 (UTC)[reply]
It's been doing the automatic linking for as long as I can remember (which must be something approaching a year). Oddly it's only the leader names and some of the flag/seal captions which get automatically linked (using the #ifexist parser function), none of the other infobox values. I don't know any way of checking up on the use of these links. MJC, any ideas?--Kotniski (talk) 14:39, 8 April 2008 (UTC)[reply]
The template has been autolinking since February of 2007 with this edit. This is the first complaint that I've heard of and errors are probably rare. We'll just have to make note of this on the doc page and the &nbsp;before the name to turn off the autolinking. I can't think of a way to check that the autolink for John Doe, mayor of Anywhereville, BFE leads to an article on a mayor and not someother guy. —MJCdetroit (yak) 01:30, 9 April 2008 (UTC)[reply]
Customised links can be made. There's nothing at all wrong with adding wiki markup in this field. While it is not likely that there will be separate articles for every mayor in Texas, keep in mind that this template is used for many of the world's major cities and I am certain that, more often than not, automatically generated links go to the right person. As far as I know, there is no way to check these links apart from manually. As stated above, this is the first complaint we've had since I made these changes over a year ago. So I assume that most people are happy with how it works.
So, when adding the template to an article, check the link first. Then, if such a false link comes up, either 1) add &nbsp; spacing to break the linking; 2) add any middle initials; or 3) create a new article (with disambiguation). 52 Pickup (deal) 06:04, 9 April 2008 (UTC)[reply]

Tallest structure

Any support for or objections to adding "tallest structure" to the template? Accurizer (talk) 18:47, 19 April 2008 (UTC)[reply]

For big cities, that wouldn't be bad. For most settlements, though, I suspect it'd be quite difficult to find any sources that would note that kind of thing. It might be easiest to just include "tallest structure" info in the body of text for those communities where that statistic is known and documented. Huwmanbeing  19:17, 19 April 2008 (UTC)[reply]
That's a good point. Accurizer (talk) 20:57, 19 April 2008 (UTC)[reply]

Coord to display in titles

I think there should be a parameter that would allow the same coordinates, that used in the infobox to be displayed in the title. That would save from having to double-include {{coord}} in the same article. For example, London has the coordinates in the infobox but then needs a second template down the bottom to display the same coordinates on the title so that the city would be included in WikiMiniAtlas. Renata (talk) 07:36, 29 April 2008 (UTC)[reply]

The {{Geobox coor}} template which generates the coordinates in the Infobox actually offers this functionality according to the documentation on its talk page(although there is also an old discussion there mentioning problems - don't know if it's currently fixed). So we would just have to define a new parameter (called coor_title or something like that), to be assigned the value 1 if the coordinates are to go in the title too, and then add the code:
|title={{{coor_title|}}}
in the {{Geobox coor}} call within the Infobox. I don't know how this affects WikiMiniAtlas though - depends whether it's compatible with Geobox coor.--Kotniski (talk) 08:05, 29 April 2008 (UTC)[reply]
Why shouldn't the coordinates always be in the title alone? Kanguole (talk) 08:28, 2 May 2008 (UTC)[reply]
Well, that would have been a possibility, but so many articles now have a separate coord template that it would take a huge amount of work to change. In any case there are differing philosophical views about coordinates - some people think that those in the title should be representative of the whole entity, without speicfying exact;y which point they are the coords of. In the Infobox you can specify what the coords are actually of - useful if you're dealing with a large city or a district, for example..--Kotniski (talk) 08:36, 2 May 2008 (UTC)[reply]
So ideally the coords would be in the title alone unless coor_type was specified, in which case they'd also be inline. Could that behaviour be provided as an option? Kanguole (talk) 10:35, 2 May 2008 (UTC)[reply]
Well I guess it could, though I don't see that it would be of great benefit, since if you want the coords to be in the title alone you can just use the coord template and not bother with any coords in the Infobox.--Kotniski (talk) 10:03, 4 May 2008 (UTC)[reply]

Incorporation

Can there be a line for date of incorporation? I think this would be very useful to be in a standardized place on every city article. —ScouterSig 20:22, 29 April 2008 (UTC)[reply]

There is.
|established_title      =  
|established_date       = 
|established_title1     =  
|established_date1      = 
|established_title2     = 
|established_date2      = 
|established_title3     =  
|established_date3      =
You can place whatever you feel is appropriate in the "..._title" fields, like settled, founded, incorporated... see Boston for an example. —MJCdetroit (yak) 00:41, 4 May 2008 (UTC)[reply]