Template talk:Infobox settlement

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Pigsonthewing (talk | contribs) at 10:24, 7 October 2008 (→‎Native name langugae: r). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Jump to navigation Jump to search

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
  6. November 2007 – December 2007
  7. January 2008 – April 2008

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]
The "goal" is to just have to input the coordinates input once within an article's Geobox/Infobox and have them displayed in the article's Infobox (for people) as well as having them displayed in the title bar (where Google and other services look for them when "datamining" Wikipedia pages.) There also are odd circumstances where more than one set of coordinates exist within an article and one needs control over exactly which one is in the article's title bar.
I have seen some articles with the "same" coordinates suffering from typos where then were entered more than once in an article and either from typos or updates, the coordinates diverged (i.e. someone either making a typographical error or updating one set of the coordinates without updating all the others). In the simplest case, coordinates should only be in the geo/infobox with the exact same coordinates replicated in the article's title bar (without having to reenter them). In the "most" complex case, with an article containing multiple coordinates, it should be clear exactly which set are replicated in the article's title bar, while the other coordinates only display in geo/infoboxes or inline text associated with the feature they are attributed to. Multiple coordinates often arise when there are multiple features with similar names or another relationship to other relevant features, it often makes sense to cover the relevant features in different sections of one article rather than having separate articles for each one. For instance a settlement named for a nearby prominent geographic feature or vice versa. Another example is when a settlement historically used to be at once location, but for some reason relocated to another location (for instance, settlements which were "wiped off the map" by earthquakes, floods, volcanoes, ... and subsequently relocated at another nearby location).

LeheckaG (talk) 12:49, 5 August 2008 (UTC)[reply]

{{Editprotected}} Requesting that an Infobox Settlement coordinates_display= or coordinates_title= field be added, with a default value of either: =inline, or blank/empty/undefined; to accept and pass the {{Geobox coor}} title= parameter which then gets "fed" to the {{Coord}} display= parameter, so that coordinates can be displayed either in-place =inline, or in the article's title bar =title, or both =inline,title. As it is now, Infobox Settlement does not display coordinates in the article's title bar, so the only way to get the article to properly show up on map services (like Google Maps or other map services showing Wikipedia articles) is by "unnecessarily" duplicating coordinates within an article and setting an appropriate display=title parameter of the other set of coordinates (either in the text like in a Geography section or in External links) which often results in multiple inaccurate sets of coordinates in articles. LeheckaG (talk) 17:32, 22 August 2008 (UTC)[reply]

 Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. Eh?? :D Some code would be nice... Happy‑melon 16:05, 23 August 2008 (UTC)[reply]

{{Editprotected}} Okay ... {{Geobox coor}} accepts a title= parameter, which if set/non-blank, invokes {{Coord}} with display=inline,title; else display=inline.

This is the {{Infobox Settlement}} section which would be updated: 

<!-- ***** Coordinates ***** -->
{{#if:{{{latd|}}}|
      <tr class="mergedbottomrow">
	<th colspan="2" style="text-align: center; font-size: smaller; padding-bottom: 0.7em;">Coordinates{{#if:{{{coor_pinpoint|{{{coor_type|}}}}}}| ({{{coor_pinpoint|{{{coor_type|}}}}}})|}}: {{Geobox coor|{{{latd|}}}|{{{latm|}}}|{{{lats|}}}|{{{latNS|}}}|{{{longd|}}}|{{{longm|}}}|{{{longs|}}}|{{{longEW|}}}|{{{coordinates_type|type:city}}}}}</th>
      </tr>
}}

With either (always pass a title= parameter, even if {coordinates_display} is blank or undefined): 

<!-- ***** Coordinates ***** -->
{{#if:{{{latd|}}}|
      <tr class="mergedbottomrow">
	<th colspan="2" style="text-align: center; font-size: smaller; padding-bottom: 0.7em;">Coordinates{{#if:{{{coor_pinpoint|{{{coor_type|}}}}}}| ({{{coor_pinpoint|{{{coor_type|}}}}}})|}}: {{Geobox coor|{{{latd|}}}|{{{latm|}}}|{{{lats|}}}|{{{latNS|}}}|{{{longd|}}}|{{{longm|}}}|{{{longs|}}}|{{{longEW|}}}|{{{coordinates_type|type:city}}}|title={{{coordinates_display|}}}}}</th>
      </tr>
}}

or (only pass a title={coordinates_display} parameter when {coordinates_display} is defined and non-blank): 

<!-- ***** Coordinates ***** -->
{{#if:{{{latd|}}}|
      <tr class="mergedbottomrow">
	<th colspan="2" style="text-align: center; font-size: smaller; padding-bottom: 0.7em;">Coordinates{{#if:{{{coor_pinpoint|{{{coor_type|}}}}}}| ({{{coor_pinpoint|{{{coor_type|}}}}}})|}}: {{Geobox coor|{{{latd|}}}|{{{latm|}}}|{{{lats|}}}|{{{latNS|}}}|{{{longd|}}}|{{{longm|}}}|{{{longs|}}}|{{{longEW|}}}|{{{coordinates_type|type:city}}}{{#if:{{{coordinates_display|}}}|{{!}}title={{{coordinates_display|}}}}}}}</th>
      </tr>
}}

{{Infobox Settlement/doc}} should then be updated to reflect coordinates_display= parameter ... LeheckaG (talk) 12:17, 24 August 2008 (UTC)[reply]

 Done Please make sure that the documentation is suitably updated. Happy‑melon 14:47, 24 August 2008 (UTC)[reply]
Tested, works great. Omitting coordinates_display= results in the current {{Coord}} behavior, and including coordinates_display=inline,title (currently can be anything non-blank - {{Geobox coor}} just checks for a non-blank parameter, hopefully =inline,title is relatively intuitive?) causes coordinates to display in an Infobox Settlement article's title bar as requested. Thank You. ... I am updating {{Infobox Settlement/doc}} ... LeheckaG (talk) 15:16, 24 August 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]

Flag problem

For the life of me, I cannot get the flag to show up on http://en.wikipedia.org/wiki/User:Nricardo/sandbox. Any help would be greatly appreciated. Thanks. --Nricardo (talk) 10:47, 2 June 2008 (UTC)[reply]

At 100px the template wouldn't display, but at 105px the flag displays. Dunno why...good luck. —MJCdetroit (yak) 11:48, 2 June 2008 (UTC)[reply]
Weird. Thank you very much! --Nricardo (talk) 03:00, 3 June 2008 (UTC)[reply]

Overlinking

Please can somebody delink the common units of measurement (km², sq mi) in the template. The guidance at wp:overlink says:

  • In general, do not create links to: ... Plain English words, including common units of measurement
  • Examples of common measurements include: ... metric units of ... length ... some imperial and US units such as inch, foot, yard, mile, etc.

Thanks Lightmouse (talk) 16:39, 7 June 2008 (UTC)[reply]

If no one has any objections it could probably be done. —MJCdetroit (yak) 00:56, 8 June 2008 (UTC)[reply]

No objection from me. All that would be required would be to delete the word "link" from the three subtemplate calls (without deleting any pipes, i.e. leaving an empty-string parameter). And there seems also to be one explicit link, in the bit of the area code that deals with dunams.--Kotniski (talk) 04:17, 8 June 2008 (UTC)[reply]

Thanks. That would be great. I think 'dunam' is sufficiently obscure to require a link. But please delink the common units. Lightmouse (talk) 09:53, 3 July 2008 (UTC)[reply]
I would, but don't have the privilege - an admin would have to do it. MJC?--Kotniski (talk) 09:56, 3 July 2008 (UTC)[reply]
It's a done deal: followed your suggestion as to the correct code tweak, and it seems to be OK. Alai (talk) 15:55, 3 July 2008 (UTC)[reply]

Thank you very much. That has improved a lot of articles. Lightmouse (talk) 16:04, 3 July 2008 (UTC)[reply]

Leader Party

Hello.

At the moment, only the leader without the number can have a party (i.e. leader_name). Is it possible to put something in the syntax to allow parties on the numbered ones (i.e. leader_name1)? It would be helpful for cities like Tauranga, which has two electorates and has two MPs. However, only one MP can have a party displayed if I insert the names of the MPs.

Laydan Mortensen (talk) 08:17, 8 June 2008 (UTC)[reply]

You can always just put the party in brackets after the name of the MP.--Kotniski (talk) 08:25, 8 June 2008 (UTC)[reply]

Scope?

What's the scope of this infobox? I understand it is intended for all cities, towns, villages, etc. How about regions, counties, municipalities, and other administrative subdivisions? Are they supposed to use template also? Renata (talk) 23:15, 8 June 2008 (UTC)[reply]

They can. Are supposed to? Maybe, maybe not. It's a judgment call that depends on quality. Mexican States like Quintana Roo use this infobox and so do provinces in Iraq and counties in Canada. (There are better examples, but those are the quickest that I could think of.) However, U.S. states and counties have had their own good/well maintained infoboxes long before this infobox was as good as it is now. So they would not use this infobox. Where did you want to use this infobox? —MJCdetroit (yak) 03:32, 9 June 2008 (UTC)[reply]
I guess a better question is: are there any plans to migrate from country-specific subdivision infoboxes to this one? Renata (talk) 14:52, 9 June 2008 (UTC)[reply]
This has already been done for Poland (I know because I did it); I don't know what plans there are for any other countries. I think some countries have good infoboxes of their own (the US and UK, for example, but I've seen others) which have no need to migrate; others are less attractive so would probably benefit from migration to here. I think User:Blofeld of SPECTRE takes care of a lot of this sort of thing.--Kotniski (talk) 16:13, 9 June 2008 (UTC)[reply]

transliteration to transcription

I changed the word "transliteration" to "transcription", after a discussion at Template talk:Infobox Korean settlement#Why not use infobox settlement?. "Transliteration" may not alright for all uses, so it was changed to transcription. If anyone has a better idea... —MJCdetroit (yak) 16:37, 14 July 2008 (UTC)[reply]

Nicknames

Is there anyway to make "nickname" display as "nicknames" or even "nickname(s)"? Many cities have more than one and technically it is grammatically incorrect. Grey Wanderer (talk) 02:21, 19 July 2008 (UTC)[reply]

 Done. Adjusted the coding a little to read "Nickname(s)" —MJCdetroit (yak) 03:08, 19 July 2008 (UTC)[reply]

Timezone parameters

The current setup of the timezone-related parameters (timezone, utc_offset, timezone_DST, and utc_offset_DST) assumes the existence of named timezones. However, many smaller countries that lie entirely within a single timezone (example, Armenia) don't have names for timezones. The template does not format the timezone fields meaningfully in these instance, as the infobox on the Armenia page shows. You cannot leave timezone= blank, or the line will not appear at all; and you cannot leave utc_offset blank, or you get a line like "UTC+4 (UTC)". Can these parameters be adjusted to allow omitting the utc_offset fields when the timezone name is the UTC offset? --Russ (talk) 09:55, 20 July 2008 (UTC)[reply]

I suggest using the TZdata parameter. So for Armenia it would be "tzid=Asia/Yerevan" and templates should handle the rest, i.e. adding generic zone name and UTC offsets. In case Armenia switches the UTC offset or adds/withdrwas DST it can be change in one place and is not needed to be changed in every page that uses the Infobox. Recent example was Venezuela which changed the UTC offset to UTC-4:30. TzClock (talk) 21:22, 15 September 2008 (UTC)[reply]

overlaying other templates bug?

Como (this version) had Template:Infobox Weather this template underlaid by Template:Infobox Settlement. Is this intended, if so is there a workaround? -84user (talk) 22:01, 20 July 2008 (UTC)[reply]

If possible, and sometimes it can't be avoided but the climate section should be a little further down the page. If this isn't possible, {{-}} (the clear all template) just before infobox weather will solve this. —MJCdetroit (yak) 01:15, 21 July 2008 (UTC)[reply]

Please improve documentation

For example, what are the allowed values for the various "size" parameters? Is it a number, or a number followed by px? Thanks. -84user (talk) 23:26, 20 July 2008 (UTC)[reply]

Population estimates

I started a proposal to create a bot to update US city articles with the 2007 population estimates that is tangentially related to this infobox (the bot would be updating the population_as_of, population_total and population_footnes lines in the template accordingly) and a discussion regarding the topic on the Village Pump (located here) suggested that population estimates may not be sufficiently official for population figures. A suggestion was also made to modify this template to include separate lines for population figures and estimates. I got no response from the WP:CITY project on this, so figured I'd see if anyone has perhaps got this template watchlisted and would care to chime in as to whether it's preferable to modify this template as suggested, or just go ahead and consider the annual estimates as sufficiently "official" to use as population figures. Shereth 18:32, 22 July 2008 (UTC)[reply]

Adding an "estimate" field is something that should be explored. Many uses of the template will give the value in the total population field and place 2008 estimate in the "population_as_of" field. —MJCdetroit (yak) 16:16, 25 July 2008 (UTC)[reply]
I've placed some new fields associated with population estimate in the sandbox (in this version: here). You can review the results in the testcases page —MJCdetroit (yak) 16:28, 4 August 2008 (UTC)[reply]

Metric

I'm trying to use metric units for the article on Plymouth, but when I try to insert the units parameter it doesn't change it. This might be because it's in the United Kingdom, but I'm really not sure. There is also a discussion about the use of metric or imperial going on at Wikipedia talk:WikiProject UK geography/How to write about settlements#Climate and consistency. bsrboy (talk) 14:51, 25 July 2008 (UTC)[reply]

The UK defaults to imperial. —MJCdetroit (yak) 16:12, 25 July 2008 (UTC)[reply]
How do you take the default off? bsrboy (talk) 17:02, 25 July 2008 (UTC)[reply]
Rewrite the code, which would/may affect the present look of the all the UK infoboxes. —MJCdetroit (yak) 17:21, 25 July 2008 (UTC)[reply]
If you really wanted to do it, I guess adding a no-break space to the country parameter would do the trick. But is there any reason why Plymouth's infobox should look different from the standard for its country?--Kotniski (talk) 00:28, 26 July 2008 (UTC)[reply]
On previewing it, it comes up with the following message in the infobox "Expression error: Unrecognised punctuation character "&"". bsrboy (talk) 00:55, 26 July 2008 (UTC)[reply]
The nbsp has to be added to the value of the parameter "subdivision_name". Then it should work (but I still don't see the justification).--Kotniski (talk) 09:27, 26 July 2008 (UTC)[reply]
This is too annoying. I'm just going to use imperial throughout instead, except climate. bsrboy (talk) 12:44, 26 July 2008 (UTC)[reply]

Proposal: delete nickname field

We've had some controversy and discussion at Talk:Albuquerque, New Mexico regarding nicknames for the city. There's been a persistent problem where some editors add nicknames that are not well-known and are challenged by other editors. It doesn't help that the editors supplying the new nicknames are often IP editors or are later discovered to be sockpuppets of banned editors. For the time being we have solved the problem by not using any nicknames.

My feeling is that city nicknames are not encyclopedic. They are also difficult to verify; that is, it's hard to find reliable sources that say in so many words that X is a nickname for city Y, even if the nickname is well know (as Duke City is for Albuquerque).

Therefore I propose that we delete the nickname field from this template. --Uncia (talk) 16:10, 27 July 2008 (UTC)[reply]

Some places do have verifiable nicknames; most probably don't. We don't want to delete a field which is useful in articles in the first category, just because it occasionally gets misused for those in the second. (There are other ways of dealing with this problem; and in any case deleting the field doesn't prevent people from inserting the information in slightly different ways.)--Kotniski (talk) 16:36, 27 July 2008 (UTC)[reply]

proposing coords parameter

Would anyone object if an additional coords parameter were accepted by this template? I suggest doing this the same way as {{Infobox Protected area‎}} (which I recently changed) where the series of 8 coord parts (lat_degrees, lat_minutes, lat_seconds, lat_direction, long_degrees, long_minutes, long_seconds, long_direction) can be replaced by, for example: 

 {{Infobox Settlement
  ...
 | coords = {{coord|45|12|34|N|123|45|56|W}}
  ...

This has several advantages.

  • Latitude and longitude may be expressed, optionally, in decimal {{coord|45.678|-123.456}}
  • The display=title,inline parameter may be used to avoid the need to have two (or more) sets of coordinates in an article.
  • The name= parameter may be used to name the point on the external maps differently than the article.
  • Minutes and seconds need not be specified if not known, or not appropriate. {{coord|45|N|123|W|name=Somewhere in Oregon}}
  • Direct access to the coordinate qualifiers for specifying map scale, region, type, source data, etc. See Wikipedia:WikiProject Geographical coordinates#Geo tag.

Example: {{coord|45.678|-123.456|type:lake_region:US-OR_scale:10000|display=inline,title|name=Somewhere in Oregon}} Naturally, backward support requires continuing to accept the plethora of parameters. I propose that only if coords= is given a value, the other parameters are ignored. —EncMstr (talk) 16:02, 28 July 2008 (UTC)[reply]

This seems redundant to what we already have. And keep in mind that through subtemplates, we already use {{coord}}. —MJCdetroit (yak) 12:46, 30 July 2008 (UTC)[reply]
While the template uses coord, it doesn't give access to its many capabilities: How would one specify the coordinate (45.123, -123.456)? (Conversion to DMS is required.) How about setting a map scale of 1:150000? Or, in an article named somewhere (qualifier1, qualifier2) make the point display on the map as somewhere (without the qualifiers)? —EncMstr (talk) 14:45, 30 July 2008 (UTC)[reply]
Decimal is not a problem: see Pie Town, New Mexico.
If you wish to have these features then the present subtemplates and/or the code need to be upgraded. I'm afraid that adding a second coord parameter will only confuse people. The subtemplate used here is {{Geobox coor}} and the code use here is:

(Removed code)

—MJCdetroit (yak) 16:26, 30 July 2008 (UTC).[reply]

In fact if you use the little known parameter of |coordinates_type=, I think you'll be able to do all that you want. See my last edit to Pie town. I'll update the doc page later. —MJCdetroit (yak) 17:27, 30 July 2008 (UTC)[reply]
I've updated the doc page, but we will have to deprecate the field named "coor_type", which has a slightly different function. Since that field seems to indicate exactly what/where the coords are pointing to, should we rename it something like "coor_info" or "coor_pinpoint"? Kotniski, what do you think? Do you have any better names? —MJCdetroit (yak) 16:53, 31 July 2008 (UTC)[reply]
"coor_pinpoint" sounds cool. I don't know if anyone else has used this parameter, but there are lots (thousands?) of instances on Polish municipality pages, so it will require botwork to make the conversion.--Kotniski (talk) 17:18, 31 July 2008 (UTC)[reply]
"coor_type is now "coor_pinpoint". I have a bot sweep through and change them at some point. —MJCdetroit (yak) 02:30, 2 August 2008 (UTC)[reply]
From my experience with other geo/info-box templates, coordinates_type= allows specifying the "coordinates" parameters (region:, type:, scale:, and source:, ...) but does not provide for specifying the Coord template's "template" paramters (display=inline,title, format=dms, name= ...) The "difficulty" arises from the latter being separated by "|" pipe/vertical-bar charaters, which creates syntax problems in trying to pass them. A workaround for name= is to append "&title=" to the end of the other coordinates parameters. But the Infobox Settlement template should provide additional coordinates_ fields for each of the Coord template parameters (display, format, ...) so that they can be controlled or specified). LeheckaG (talk) 12:59, 5 August 2008 (UTC)[reply]

(outdent) I got it to display in the title in the sandbox. Please see the Mexico city infobox in the Testcase page. Seemed small to me. But that is very doable. —MJCdetroit (yak) 16:40, 5 August 2008 (UTC)[reply]

An article's "title" bar coordinates are primarily for "computer programs" use rather than readability by people (so "small" is okay, you might look at some other template to see what they do with font/size). Coordinates within an Infobox are the ones which require easy readability by people.
Lately there has been a performance issue where coordinates without a "region:" specified result in ToolServer's geohack.php calling region.php to attempt to do a lookup to determine an appropriate region (for mapping services to know which sub-set of maps). When too many concurrent blank/empty region: occur it results in the "Fastcgi Protocol Error" message getting displayed instead of the GeoTemplate map selection page. So an ISO 3166-1 alpha-2 region: code should be supplied whenever it known. For instance region:US for the United States or region:US-XX where XX is the ISO 3166-2 code for a State or Territory (they are generally the same as 2-letter postal abbreviations in Canada and the U.S.) So normally, North American city coordinates would look like:
  • {{Coord|lat_d|lat_m|lat_s|N|lon_d|lon_m|lon_s|W|region:US-XX_type:city|name=name_of_city_if_different_than_article_title}}
I have not looked into Geobox coor(d) to see whether it has "standard" names for parameters; I recommend following whatever naming conventions {{Geobox}} and {{Coord}} use for parameters. For instance, Geobox sets the inline,title parameter by default and coordinates_no_title= turns title off.

LeheckaG (talk) 18:57, 5 August 2008 (UTC)[reply]

Request: area rank

Hello, I would like to request an additional field where I could input rankings by area (for example, note that administrative division ranks 5th by area in this or that country). Right now all area fields are auto-converted from km to mi. Renata (talk) 05:50, 30 July 2008 (UTC)[reply]

We discussed this once and concluded that such a field would either a) add too much clutter, or b) be potentially misleading, depending on how much information was shown. But you can use the area_footnotes field for such purposes (despite its name, it doesn't really produce footnotes).--Kotniski (talk) 08:08, 30 July 2008 (UTC)[reply]

GNIS identifier

I added a parameter to the template for Geographic Names Information System identifiers, and was subsequently reverted. Apparently, there's some concern as to whether or not this ought to be here. GNIS identifiers have already been added to the majority of US city articles via use of the "Blank" parameter. Since GNIS id's are also static, and provide a unique identifying number to geographic features in use by several agencies (such as the Census Bureau) having this field included in the infobox is immeasurably useful to automated tools such as bots. In the sake of transparency, my motivation was that I am running a bot that will use GNIS identifiers to circumvent problems with ambiguous names for the automatic updating of demographic information.

Anyway - I felt it was a fairly innocuous change, it only shows up in the infobox when the parameter is there (meaning there is no net effect on non-US articles). Given that there is no harm in adding this parameter and the utility of having a unique and easily accessible identifier for several thousands of articles I figured it would be uncontroversial. If anyone feels that this additional parameter is in any way detrimental or harmful to either the project or the readers, please explain. Shereth 23:18, 8 August 2008 (UTC)[reply]

Your addition seems sensible to me, but I recently proposed a parameter which could provide a way to decrease the number of parameters by 9 or so. That was opposed as "too complicated". —EncMstr (talk) 23:49, 8 August 2008 (UTC)[reply]
E, Did you actually read all of that #proposing coords parameter? It doesn't appear to be so because at no point did anyone oppose your proposal because it was "too complicated". The concern was that it was redundant to what we already have and it would not reduce anything because of how the location maps work. We have found ways to accommodate most of your request and were waiting for you to comment.
As for GNIS, my concern is that is it is too country specific (i.e., only the U.S. articles would use it). If we allow GNIS to have its own parameter, what's to say the Canadian, Mexican, Chinese, and all those other countries wouldn't argue for some country specific parameters or other U.S. parameters like the FIPS code? And adding extra parameters can slow down the performance of all the articles that use this template (75,000+) not just the U.S. ones. That was the reason for the "blank" parameters. In respect to a bot, why couldn't the bot be programed to look for "|blank1_name = [[Geographic Names Information System|GNIS]] feature ID" anyway? —MJCdetroit (yak) 15:26, 9 August 2008 (UTC)[reply]
Because "|blank1_name = " is nonstandard, and can be used for any information field. Yes, it would be fairly simple to program a bot to look for the data in that field but then we are assuming that article editors are going to put it there, as opposed to "|blank_name = ", or somewhere else. The idea is to have a reserved field for the data. FIPS55, the standard for places, is deprecated. Anyway, isn't worrying about what might happen in the future the wrong way to go about thing? It just sounds too much to me like you are willing to discard the known benefit for the sake of possible problems down the road. Besides, if the primary concern is being too country-specific it could be renamed to something generic like "|geo_id = " and then it can be used for GNIS, Geographical Names Board of Canada identifiers, or whatever Russian, Chinese, Mexican or whatever unique identifying system applies. Shereth 16:18, 9 August 2008 (UTC)[reply]
I would like to make several points:
  • "Codes" should provide readers with a "one-click link" to an appropriate authoritative/normative/primary reference page, and not be a cryptic one with no link or reference and therefore only understood by a few (the GR templates should be BANNED). For instance, any mention of a GNIS code should be: [{{Gnis3|gnis_feature_id}} gnis_feature_id] so that a reader can see what the code is, but also be able to click on it to go to the appropriate reference page. The same should be true of "Census FIPS 55" codes, etc. (but sadly, it is currently not).
  • There are other GNIS systems besides the (United States) USGS one, for instance British Columbia, Canada has one. So whatever fields and codes provided should indicate which and be "navigable" to the appropriate system. i.e. the field name should clearly navigate to the appropriate national or regional general system, while the code itself should unambiguously navigate to the appropriate specific reference page.
  • There is more than one type of GNIS "Feature Class" (for a "populated place"): Census, Civil, Locale, Populated Place, ... For coordinates and elevation, generally "Populated Place" or "Locale" should be used - it is where the USGS plots a name on maps. The Census and Civil codes should ONLY be used in-line within the context of discussing where the centroid of a U.S. Census statistical area or where the geographic center of incorporated boundaries are. The generally should NOT be used in place of a (geography) coordinates, location, ... for "Populated Place" or "Locale" in ANY infobox. Census or Civil code references are appropriate in a population section of an infobox or article, but not a general geography/location section.
  • My specific issue is having "Census borgs" update articles with nonsensical geographic information: often city or CDP coordinates "in the water" or "on top of a mountain". While the U.S. Census Bureau "might" be good at counting people, they apparently "failed" their geography lessons in several cases. Please leave geography updates to either other (typically local) Wiki projects which use USGS, NOAA or other authoritative geography and not "made up" US census stuff.
  • Census data should be centralized behind templates transcluded into articles, and there should not be bots running around and "willy nilly" editing articles - in particular, bots SHOULD NOT BE deleting or moving information into UNIMPLEMENTED fields - extremely "poor behavior" for a bot.
All that "ranting" said ... there should be a standardized reference id field to a government reference should for geography and there should likewise be one for population. While many governments might not have GIS (Geographic Information Systems) or other publicly-accessible database systems, there should be standardized fields for when they do. Such "code id" fields should be the primary index or key for retrieving such information, and any code or id provided should not just be "text" but rather a reference link to such information. i.e. there should be a one-click link to geography, population, climate, ... reference data provided. So, there should be a "general" GNIS or GIS or ... field and it should be usable across regions, "bots" should not be "inventing it", but rather it should be invented by proposal or consensus, then bots should follow "implemented" behavior rather than "inventing" things and "breaking" article pages by "deleting" or moving information. LeheckaG (talk) 05:34, 12 August 2008 (UTC)[reply]
Before you go shaking me down for "bad behavior", how about you stop making assumptions? I did not have any intent to run a bot that "invents" new behavior - I added (what I felt was) an uncontroversial parameter to the infobox and was using that. As soon as another editor expressed a concern (and reverted the addition) I immediately ceased operation of the bot. I take offense at the accusation of running about "willy nilly" and operating a bot with "poor behavior". Also, if you had bothered to do a little bit of background checking you would know that the bot is only changing places with a location type of "populated place" - it is not touching CDPs or any other type of location, and therefore it is not using what is, as you describe, "nonsense geography". As for your first suggestion, I was not aware of the {{gnis3}} template and I do appreciate your mentioning its utility in this situation - but the rest of your rant comes across as rather rude, condescending and ill-informed. Next time familiarize yourself with the situation better before you begin accusing other editors of exhibiting poor behavior and ignorance. Shereth 13:54, 12 August 2008 (UTC)[reply]

(outdent) Shereth, I'd favor some type of generic fields like "geo_id_type" and "geo_id_info". That way, it could be used by many countries—not just the U.S. It should go at the bottom near the postal code and area code fields. Also, the table on the doc page would need to be updated with a description of these new fields. —MJCdetroit (yak) 12:02, 12 August 2008 (UTC)[reply]

Okay, something like that would be extremely helpful, and I have absolutely no issues with a generic identifier field. Shereth 13:54, 12 August 2008 (UTC)[reply]
Yes, I understand from looking at the histories what the sequence of events was (that you started something which the template revert subsequently "broke" beyond your immediate control). "Bad behavior" is also having a bot which summarizes that it is updating "2007 census" but actually makes additional changes: rearranging GNIS fields. When I saw "2007 census" and "bot" on the watchlist, I "ignored" it; Later to find out that it shuffled the GNIS fields. The "willy nilly" was in reference to ArkyBot's edits' which "broke" some Infobox pages which contained a reference link rather than simply an ID number, so it was not in reference to your bots' editing "mistakes" and not you. I suspect, but I am not sure that it occurred on a few pages which otherwise had "harmless" typos (either added or missing "parenthetic" punctuation) which the bots' edits changed into more serious Wikitext syntax errors resulting in pages which visually did not display properly due to the subsequent Infobox "errors". I am not sure about the bots' "Populated Place" assertion: one of the unified-home rule city-boroughs, guessing either Sitka or Skagway, had a Census or Civil GNIS code and not the Populated Place one - which could have occurred after your bot passed by; subsequently I inserted the appropriate Populated Place reference link before the other code - i.e. the blank1 GNIS field now cites both codes. LeheckaG (talk) 14:47, 12 August 2008 (UTC)[reply]
The incorrect summary is my fault; I had implemented an updated summary but apparently forgot to save that revision, so I do apologize for that. In any case, for your reference the source I used for the GNIS parameter is the "Populated Places" gazetteer available from [1], so it should only be using populated places and not Census or Civil GNIS codes. Anyway, I am quite prepared to have the bot go back through the articles it has edited (Alaska and Arizona) and either revert the GNIS codes to the blank field, or to a new field, depending on the result of the discussion here. As always, there are potential problems that I cannot forsee in the coding (such as unexpected "parenthetic" punctuation) and I do appreciate when instances of unexpected behavior, "breaking" the infobox, come to my attention so I can make sure it doesn't happen subsequently. Shereth 15:09, 12 August 2008 (UTC)[reply]

Why should the "Populated Place" coordinates be used instead of the "Civil" coordinated for a city? To me, it makes much more sense to identify a city by its "Civil" center (centroid) rather than a seemingly arbitrary "Populated Place" (uncentered) coordinates. 68.41.144.239 (talk) 23:06, 26 August 2008 (UTC)[reply]

Any coordinates need to be used with "common sense", the USGS is generally the official source for most U.S. maps (NOAA geodetic survey, US Army Corps of Engineers, US Coast Guard, FAA, FCC, each having their own specialized maps), so USGS "Populated Place" coordinates are generally a reasonable representation of a population on a map. While the U.S. Census Bureau produces maps to attempt to explain where population counts and demographics come from, census borders are primarily supposed to follow election districting borders (which are often determined by "party politics"). The closest approximations to U.S. Census borders can be found at http://www.census.gov/geo/www/cob/, and they have several disclaimers regarding accuracy which along with some other maps can be found at http://www.census.gov/geo/www/maps/CP_MapProducts.htm. The "problem" with both municipal boundary and census tract geographic boundary centroids is that they often can be separate from where the "mean center of population is". Where population population densities are higher, and "evenly distributed", and boundaries are relatively rectangular, then the geographic boundary centroids work out somewhat better. "Problems" occur when the population densities are lower, or unevenly distributed, or irregular-shaped boundaries/tracts, then the centroids often end up in "odd" places away from the actual populated areas. In Alaska, the census areas and municipal boundaries are both relatively large, so the geographic area centroids often end up away from where the populated cities actually are ("in the water", or "on a mountain", ...). In Ohio, Municipal and census boundaries are "often" odd-shaped having been "carved out" by annexations and dissolutions of various municipal corporations (cities, townships, counties), the method the U.S. Census Bureau uses to compute the geographic centroid works okay for relatively smaller "rectangular" or square areas, and it does not work as well with the "more common" irregular tract shapes formed by cities, townships, counties, and census tracts. With GNIS Populated Places, Civil, Census, or Locale, ... coordinates, one should verify that the coordinates map to a "reasonable" location on a map, and should match what one is describing.
When one is using Census-derived data, a "better" answer is to review the actual census tract boundaries rather than "blindly" re-publishing census coordinates. LeheckaG (talk) 23:56, 26 August 2008 (UTC)[reply]

Multiple Pushpins?

Is it possible to have a map with multiple pushpins, each with their own coordinates? And furthermore, can the color of some be changed? As in having, say, 5 red pushpins and 3 blue ones on a map? Is that possible, and if yes, how? — N-true (talk) 10:55, 15 August 2008 (UTC)[reply]

Not within the infobox, but Template:location map+ does what you want. See Hertfordshire#Urban areas for an example. Kanguole (talk) 11:25, 15 August 2008 (UTC)[reply]
Using Location map+ and Location map~ you can also "dock" it to the bottom of an Infobox by creating a table (which would contain the Infobox and the Location map) and setting the same CSS classes on the table as the Infobox has (primarily class=Infobox). LeheckaG (talk) 19:02, 15 August 2008 (UTC)[reply]

Broken microformat

{{editprotected}}

Will somebody please reverse this edit which broke the hCard microformat. Thank you. Andy Mabbett | Talk to Andy Mabbett 22:39, 21 August 2008 (UTC)[reply]

What exactly is broken in the microformat? --Qyd (talk) 03:44, 22 August 2008 (UTC)[reply]
It includes three, separate addresses for the settlement, one of which is just a postcode. Andy Mabbett | Talk to Andy Mabbett 08:16, 22 August 2008 (UTC)[reply]
 Done Happy‑melon 14:36, 23 August 2008 (UTC)[reply]
Thank you. Andy Mabbett | Talk to Andy Mabbett 14:40, 23 August 2008 (UTC)[reply]
It includes three separate address elements. Why would that be wrong? Firefox operator extension is able to put the pieces together into one address entity (such as a ms outlook contact). --Qyd (talk) 14:55, 23 August 2008 (UTC)[reply]
It includes three separate address. ADR is defned as a plural property in hCard and vCard. Settlements have one address, not three. Andy Mabbett | Talk to Andy Mabbett 15:06, 23 August 2008 (UTC)[reply]
I'm afraid you interpreted the specifications wrongly. adr is "OPTIONAL, and MAY occur more than once". Attributes included in adr can be declared in different places inside the vcard, and parsers will be able to put them together. Only one address will be generated inside a vcard, and it will include all sub-attributes declared in distinct elements labeled as 'adr'. --Qyd (talk) 18:19, 24 August 2008 (UTC)[reply]
No, I have not interpreted the specification wrongly; and nothing in the part you cite contradicts what I have said. Of course ADR can occur more than once; because someone can have more than one address (their home, their workplace, their weekend cottage in the country, or wherever). But each occurrence is a different address. Please find us, if you can, the part of the specification which says that separate addresses are to be combined in the manner you imagine; and which says what should happen if one address had a country-name of, say, England, another of Brazil. Andy Mabbett | Talk to Andy Mabbett 18:27, 24 August 2008 (UTC)[reply]
Each occurrence is not a different address. While the documentation is not specific about that, the behavior of any vcard content extractor is very clear: only one address is generated per vcard, and distinct elements (inside a vcard, but in separate adr elements) are merged. Duplicate fields are replaced by the last declaration (as it happens with most html declarations). Please try Firefox operator in User:Qyd/Temp and see what happens, or try the external http://suda.co.uk/projects/microformats/hcard/get-contact.php?uri=http://en.wikipedia.org/wiki/User:Qyd/Temp to see the effect. --Qyd (talk) 01:58, 27 August 2008 (UTC)[reply]
Do you understand the difference between an authoritative or normative SPECIFICATION and a "broken" implementation? There are other implementations besides the Operator extension, which behave differently. Please see: http://microformats.org/wiki/hcard#Property List, specifically:
adr (post-office-box, extended-address, street-address, locality, region, postal-code, country-name, type, value), label
...
adr tel email types
The following lists are informative. See RFC2426 sections 3.2.1 ADR, 3.3.1 TEL, and 3.3.2 EMAIL respectively for normative type values.
They are repeated here for convenience.
Default type subproperty value(s) is(are) first in each list and indicated in ALL CAPS. types may be multivalued.
*adr type: INTL, POSTAL, PARCEL, WORK, dom, home, pref

which says that multiple INTL, POSTAL, PARCEL and WORK addresses can be included in a hCard/vCard, along with only one dom, home, and pref address. i.e. an organization or person has only ONE "home" address and they have only ONE "preferred" address, and the home address can be different than the preferred address.

and http://microformats.org/wiki/hcard-profile which says: 

   <dt>adr</dt>
    <dd>See section 3.2.1 of RFC 2426.</dd>"

and http://microformats.org/wiki/adr which says: 

adr (pronounced "adder"; FAQ: "why 'adr'?") is a simple format for marking up address information,
suitable for embedding in HTML, XHTML, Atom, RSS, and arbitrary XML.
adr is a 1:1 representation of the adr property in the vCard standard (RFC2426 (http://www.ietf.org/rfc/rfc2426.txt)) in HTML,
one of several open microformat standards. It is also a property of hCard.

Which say that RFC 2426 is the standard on which hCard/vCard adr is based (1:1 representation) ...

http://www.ietf.org/rfc/rfc2426.txt goes on to say: 

3.2.1 ADR Type Definition
...
   Type special notes: The structured type value consists of a sequence
   of address components. The component values MUST be specified in
   their corresponding position. The structured type value corresponds,
   in sequence, to the post office box; the extended address; the street
   address; the locality (e.g., city); the region (e.g., state or
   province); the postal code; the country name. When a component value
   is missing, the associated component separator MUST still be
   specified.
...
   The TYPE parameter values can include "dom" to
   indicate a domestic delivery address; "intl" to indicate an
   international delivery address; "postal" to indicate a postal
   delivery address; "parcel" to indicate a parcel delivery address;
   "home" to indicate a delivery address for a residence; "work" to
   indicate delivery address for a place of work; and "pref" to indicate
   the preferred delivery address when more than one address is
   specified.
...
   This type is based on semantics of the
   X.520 geographical and postal addressing attributes.
...

NOTE: specifically "WHEN MORE THAN ONE ADDRESS IS SPECIFIED", and while HTML/XML microformat tagging permits omitting blank or empty components, The REQUIREMENT that EACH AND EVERY ADR be composed of: (post office box, extended address, street address, city/locality, province/region/state, postal code, country) has NOT changed.

Personally, I do not feel that adr microformat fields should be rearranged from their X.520 or RFC 2426 semantic order or sequence, but I am not going to argue that semantic point here, and for parsing purposes: an adr microformat reader "could" rearrange adr tagged fields "back into the appropriate order or sequence"; my point would be that they normally should be in the appropriate (X.520/RFC 2426) sequence unless there is a good technical reason not to.

So:

  • adr (post-office-box, extended-address, street-address, locality, region, postal-code, country-name)

is properly formed.

  • Whereas adr( region ), adr( postal-code ), adr (country-name) are all MALFORMED;

and hCard/vCard permits including or specifying more than one address, like: 

vcard( fn org()
 adr (post-office-box, extended-address, street-address, locality, region, postal-code, country-name, home)
 adr (post-office-box, extended-address, street-address, locality, region, postal-code, country-name, work)
)

NOTE: types like home or work are coded as: 

Either:
< ... class="type">home</ ...>
or
< ... class="type">work</ ...>

within the corresponding < ... class="adr"> ... </ ...>

Flat-out:

  • vcard( fn org() adr( a b c ) ) is correct usage
  • whereas vcard( fn org() adr(a) adr(b) adr(c) ) in INCORRECT usage (where a b c are "components" of ONE address),
  • and vcard( fn org() adr( a1 b1 c1 ) adr( a2 b2 c2 ) ... ) is permissible (i.e. multiple addresses),
where a1 b1 c1 are components of the 1st address, and a2 b2 c2 are components of a 2nd address, ...

LeheckaG (talk) 06:43, 27 August 2008 (UTC)[reply]

So when more then one address is specified, type must be defined, and that's how parsers detect different addresses inside a vcard. Now if they're defined in more then one place, they would still be recognized (the codes "vcard( fn org() adr1( a1 b1 c1 ) adr2( a2 b2 c2 )" would generate the same microformats as " vcard( fn org() adr1( a1 b1) adr2(b2 c2 ) adr1( c1) adr2( a2)" ). One of the examples I've given comes from one of the microformat developers site, and it does merge split declarations. Can you please find any kind of error message or a "broken" extracted microformat to go with your theory? If not, than please acknowledge that the lengthily text above is just your interpretation. --Qyd (talk) 13:45, 31 August 2008 (UTC)[reply]
So when more then one address is specified, type must be defined - No. Where in the specification do you think that is mandated? Andy Mabbett | Talk to Andy Mabbett 14:22, 31 August 2008 (UTC)[reply]
That's what LeheckaG says above. I agree with that, it's similar to the "tel" class. Otherwise there's no way in hell it would work. If you know otherwise, please provide example. Thanks. --Qyd (talk) 21:10, 1 September 2008 (UTC)[reply]
No. If you think that's required, please point to the relevant part of the specification; as I have already asked you to do. I cannot prove a negative. Andy Mabbett | Talk to Andy Mabbett 21:23, 1 September 2008 (UTC)[reply]
You still haven't provided any example of what you called broken microformat (other than theoretical speculation), any kind of error message, I'm asking you to give any kind of prove that it was broken. I don't want to play this silly game, I'm just sorry that the possibilities offered by microformats are not fully implemented because of someone stubborn like you. Too bad. Peace out. --Qyd (talk) 04:25, 3 September 2008 (UTC)[reply]
I take it from your aggressive tone that you can't find support for your position in the ADR microformat spec. Andy Mabbett (aka Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 08:17, 3 September 2008 (UTC)[reply]

Other issues

Yes. 1 of the few or several? "problems" is that class="adr" should "div" or "span": (country-name, region, and postal-code); rather than being applied separately to each "adr" component. See below (copy and pasted from edit conflict warning):
Talk about "... opening a can of worms ..."; I had wondered about the <th class="adr"> ... <span class="country-name"> ... <span class="region"> ... <span "class="postal-code"> edit when I saw it on my watchlist. <span class="region"> had caught my attention, and when I had previously researched it, I could not find "region" in MediaWiki:common.css nor MediaWiki:Monobook.css. So initially, I believed what was "broken" is that the Cascading StyleSheet (CSS) class "region" does not exist for at least most English Wikipedia users with "default" (Monobook.css) preferences. I do not know if any of those CSS classes might exist in any of the other Wiki "Skins"?
Specifically, see Wikipedia:Skin, Help:Cascading style sheets, and Wikipedia:Catalogue of CSS classes
The claim is that the English Wikipedia uses these .css files in this cascade order:
I only searched for (CSS class) "region", which I did not find in any of those CSS (Cascading Style Sheet) files.
a "View, Page Source" in a web browser roughly confirms use of those Cascading Style Sheets, but apparently there are other undocumented ones as well.
http://www.ietf.org/rfc/rfc2426.txt is the authoritative/normative reference standard on which microformats are based; microformats are a 1:1 mapping between the RFC 2426 vCard MIMI profile or structure and the corresponding XML/CSS markup, see: http://microformats.org/wiki/hcard-profile which specifies the hcard/vcard mapping; although some microformats may have diverged in actual practice a little bit since (although they probably should not have).
XML Microformat markups say to use < ... class="">, but then they do not go on to say strongly enough that the shared Cascading Style Sheets (CSS) should be updated with the appropriate class(es) to support those corresponding microformats. Nor do they go on to caution strongly enough about the appropriate "nesting" structure of the microformats. Although <... class="non-implemented-class"> might work, good coding practice is that the corresponding Cascading Style Sheet should be updated to indicate the use of the class, even if it is just with a "blank placeholder". Also generally, classes should NOT be concatenated, i.e. each microformat < ... class="tag"> should NOT be merged into < ... class="tag1 tag2 tag3">. < ... class="fn"> is the 1? notable exception where classes/tags such as < ... class="fn org"> is valid.
So "vcard" should stand as its own outer envelope < ... class="vcard">, rather than being merged with other < ... class="tag1 tag2 tag3">.
So the 1st. "obvious" thing which I see is that < ... class="adr"> should NOT be applied separately on "country-name", "region", and "postal-code". Rather < ... class="adr"> should be an outer "envelope" or "container" encompassing the address's inner components.
Per http://microformats.org/wiki/adr, Within < ... class="adr">, permitted "types" are: post-office-box, extended-address, street-address, locality, region, postal-code, country-name.
Note that a "raw" adr is "out of context", for example saying "42" here would mean? Whereas saying it in the context of "Hitchhiker's Guide to the Galaxy" would mean something totally different than saying "42" in many other contexts. So an "adr" must or should be contained within another microformat like http://microformats.org/wiki/hcard (a.k.a. class="vcard" ... class="fn org" ...) for which it is the address of.
Similarly, within a microformat < ... class="type"> container or envelope, EVERYTHING should be appropriately structured and tagged, so fields which are NOT appropriate to the microformat either need to outside of such microformat containers or envelopes or they need to be tagged with appropriate tags which effectively "comment them out" for the microformat purposes, while still having their normal effect(s) otherwise. RFC 2426 vcard specifies a "NOTE", for which there does not appear to be a conflicting class in MediaWiki:Common.css or MediaWiki:Monobook.css. So a < ... class="note"> could be used to effectively "comment out" other XML components (while they still retain their original effect) when they are not really a component of the corresponding microformat. Class "note" should be added to either MediaWiki:Common.css or MediaWiki:Monobook.css to "document" and "placemark" it so that it is used appropriately and not subsequently used to do something else.
A "problem" which < ... class="adr"> "creates" is that the corresponding Infobox fields should be reorganized so that the "adr" component fields are within the corresponding < ... class="adr"> container or envelope.
So either: MediaWiki:Common.css or the corresponding skins (Monobook.css, ...) should be updated with the appropriate CSS code to document or implement those classes, even if they are blank/empty.
And < ... class="adr"> should be moved so that while it is still within << ... class="vcard"> and < ... class=fn org">; that ... class="adr" ... is a container or envelope surrounding < ... class="country-name" ... class="region" ... class="postal code">.

LeheckaG (talk) 10:43, 22 August 2008 (UTC)[reply]

With regard to "reversing" or "reverting" the edit originally cited which "broke" the "vcard"-"fn org" Micro-format. In my opinion, it should not be reverted, but rather appropriately updated so that < ... class="adr"> encompasses the corresponding adr sub-fields collectively rather than individually. LeheckaG (talk) 10:50, 22 August 2008 (UTC)[reply]
Sadly, that doesn't seem to be possible, with current methods of template construction. Andy Mabbett | Talk to Andy Mabbett 11:11, 22 August 2008 (UTC)[reply]
Huh? it means reorganizing the "adr"-related (country-name, region, and postal-code) fields so that they are adjacent to each other rather then spread out in the Infobox, and then placing the class="adr" so that it is a container around the block. If it is an "address", then it should "look like an address", i.e. adr(name, street, city, state, county) which means rearranging the Infobox fields.
You unfortunately make some fundamentally wrong assumptions about microformats, and HTML in general. In HTML, classes may legitimately be used, without reference to stylesheets. That said, it may be worth adding the relevant classes (more listed in {{UF-hcard-geo}} and {{UF-hcard-person}}) to the relevant CSS files; even if only in a comment. I see no reason why VCARD should not be on the same level as other classes, nor why classes should not be concatenated on a single element in general - that's perfectly acceptable and valid mark-up; it avoids bloat (or "DIV-itis"). There is no requirement, in microformats, to "comment out" other data; anything not explicitly encoded in a child-class is ignored; using class="note" would INCLUDE that data in the microformat. ADR microformats need not be contained within another microformat (though often are); but should only be used to mark up addresses, not other data. (This discussion might be better placed on {{ProjectMicroformats}}; which you're welcome to join.) None of this affects the above "editprotected" request. Andy Mabbett | Talk to Andy Mabbett 11:26, 22 August 2008 (UTC)[reply]
Not exactly. Yes, one can use class="undefined-style", but that is generally not a good idea, and while HTML/XML class style rules can be added or defined outside of stylesheets like on "normal" HMTL/XML pages (outside of Wiki), it was my understanding that the WikiText parser does not let a contributor add or define a CSS style rule: tag.name { property: value } outside of the appropriate User:*.css stylesheets? So that on Wiki, CSS styles should be added on the MediaWiki:Common.css or appropriate skin MediaWiki:Monobook.css. Is that not true about WikiText? or can Wiki Article, Template:, Project, or User: pages include page-specific CSS style rules (i.e. defined on the article page rather than on a separate common stylesheet)? If that is indeed possible, then the Infobox Settlement template could or should "self-defined" those microformat CSS style rules which are not defined elsewhere which it uses at the beginning of the template.
The "problem" which I see with the classes used as microformat tags not being listed on MediaWiki:Common.css is that someone could come along later and add a shared CSS style rule with any of those names, possible causing "unfortunate" side effects or page rendering - which is why style classes used as common microformat tags should be centrally defined on Wiki.
Microformats have a "structure to them". adr(country-name), adr(region), adr(postal-code) means something different than adr(country-name, region, postal-code).
Yes, [http://microformats.org/wiki/hcard-parsing] allows for a microformat's root element (like hcard's class="vcard" to be concatenated along with other CSS classes.
Elsewhere they do not clearly indicate whether subsidiary components within vcard can be concatenated or not, although none of the examples show concatenation of other tags [http://microformats.org/wiki/hcard-examples-rfc2426] and the DTD [http://microformats.org/wiki/hcard-profile] indicated them as separate, nor does the microformat parsing description discuss concatenated non-root tags other than "fn".
there is considerable discussion regarding the "fn" element (fn n, fn org, ...) which generally seems to indicated not.
Any markup divisions should reflect the semantics, like: "correct" vcard( fn org( adr(a, b, c) ) ) versus "probably incorrect" vcard( fn org( adr(a) adr(b) adr(c) ) ); or "definitely incorrect": vcard( fn org( ) adr(a) adr(b) adr(c) ) or likewise incorrect vcard( ) fn org( ) adr(a) adr(b) adr(c)

LeheckaG (talk) 16:57, 22 August 2008 (UTC)[reply]

I would like to understand if I missed something regarding Help:HTML in wikitext and <style type="text/css"> tag.name { property: value ; ... } </style> rules on a WikiText HTML/XML page rather than in a separate Wiki stylesheet (WikiMedia:Common.css, WikiMedia:Monobook.css and the other Wiki "Skins", User:*.css), but from my quick "SandBox" testing, it appears that WikiText behavior matches the HTML in WikiText documentation, and ignores the <style type="text/css"> and </style> HTML/XML tags, so am I missing something? LeheckaG (talk) 21:18, 22 August 2008 (UTC)[reply]
I'm not sure what you're asking, but I think you need to ask on a more appropriate talk page. Andy Mabbett | Talk to Andy Mabbett 21:27, 22 August 2008 (UTC)[reply]
YOU said "... fundamentally wrong assumptions ..." so what exactly are you referring to? When I make a mistake, I prefer to understand what it is. As it currently stands, either the adr, country-name, region, and postal code update should be reverted as someone else originally requested; or the template should be updated so that the "adr"-related fields are re-grouped together in the proper order ...

(as far as I know "English": US, Canada, England, Australia, ... addresses are in that order and grouping - versus some non-English addresses which flow in the opposite direction, like Russia) 

<span class="adr">
{{#if:{{{subdivision_type1|}}}|
	<tr class="mergedrow">
		<th>{{{subdivision_type1}}}
                <th><span class="region">{{{subdivision_name1}}}</span>
	</tr>
<!-- ***** Subdivisions ***** -->
{{#if:{{{subdivision_type|}}}|
	<tr class="mergedtoprow">
		<th>{{{subdivision_type}}}
                <th><span class="country-name">{{{subdivision_name}}}</span>
	</tr>
<!-- ***** Postal Code(s) ***** -->
{{#if:{{{postal_code_type|}}}|
	<tr class="mergedtoprow">
                <th>{{{postal_code_type}}}</th>
                <td><span class="postal-code">{{{postal_code}}}</span>
	</tr>
</span>

I know that there is more to it than that (that there are other adr-related fields, and re-ordering visibly displayed fields in a protected Infobox is a change which requires consensus). So for now those "adr" changes should probably be reverted until it can be done a better way, the multiple separate "adr" is definitely broken. LeheckaG (talk) 22:16, 22 August 2008 (UTC)[reply]

Nobody is asking for " re-ordering visibly displayed fields". The "regrouping" you propose is not possible, as I have already said - and you cannot wrap a span around multiple table rows. I addressed your "fundamentally wrong assumptions", but this is not an appropriate place to discuss them, as they are either not specific to, or mostly not relevant to, this template. Andy Mabbett | Talk to Andy Mabbett 22:34, 22 August 2008 (UTC)[reply]
What was asked for was fixing the "3" address problem (each with only a piece of the address) with a proper adr microformat which implies vcard( fn org( adr(region, country-name, postal-code) ) ) rather than the "3 address": adr(region), adr(country-name), adr(postal-code). Actually the re-grouping is possible, yes, while WikiText parsing and re-writing of HTML/XML breaks "span" when it encounters certain table elements, what does work is re-grouping those adr-related rows together and splitting them into either a separate or nested table and placing a div or similar around that:

either: 

<table>
 ... top of table ...
</table>
<div class="adr">
 <table>
  ... relevant rows ...
 </table>
</div>
<table>
 ... bottom of table ...
</table>

or 

<table>
 ... top of table ...
 <div class="adr">
  <table> <!-- nested table -->
   ... relevant rows ...
  </table> <!-- end of nested table -->
 </div>
 ... bottom of table ...
</table>

and yes, I understand that WikiText parsing and re-writing of the latter actually breaks out the div and nested table, effectively creating something similar to the table - table - table layout above rather than remaining nested.

"Think outside of the box" and no you did not say what is wrong, just that you are apprarently either unwilling or technically incapable of fixing the issue, while there "always" is some way, I understand that WikiText might not make some things easy and has more restrictions than "normal" HTML/XML. LeheckaG (talk) 01:34, 23 August 2008 (UTC)[reply]

With regard to an adr microformat being used stand-alone, while Wikipedia "informative" HCard says "The adr part of hCard can also be used as a stand-alone microformat.", the actual adr microformat authoritative/normative specification http://microformats.org/wiki/adr says "If the publisher knows and is publishing the name of the location in addition to its address, then the publisher MUST use hCard instead of just adr to publish the name and address of the location." Note the "MUST" which means that in most cases hCard (a.k.a. vcard) MUST be used instead of a stand-alone adr unless you somehow have an address but have no clue as to what it is the address of? LeheckaG (talk) 02:08, 23 August 2008 (UTC)[reply]

Garbled display

Could someone take a look at the implementation of the template in the Bajaur article? __meco (talk) 21:47, 1 September 2008 (UTC)[reply]

I tweaked it a little. —MJCdetroit (yak) 03:04, 2 September 2008 (UTC)[reply]
Appreciated! __meco (talk) 07:27, 2 September 2008 (UTC)[reply]

Placebox templates

The Placebox template series (see also Argentina-related regional notice board/Placebox) would seem redundant to this template, though conversion of individual instances might be a job for a bot. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:14, 9 September 2008 (UTC)[reply]

Infobox code ruins output of Template:Fact

A source request for the population parameter had to be temporarily removed from the infobox at Lillestrøm as the article was categorized into Category:Articles with unsourced statements since May 2,008. I made an inquiry at the Village pump (technical) that identified the problem. It remains however unsolved. __meco (talk) 18:11, 12 September 2008 (UTC)[reply]

Population parameters can be used in calculations. Therefore, it (like the the population density, area, and elevation fields) is for raw unformatted numbers only. I placed the fact tag in the population_footnotes field and someone else placed the fag tag in <!-- --> an editor comment on the population parameter line. —MJCdetroit (yak) 20:35, 12 September 2008 (UTC)[reply]
Could this technical issue be made known to users of the template in some fashion? __meco (talk) 07:38, 17 September 2008 (UTC)[reply]

Redundant Infoboxes

http://en.wikipedia.org/w/index.php?title=Category:Country_subdivision_infobox_templates&diff=238794261&oldid=204943009 ... bots could convert them. TopoCode-blockedbyEdJohnston (talk) 06:32, 17 September 2008 (UTC)[reply]

The problem with that is that the people who have created and maintaned the other infoboxes often don't want their work to become deprecated. There is currently no policy to force Infobox Settlement to be used instead of other infoboxes, so a switch has to be made voluntarily in each instance. __meco (talk) 07:35, 17 September 2008 (UTC)[reply]

Coordinates: type:city(#) and population_total

The coordinates' type:city (see WP:GEO#Type:t) for settlement allows to specific the population of a settlement. This is used to define the scale for maps.

Including the field "population_total" into the coordinates link would provide such information (e.g. [2]. As sometimes "population_total" includes non-numeric data, this is breaks the coordinates though. Either the field population_total needs to be standarized to numeric values (removing multiple numbers, ranks, sources, estimates or simply spaces and points used instead of commas) or the population_total needs to be checked for numeric values first. -- User:Docu

IW

please add Interwiki for Bahasa Indonesia's wikipedia. It's has the same name of article. Albert (talk) 10:45, 19 September 2008 (UTC)[reply]

Demonym – part 2

There was some previous discussion about adding a demonym parameter. The documentation lists population_demonym but then under usage it states in red: "Not currently available". Is anyone working on this? __meco (talk) 08:45, 25 September 2008 (UTC)[reply]

What is a settlement?

It would be a good idea if the lede of this template's documentation said what is meant by "settlement" - in particular, how large does it go? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:01, 28 September 2008 (UTC)[reply]

Villages, towns, cities - no limit; it's not even limited to settlements (it can be used successfully for districts and regions as well). I've updated the documentation to that effect.--Kotniski (talk) 08:50, 29 September 2008 (UTC)[reply]
Thanks - I've added a note that it's for anything less than a country; since that was the point on which I was originally not clear; plus a link to {{Infobox Country}}. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:42, 29 September 2008 (UTC)[reply]

Merging properties from Subdivisions of Malaysia

I have nominated {{Subdivisions of Malaysia}} for deletion as redundant to this template, but it has been pointed out that the Malaysian template has these properties:

  • State anthems (under "anthem").
  • Ruling party and history of the states' sovereignty (under "ruling_party" and "sovereignty_type"; These fields could be integrated into the "Politics" and "History" sections}
  • License plate prefixes (under "license_plate").

What do people think about adding them to Infobox Settlement? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:26, 29 September 2008 (UTC)[reply]

Allow me to compare the TfD-ed state template and {{Infobox Settlement}} as they may when summarising the state of Malacca in a sandbox. The fields were migrated into respectable areas of {{Infobox Settlement}}, but the result is not very satisfactory. My comments have been included in the raw code of the {{Infobox Settlement}} infobox, But I'll duplicate them here:
  • "Name and motto" section
    • There is no support for state anthems, while the original template allows the anthem to be placed underneath the motto.
  • "Location, subdivisions, government and established information" section
    • There is no fields for capitals cities. Certain Malaysian states are known to have both a basic state capital and a royal state capital. The fact that this template is city-centric may be the reason for the lack of such fields.
    • "established_title" fields are limited to only four entries, cutting off from "established_date3" onwards. In addition, there is no "History" heading, which is more relevant for topics like this. Recommendation: Expand it to support up to 10 fields; include optional history heading.
    • In certain cases, states have more than two heads nominated by political parties. {{Infobox Settlement}}, however, only supports one field on a head's affliated party. In addition, there are no ruling party fields.
  • "Other informations" section
    • "area_code" in the does not support custom links. Recommendation: Include "area_code_type" field similar to "postal_code_type"
- Two hundred percent (talk) 16:26, 30 September 2008 (UTC)[reply]
In the meantime, I'll also be looking up the districts section to see if anything else is left out. - Two hundred percent (talk) 16:28, 30 September 2008 (UTC)[reply]
The district template has been examined. See the same sandbox for (hidden) comments. - Two hundred percent (talk) 17:32, 1 October 2008 (UTC)[reply]

Copyable blank

I've added a copyable blank to the documentation; please check it, and add anything I missed. Thank you.Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:36, 30 September 2008 (UTC)[reply]

I think this just duplicates the empty syntax that already exists (maybe you didn't notice it because it's hidden - perhaps that means attention ought to be drawn to it better).--Kotniski (talk) 12:49, 30 September 2008 (UTC)[reply]
I didn't notice because not only is it hidden, but it's impossible to reveal it when, like I do, one surfs with Javascript disabled. That's a clear breach of priority-1 web accessibility guideline 6.3]. I've fixed that by unhiding them. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:13, 30 September 2008 (UTC)[reply]

Saket Nagar Bhopal ‎

Could someone please check my use of this template on Saket Nagar Bhopal. Some of the fields (postal code, for example) are not showing, Thank you. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:55, 30 September 2008 (UTC)[reply]

Native name langugae

This template already has a native_name parameter. I think it should also have a native_name_lang parameter, to take the relevant ISO639 language code and should display the native name, where present, by replacing the current code:

<span class="nickname">{{{native_name}}}</span>}}

with:

<span class="nickname"{{#if:{{{native_name_lang|}}} lang="{{{native_name_lang}}}"}}>{{{native_name}}}</span>}} (see below)

Is everyone happy with that? If so, I'll request an {{editprotected}} Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:08, 30 September 2008 (UTC)[reply]

No objections; so I have done so. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:05, 3 October 2008 (UTC)[reply]
I think your code is missing a vertical bar. --MZMcBride (talk) 18:08, 3 October 2008 (UTC)[reply]
Thank you, but at which point? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:15, 3 October 2008 (UTC)[reply]
Correction: :<span class="nickname"{{#if:{{{native_name_lang|}}}| lang="{{{native_name_lang}}}"}}>{{{native_name}}}</span>}}. —Ms2ger (talk) 18:59, 3 October 2008 (UTC)[reply]
Thank you. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:08, 3 October 2008 (UTC)[reply]

(←) Should this include xml:lang="{{{native_name_lang}}}" as well to match the span generated by {{lang}} (or alternatively use that template)? mattbr 20:05, 6 October 2008 (UTC)[reply]

Can you please create a template sandbox for an admin with the required change so that we can just copy-paste it from one into the other? I am not confident of editing the right line here. Stifle (talk) 10:05, 7 October 2008 (UTC)[reply]
Done: Template:Infobox Settlement/sandbox. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:24, 7 October 2008 (UTC)[reply]

Population census year

Just a small quibble, but when you include a census year on population data in this template, it adds a comma to the year. (e.g. 2,008 instead of just 2008) See examples at Cusco, Iquique. Is there any way to prevent this from occurring? I can understand the comma being added for the population value itself, but the year shouldn't have a comma in it. Lurlock (talk) 19:35, 30 September 2008 (UTC)[reply]

Use population_footnotes = 2007 instead of adding the year at the end of population_total. older ≠ wiser 21:38, 30 September 2008 (UTC)[reply]
ITYM population_as_of = 2007. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:01, 30 September 2008 (UTC)[reply]
Okay, thanks. (I created the Iquique infobox by copying the one at Cusco - which included the improper use of the template. Probably would've gotten it right if I'd picked any other city...) Lurlock (talk) 14:25, 1 October 2008 (UTC)[reply]

Named for

{{editprotected}}

After expanding Cass City, Michigan, I noticed that the named_for label is one of the few in its group that isn't wikilinked. Since Namesake would be entirely appropriate, please change the named_for label to "Named for"...Thanks. 68.167.254.198 (talk) 09:20, 1 October 2008 (UTC).[reply]

Done. Cheers. --MZMcBride (talk) 19:39, 1 October 2008 (UTC)[reply]


USDA Hardiness zone

Any objections to adding a field for hardiness zone, using the more-detailed a/b system and the most recently-published map (1990)? I would find this very useful, as would anyone else interested in gardening (hundreds of thousands of Wikipedians, I presume). How is this template edited - all I get is a "view source" tab-button? Nuberger13 (talk) 01:33, 2 October 2008 (UTC)[reply]

Unless the code is somehow subtemplated, it can only take so many fields in its present state. Please use the "blank" fields for this type of info.
Because this template is used on more than 80,000 pages, it is fully protected and can only be edited by submitting requests on this talk and having an administrator do the editing. —MJCdetroit (yak) 12:55, 3 October 2008 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Infobox_settlement&oldid=243623536"