Static Wikipedia February 2008 (no images)

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - en - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu

Web Analytics
Cookie Policy Terms and Conditions Template talk:Infobox City - Wikipedia, the free encyclopedia

Template talk:Infobox City

From Wikipedia, the free encyclopedia

[edit] Usage Example

from San Jose, California--Note Pipe characters are in front of the line of cell data, instead of at the end of the line, which makes it easier to include both sq km and sq mi for area cells (as well as simplifying the spacing):

<!-- Infobox begins -->{{Infobox City
|official_name          = City of San José
|native_name            = 
|nickname               = Capital of Silicon Valley
|motto                  = 
|image_skyline          = SJPan.jpg
|imagesize              = 
|image_caption          = 
|image_flag             = Us-ca-sj.gif
|image_seal             = Sj city seal.jpg
|image_shield           = 
|image_map              = SanJoseMapWithLAFCOandCityLabelsandCA.png
|mapsize                = 
|map_caption            = Location of San Jose within [[Santa Clara County, California]].
|pushpin_map            = 
|pushpin_label_position =
|subdivision_type       = [[Countries of the world|Country]]
|subdivision_name       = [[United States of America]]
|subdivision_type1      = [[Political divisions of the United States|State]]
|subdivision_name1      = [[California]]
|subdivision_type2      = [[List of counties in California|County]]
|subdivision_name2      = [[Santa Clara County, California|Santa Clara]]
|government_type        = [[Council-manager government|Council-Manager]]
|leader_title           = [[Mayor]]
|leader_name            = [[Ron Gonzales]]
|leader_title1          = [[City manager]]
|leader_name1           = [[Les White]]
|leader_title2          =
|leader_name2           =
|leader_title3          =
|leader_name3           = 
|established_title      = [[Settled]]
|established_date       = [[1770]]
|established_title2     = [[Municipal corporation|Incorporated]]
|established_date2      = [[March 27]], [[1850]]
|established_title3     = 
|established_date3      = 
|area_footnotes         = <ref>[http://www.census.gov/geo/www/ua/ua2k.txt US Census Bureau Lists of Urbanized Areas]</ref>
|area_magnitude         = 1 E8
|area_total             = 461.5
|TotalArea_sq_mi        = 178.2
|area_land              = 452.9
|LandArea_sq_mi         = 174.9
|area_water             = 8.6
|WaterArea_sq_mi        = 3.3
|area_water_percent     = 
|area_urban             = 673.68
|UrbanArea_sq_mi        = 260.11
|area_metro             =
|MetroArea_sq_mi        =
|population_as_of       = 2006
|population_footnotes   = <ref>[http://www.sanjoseca.gov/planning/data/population/ City of San Jose Planning:Maps/Data]</ref>
|population_note        = 
|population_total       = 953679 <!--Note: use population_footnotes for refs, use only unformatted numbers here -->
|population_density     = 1976.1<!--Note: use population_footnotes for refs, use only unformatted numbers here -->
|population_density_mi2 = 5118.1<!--Note: use population_footnotes for refs, use only unformatted numbers here -->
|population_metro       = 1741431<!--Note: use population_footnotes for refs, use only unformatted numbers here -->
|population_density_metro_km2 =
|population_density_metro_mi2 =
|population_urban       = 1611000<!--Note: use population_footnotes for refs, use only unformatted numbers here -->
|timezone               = [[Pacific Time Zone|PST]]
|utc_offset             = -8
|timezone_DST           = PDT
|utc_offset_DST         = -7 
|latd                   = 37 
|latm                   = 18 
|lats                   = 15 
|latNS                  = N 
|longd                  = 121 
|longm                  = 52 
|longs                  = 22 
|longEW                 = W 
|elevation_footnotes =<ref name=elevation>{{cite web |url=http://geonames.usgs.gov/pls/gnispublic/f?p=121:3:164536441437870960::NO::P3_FID:1654952 |title=USGS—San Jose, California |accessdate=2007-02-17 }}</ref>
|elevation              = 26
|elevation_ft           = 85
|postal_code_type       = ZIP codes
|postal_code            = 95110–95139
|website                = [http://www.sanjoseca.gov www.sanjoseca.gov]
|footnotes              = 
}} <!-- Infobox ends -->

List of articles using this template


Archive
Archives
  1. March 2005 – May 2006
  2. June 2006 – July 2006

Contents


[edit] Discussion

[edit] Established Title/Date

How are the "established_title2", "established_date2" etc fields supposed to be used? Could someone give an example? -- SatyrTN 16:57, 7 August 2006 (UTC)

They could be used for places where there is a "Founded" date as well as an "Incorporated" date (like at Albany, New York). This could already be done using "<br>" tags, however, so I'm not sure if this makes the template any better. --MattWright (talk) 17:14, 7 August 2006 (UTC)
It makes it better by fixing the way in which a screen reader (something a blind person would use) interpets the rows. My understanding is that a screen reader will not correctly read the order of the rows when using the "<br>" tags. Doing the separate fields method would correct this and not affect the way in which you or I see the infobox. See Accessibility issues above. --MJCdetroit 17:34, 7 August 2006 (UTC)
Sounds good to me -- it also ensures that the fields line up properly in some situations. --MattWright (talk) 17:44, 7 August 2006 (UTC)
Gotcha - Thanks! SatyrTN
Yes, I added these for when I redid the Westfield, MA infobox. I found that the date that it was incorporated a town and the date it was settled was just as important as the city's incorporation. And its extra syntax that doesn't hurt to be there. I think it could be helpful to other articles as well, which is why I didn't use the <br> tags. JARED(t)  02:44, 8 August 2006 (UTC)

[edit] Postal code?

There should be a postal code section on these things. Most international cities have postal codes, like the US has zip codes, right? --Goatrider 08:53, 10 August 2006 (UTC)

Yeah I was thinking the same thing. The MA town box has an option for zip code(s) and area code(s). I think they should be included on this page. Maybe someone could copy the code. Or I will eventually. JARED(t)  14:25, 10 August 2006 (UTC)
Someone copied it. But the section doesn't show up on the saved page. VolatileChemical 14:20, 14 August 2006 (UTC)
Yeah, I did it, but I don't know how to fix it. JARED(t)  14:44, 15 August 2006 (UTC)
Oppose this. Large cities in the US have way too many postal codes to list easily in an infobox. howcheng {chat} 17:49, 15 August 2006 (UTC)

How about telephone exchange and area code(s) as well? Daniel Case 16:51, 15 August 2006 (UTC)

I tend to agree with Howcheng —although, not strongly. This could work for small towns, but it could be a mess for larger cities. For large cities, the only way this could work (and be bearable) is if there was a link to a list of postal codes (or area codes) in the field entry. I did something similar to this for MPs and MLAs in the infobox for Toronto —it really uncluttered the infobox. Which leads us to the questions: Will this clutter up infoboxes? Should we put it in as optional and let the page editors decide? Is this really needed? —MJCdetroit 18:34, 15 August 2006 (UTC)
It's up to anyone. I just did it because it wasn't there. It's a good addition for small cities like the one I originally tried it for, but it doesn't work for some reason and I'm not good with ParserFunctions. JARED(t)  19:05, 15 August 2006 (UTC)

I have to oppose this as well. Look at how many postal codes there are or Phoenix, Arizona or New York City. I don't think I want those in the infobox,... It probably really doesn't need to be in an encyclopedia, either (though there's already a wiki page for zip codes in NYC). But the info is more for something like an almanac or city guide than an encyclopedia. Area codes would fit in the infobox better, but again, just because we can, does that mean we should ... area codes probably don't go in an encyclopedia either. Dr. Cash 22:04, 15 August 2006 (UTC)

I would agree that postal code is unnecessary on city pages. --23:58, 15 August 2006 (UTC)
I seen that someone did add postal codes to the template. I entered them in when I edited Waterloo, Ontario. They showed up under "Motto" and above the map image. It looked very out of place. So I switch the postal fields location to near the bottom of template; where it looks better. However, I am still not crazy about this field, but we'll see how it goes. MJCdetroit 12:24, 13 September 2006 (UTC)
I don't see the problem. Smaller cities have only one code, and for larger (let's take your example of Phoenix, Arizona) it's enough to write "85001-85099". There isn't even a problem when there are some of these numbers aren't used. Look at Dresden (the city with the lowest postal codes in Germany), the range is 01001-01326, but that doesn't mean that all 326 codes are or have to be in use. People aren't that dumb to write down every single code (at least I hope so). --32X 16:16, 9 October 2006 (UTC)

Why are the postal codes in bold? I don't think we have any other value fields in bold, only the labels. Kaldari 18:57, 9 October 2006 (UTC)

[edit] Weird bug

There a weird bug with this template on the Nashville, Tennessee article. Somehow the population and coordinate values are interfering with each other. As long as there is a reference cited for the population, it adds "[1])" to the beginning of the coordinates. Any idea what's going on here? Kaldari 02:02, 14 August 2006 (UTC)

Per Wikipedia:WikiProject Geographical coordinates#Parameters, the "type:" parameter for the coor* templates should be, for example, type:city(population). This template passes the value of the population_total parameter to one of the coor templates, and if a reference is included it apparently confuses the coor template. I can't think of a reasonable way to strip a reference from the population_total parameter in "template language". Assuming no one else can either, then we either need to make the coor* templates do it or add yet another parameter for the reference so we can make the coor template happy. -- Rick Block (talk) 03:26, 14 August 2006 (UTC)
Can't the population be cited within the article instead of infobox? Normally it is mentioned in both places. --MattWright (talk) 18:15, 14 August 2006 (UTC)
Yes, I'll just remove the extra citations for now, although I suspect others may run into this problem at some point. Kaldari 07:21, 15 August 2006 (UTC)
It looks like Louisville, Kentucky is also experiencing this bug. Kaldari 22:28, 17 September 2006 (UTC)

I'm going to go ahead and remove the population parameter from what gets passed to the coordinate template. The population parameter is completely optional for the coordinate template and isn't actually used for anything currently (as far as I can tell). Ostensibly, the logic behind passing the population to the coor template is that at some point in the future Wikipedia may support some type of automated mapping system and the population would help determine the appropriate scale for the map. When and if such a feature is actually implemented in the future, we can certainly re-examine the issue. (Perhaps we could figure out a way to get the coor template to strip out citations from the population). Right now, however, I don't see any good reason why we need to pass the population, especially if it is going to cause rendering bugs in our template. Kaldari 22:47, 17 September 2006 (UTC)

To recap what Kaldari did (from a non-programmer POV). Basically the information for population is still there but you have broken any "link" between the population total and the coordinates. The problem being when there is a footnote superscript at the end of the population total (like in the two examples above), it gets carried over to the coordinates and would look something like this: [1]36°10′00″N, 86°47′00″W. Breaking that "link" would remove the [1] from the front of the coordinates. This fixes the bug and makes the infobox visually better in those cases. Visually better —I'll agree to that. —MJCdetroit 12:46, 18 September 2006 (UTC)
The fix I would prefer is: 1) Remove citations from infobox and place them in the article where the population figures are mentioned or 2) Create a new field in infobox called population_ref (or something) that can be used for the reference and placed properly. That would allow the coordinate population link to still work. --MattWright (talk) 22:16, 18 September 2006 (UTC)
Side note / Just in case: If you folks here would want to go with 2), I think I could help converting the calls with my bot power. (This is not a voice for any particular solution – I'm not an expert on this template here). --Ligulem 22:29, 18 September 2006 (UTC)
Option 1 requires that every editor of city articles be educated about not using citations in the Infobox, and it adds another layer of instruction to an already complex template. Option 2 seems like extra work for no (or virtually no benefit). What's wrong with the current solution (i.e. not passing the population)? We already pass "city" as the coordinate type. Passing the population is just an extra nicety. I don't know of any mapping system that actually uses the population figure, much less one that is hooked up to the coor template. Is there any reason it would benefit anyone to pass the population? Kaldari 22:41, 18 September 2006 (UTC)
I won't argue this too much, because it isn't that important to me, but the information can be useful to external services, such as geonames.org. If you go to [1] and click on the Wikipedia link on that page, you can see it will popup city names, along with their population, which I think it is gathering from the coor template, although I am not 100% sure on that. I was the one that initially added the population to the city() type on this template, and prior to that, many cities on geonames did not have populations noted. --MattWright (talk) 23:54, 18 September 2006 (UTC)
Geonames doesn't seem to be using Wikipedia's populations. Even if they were, it would be just as easy for them to scrape the populations from the population field as it would be to scrape it from the coordinate URL. Scrapers don't factor into this problem. The only case in which it would actually make a difference is if both the Map Sources Wiki and one of the mapping systems linked from the Map Sources Wiki utilized the population (since the parameter could theoretically be passed to them from the Wikipedia article). That would work like so: Click on the coordinates in the Wikipedia article to go to the Map Sources Wiki; the population gets passed in the query string and then dynamically tacked on to the URLs for the various mapping systems; click on a mapping system in the Map Sources Wiki; the population gets passed again in the query string and parsed by the mapping service. Right now, though, it doesn't even look like the Map Sources Wiki parses out the population (only the type). So it really doesn't matter to anything currently whether we include the population or not. Kaldari 01:52, 19 September 2006 (UTC)

[edit] New look, again

Per the thread slightly above, #New look, more similar to template:Infobox Country, I've created a new version much more similar to template:Infobox Country and template:Infobox U.S. state, please see user:Rick Block/Template:Infobox City. Enough time has passed that the new style in MediaWiki:Common.css should be available to all users. Are there any serious objections to changing to this new style? Note that once all three of these templates use class="infobox geography", their style can be changed in unison by updating this css class. -- Rick Block (talk) 02:58, 24 August 2006 (UTC)

Agree that look should be sync'd with state and country infoboxes. --MattWright (talk) 03:45, 24 August 2006 (UTC)
Sounds good. I still like the grey bars on the current version (Location, etc), but I'll live without 'em :) -- SatyrTN (talk | contribs) 06:53, 24 August 2006 (UTC)

[edit] Ranally city ratings

Would there be interest in adding the Ranally city ratings (a measure of the economic importance of the city) to the infobox, perhaps under a new heading "Economic characteristics"? Bellczar 01:13, 25 August 2006 (UTC)

Since the template is used by cities all over the world, that might not be usefull... SatyrTN (talk | contribs) 01:38, 25 August 2006 (UTC)
I also don't really see it as being useful information. It's an arbitrary ranking system by one company. --MattWright (talk) 02:01, 25 August 2006 (UTC)
I must disagree that it's arbitrary. It's based on hard data such as retail sales, newspaper circulation, etc. What other single measure is there that can inform one whether Santa Paula, California, for example, is more important in the national economy than Jamestown, New York? Population alone can't do it. Using population as the only guide, someone would conclude that Jacksonville, Florida and Mesa, Arizona are more important than Miami and Minneapolis. And that wouldn't be correct.Bellczar 19:00, 25 August 2006 (UTC)
By arbitrary, I mean that they have set the "formula" for what they think is important. All of the hard data you mention is good information to include in an encyclopedia article on each city. But what makes Rand McNally's classification more important than other classifications or more useful than the raw data? --MattWright (talk) 20:16, 25 August 2006 (UTC)
What other classification is there that conveys as much information about the economic importance of a place (in both its local and the national economy) in a single measure? Obviously, the Ranally rating would not supplant any raw data in Wikipedia. Ranally data are frequently cited by the Federal Reserve banks in evaluating community economies. The Ranally city rating system (RCRS) is designed to reflect an inherent hierarchy in the national economy, not to impose one of its own. The data that RM consider are judged (for example) to make Cleveland more important nationally than Cincinnati, so that Cleveland is 1-AA and Cinti is 1-A. And so forth.
It is really a very elegant system. The country consists of 487 markets (basic trading areas) and each of them is centered on an A-rated city. The numeric rating and the number of letters (1-A, 3-AA, etc.) indicates its importance in the national economy. Other large cities in each market area are rated B or C, and important suburbs are rated S. I have seen many market areas as defined by large companies for their geographic hierarchy, and they often closely correspond to the market areas of the RCRS. I think it would be useful to have pages with lists of 1-AA, 2-AA, etc., cities and links to those pages from the individual city pages. I have noticed that the business and economics area is not as developed in Wikipedia as some others (e.g., pop culture). The RCRS might be a tool in getting Wikipedians to think of cities as not onlyt venues for culture but also their place in their local and the national economy. Just my 2c. Obviously I don't have the time to implement my idea (i.e., an edit to 1492 separate city entries) even if there were a consensus for it. Bellczar 04:50, 26 August 2006 (UTC)
If there was just a little more information on it or it was more notable, I might agree with you. I tried googling for it and there just doesn't seem to be any information anywhere, and the article on Wikipedia is fairly recent, having been created by you. Are these ratings public information or is it something that is normally paid for? Where do you get the complete listing, etc.? There are no external links in the article either. --MattWright (talk) 06:14, 26 August 2006 (UTC)
They are available in the Rand McNally Commercial Atlas and Marketing Guide, published and updated annually, which is available at larger libraries. Bellczar 02:06, 27 August 2006 (UTC)

[edit] Elevation

Wouldn't it make more sense to have the highest and lowest point in the infobox instead? A single elevation value seems ambiguous -- is it the mean value (and how is the mean calculated) or is it the elevation at the centroid of the city or some other thing? A city doesn't typically have a single elevation. --Polaron | Talk 16:51, 29 August 2006 (UTC)

There is often an official elevation, recognized by the city (such as Denver). Otherwise, the Infobox can already accomodate a range (as seen at Los Angeles). --MattWright (talk) 17:23, 29 August 2006 (UTC)
Thanks. I think a range might be a good option, especially for cities that have large extremes. --Polaron | Talk 17:25, 29 August 2006 (UTC)
If there is data to support a range that would be great. However, for American cities, I found my elevation infomation from the USGS which only gives one value in feet and metres. For San Jose, the elevation was reported by the USGS as "Elevation(ft/m):85/26". This data is referenced in the San Jose reference section. MJCdetroit 18:28, 29 August 2006 (UTC)
FallingRain.com shows elevations for almost any location in the world.--enano (Talk) 20:21, 20 September 2006 (UTC)

[edit] New look

I've changed the template to use class="infobox geography" per the discussion slightly above. I'm adding a new section here if anyone wants to complain about this. -- Rick Block (talk) 00:49, 1 September 2006 (UTC)

Looks good except that the city picture is off-center and all of the labels are in bold except for "Summer" (time zone). Kaldari 05:13, 1 September 2006 (UTC)
Fixed. -- Rick Block (talk) 13:56, 1 September 2006 (UTC)

[edit] Reversion of m

Discussion moved to Wikipedia talk:Manual of Style (dates and numbers)
bobblewik 21:11, 3 September 2006 (UTC)

[edit] Another Leader?

Wasn't the decision above to not add more leader names and titles? -- SatyrTN (talk | contribs) 05:37, 4 September 2006 (UTC)

I think we've agreed to not add city council members. I've started going through the cities using this template, elinimating "virtual rows" (entries within one row of the table that look like multiple rows by including <br>s). The point of doing this is so these tables can be more easily understood by (usually blind) people using screen readers. This generally means using the additional subdivision_type/subdivision_name parameters and I ran into Berkeley, California that lists both a mayor and a city manager. Two (or three, or four) pairs of leader title/name parameters seem not too outrageous to me. I should have brought it up here first. -- Rick Block (talk) 15:35, 4 September 2006 (UTC)
I've created a subpage to help coordinate this activity, see Template talk:Infobox City/links. I think it would be good to do with a bot, but there are enough irregularities that I'm not sure it's entirely possible. I did something similar for the 200 (or so) references to template:infobox country a while ago which took a few days. There are slightly more than 2000 references to this template, so it will take a good bit longer to finish this if I'm the only one working on it (and a bot is not used). If anyone would like to help or has suggestions for a bot-based approach, please speak up. -- Rick Block (talk) 16:14, 4 September 2006 (UTC)
I have added 2 more pairs of leader title/name parameters. The addition of these to pairs will greatly help get rid of the <br>s in Canadian cities which all include the city's MPs and MLA's. For an example see Toronto. MJCdetroit 17:43, 7 September 2006 (UTC)

[edit] More leader params

Moved here from: Template talk:Infobox City/Template parameter changes bot

I think the leader_title3/leader_name3, etc should be revisted because of the way that some of the Canadian cities are currently set up. I know the city council members did not go over well but if we limit to 4 fields that should cover it pretty well. If there are large numbers of leaders (such as MPs) then leader name3 can be a link to a list of names. That way we would not have to use the <br> to break up fields for things such as MPs and MLAs. Check out Toronto to see an example. —MJCdetroit 14:16, 6 September 2006 (UTC)

Any thoughts on my proposal above of adding 2 more leader fields above to tie up any lose strings, especially for Canadian cities. I think that this would really help and unlike the city council additions there would only be 2 additional fields not 12. I think that the city council additions were like dropping a Mac truck into the infobox; this is not so blunt. Thoughts? —MJCdetroit 12:53, 7 September 2006 (UTC)

I agree. In the "great BR purging" that's going on, there are at least a dozen or so cities where more leader params would be useful. In some cases, city council members are listed but as long as it's a single HTML row (labeled, for example, "city council") with multiple lines of "value" (yes, with embedded BRs) it's OK from an accessibility viewpoint. As MJC says, there are a bunch of Canadian cities that list mayor, MP, MLA, etc. as well. And there's one "city" (fictional, no less) that lists mayor, vice-mayor, and sheriff. -- Rick Block (talk) 17:52, 7 September 2006 (UTC)

Compare these versions of Toronto to see how much of an improvement these changes and this infobox makes.


MJCdetroit 18:20, 7 September 2006 (UTC)


[edit] Template parameter changes bot

moved to Template talk:Infobox City/Template parameter changes bot --Ligulem 10:12, 7 September 2006 (UTC)

[edit] Handling city names in other languages

Now that Infobox City is sufficiently generic, I'm seeing it used for many cities outside of the English-speaking world. One difficulty that arises from this is deciding what to enter as the official_name. Most of these cities seem to be opting for a dual name approach, but there is little consistancy. Here are a few examples:

official_name = آمل <br /> Amol
official_name = Zaysan (Зайсан)
official_name = Beijing - 北京
official_name = Tokyo <br> (東京都)

It looks like we need to add an optional parameter for native_name or something similar so that there will be some consistancy in how these are handled. Kaldari 23:07, 6 September 2006 (UTC)

I propose adding a native_name field. Any opinions on the best way to format it in the template? Kaldari 19:20, 13 September 2006 (UTC)
How this is handled in template:Japanese prefecture is with two params, one in Japanese (with a transliteration), formatted as follows:
'''{{{Name}}} Prefecture <span style="white-space: nowrap;">({{{JapaneseName}}})</span>'''
What this does is put the English name and parenthesized Japanese name on the same line (if they both fit), but if the English name is too long for this, it splits the two and puts the Japanese name underneath (with both centered). See, for example, Aichi Prefecture vs. Yamaguchi Prefecture. -- Rick Block (talk) 00:58, 14 September 2006 (UTC)
I have added a native_name parameter on an experimental basis. It follows the formatting suggested by Rick Block and is an optional parameter. For examples of it in use, see Amol or Zaysan (town). If anyone notices any problems with it, let me know. Kaldari 23:23, 20 September 2006 (UTC)
Question: What if the 'official name' has more than one word? For example most of the Canadian cities follow the format: city of Toronto, Ontario or (if in Quebec) Ville de Montréal, Québec. If I switch over the Montreal infobox to this template will all of the English name and all of the French name be on separate 'lines'? I haven't try it yet but is a concern that I thought might be worth mentioning. MJCdetroit 17:02, 22 September 2006 (UTC)
I tried and it doesn't work well. It breaks the box to the right and everything is on one line. —MJCdetroit 17:44, 22 September 2006 (UTC)
This may be because the table width is specified in ems not pixels. The Japanese prefecture template does not have this problem, and I think the only difference that's relevant is that it specifies a width in pixels. -- Rick Block (talk) 18:45, 22 September 2006 (UTC)
Can you show me an example that you tried so that I can take a look at what happens? Send a link to the test revision if possible. Kaldari 19:11, 22 September 2006 (UTC)
OK, I've figured out what the problem is: I was using a non-breaking space to keep the space character at the beginning of the optional native_name from being striped as whitespace within the if statement. Problem is, the line won't break on a non-breaking space! Duh. So is there a character besides a non-breaking space that will act as a space character but not be stripped out as whitespace? Kaldari 00:00, 23 September 2006 (UTC)
Maybe something at Space character, such as &ensp; or &emsp; --MattWright (talk) 00:52, 23 September 2006 (UTC)
In my sandbox, the only way that I was able to get both long names above and below each other was to use &nbsp; between the words and at the end of the English name I placed a regular space followed by a &thinsp;. This "forced" them to be above and below each other. Visually it looks ok, but I am wondering if my rigging would have accessibility issues. See my example:
|official_name = City&nbsp;of&nbsp;Montreal,&nbsp;Quebec &thinsp;
|native_name = Ville&nbsp;de&nbsp;Montréal,&nbsp;Québec
MJCdetroit 01:25, 23 September 2006 (UTC)
I've changed it to &#x0020; (ASCII code for a normal space), which seems to work. -- Rick Block (talk) 01:19, 23 September 2006 (UTC)
Ok, Rick's placement of the 'normal space' fixed it. No need to force/rig anything. I think Montreal will be getting a new infobox soon. —MJCdetroit 01:33, 23 September 2006 (UTC)

[edit] Indenting

I liked the indenting for subdivision_type1 and subdivision_type2! Anyone else? -- SatyrTN (talk | contribs) 01:42, 8 September 2006 (UTC)

A quick shot: I don't care. But during my recent serial edits I noticed some rare problems with wrapped lines. I saw several cases where an entry was wrapped to a second line (without a BR) and that second line was not indented, but the first one was (although I'm not sure why this happended, but I assume these problems went away with Kaldari's edit). If you guys want it intented, I would propose that you look for ways to make not only the first line indented, because longer entries can wrap around to multiple lines. I digged into my contribs looking for an example but gave up seraching after 20 minutes. But I'm pretty sure I saw some yesterday during my botting. Apologies if I might have overlooked something. Maybe some sandbox testing would be helpful (I'm too lazy right now ;-). --Ligulem 09:07, 8 September 2006 (UTC)
I think I found an example: Klawock, Alaska. --Ligulem 09:12, 8 September 2006 (UTC)
I could reproduce the aforementionend problem in my sandbox. See User talk:Ligulem/work/sandbox2. See the string "Prince of Wales-Outer Ketchikan", which is wrapped to a second line (not caused by a BR). --Ligulem 09:20, 8 September 2006 (UTC)
I tried fixing this using margin-left rather than text-indent and it didn't seem to work (not sure why). And, in case anyone is confused, this example wraps in monobook but not classic skin. -- Rick Block (talk) 13:52, 8 September 2006 (UTC)
  • I strongly prefer "no indent" for the value (rightmost column). Having some of these indented and some not is fairly classic "bad visual design". Most of the other indented labels (on the left) are dashed as well. I don't care as much about the label indenting, but if they're going to be indented they should probably be dashed. -- Rick Block (talk) 13:52, 8 September 2006 (UTC)
    • I really don't think the indenting is necessary and it looks cleaner without it. The thing I hated the most about the old design was that there was crazy indenting all over the place and it made the table look really messy. If most people prefer the indenting, however, I would agree that it should at least be consistant and use the dash. Kaldari 18:16, 8 September 2006 (UTC)
      • I didn't realize the value column was indented - that certainly shouldn't be. Especially since I don't think any other values are indented. But I'm in favor of indenting the label column - with dashes, since that's the way the others are. -- SatyrTN (talk | contribs) 21:57, 8 September 2006 (UTC)

[edit] Titling

In order to stop the city name becoming hidden/overlapped by the box when the text wraps (i.e. for longer city names), I have moved the city name to within the border of the box. We had a similar problem with the United Kingdom infobox and this seemed to be the simplest solution (as per Template:Infobox Country). IMHO, it looks better this way too, but that is not really the issue! DJR (T) 16:03, 11 September 2006 (UTC)

[edit] Font in motto

This was moved here from the Detroit talk page. 13:13, 12 September 2006 (UTC)

—Font on Detroit InfoBox—

Who changed the font of Detroit's city motto in the Detroit infobox? It's very distracting. Can someone change it to something smaller and less assumming like it used to be? It doesn't fit the page one bit. --Criticalthinker 07:47, 12 September 2006 (UTC)

It looks like forcing the entire motto to be in italics and quotes is problematic on that article (aside from the font issue). They include a note in their motto field, which shouldn't be in italics and quotes. Isn't using both italics and quotes redundant anyway? Kaldari 19:16, 13 September 2006 (UTC)

[edit] Seal and flag, how about city arms?

I'm currently working on a swedish city and will soon start with some other swedish cities. Now the problem is that swedish cities doesn't have seals or flags, most have city arms (stadsvapen in swedish), for example; Stockholm and Gothenburg. Now since these "shields" have a long history and is being used today in many culural things for the their citys, I feel that it's important that they can be used in the infobox but not under seal or flag. --Krm500 10:04, 17 October 2006 (UTC)

Please, could someone help me? I don't want too mess up the template and that's why I'm asking here. I want too write an article on these sheilds and that's why it's important too get it right in the template.
I tried the other night but couldn't get it to work correctly. I have asked for help on this. —MJCdetroit 01:32, 20 October 2006 (UTC)
I'm not sure I understand exactly what is requested. Are you looking for an optional "shield" parameter (with image) that takes the place in the infobox of, say, the seal? It would be possible to set it up so that at most two of flag, seal, or shield would fit (and if anyone provided all three the infobox would be half again wider). I've added an "image_shield" parameter to Template:Infobox City/Test that works this way. -- Rick Block (talk) 02:01, 20 October 2006 (UTC)

Well the thing is that I don't know of any Swedish or Scandinavian city that have an official seal. Most of them have city arms, a sort of coats of arms. And it would be nice if I could be able to have the text city arms under the image instead of "Seal".--Krm500 00:55, 22 October 2006 (UTC)

Please look at Template:Infobox City/Test and let me know what you think (the one on the right is the "test" version). The text currently says "Coat of arms". We could make this "City arms", and even make it flexible (with yet another parameter) if this might be called something else somewhere else. -- Rick Block (talk) 14:52, 22 October 2006 (UTC)
I've looked at it and I have looked at the Coat of arms article here on Wikipedia. It looks good, the term "City arms" is probably a translation from swedish so the text should probably say coat of arms. --Krm500 15:44, 22 October 2006 (UTC)

When will I be able to insert the coat of arms in the infobox? --Krm500 19:15, 23 October 2006 (UTC)

I just updated the template. The coat of arms parameter is called "image_shield". -- Rick Block (talk) 01:14, 24 October 2006 (UTC)

Ok, thanks for all the help! --Krm500 08:14, 24 October 2006 (UTC)

[edit] Form of government

Is there an easy way to indicate the type of municipal government? I think this is useful to include for the New England and New Jersey municipalities. --Polaron | Talk 19:35, 19 October 2006 (UTC)

You could put in under one of the leader_title & leader_name fields, e.g. |leader_title = gov type AND |leader_name= Your town City Council
Do yo have a city that you were thinking of doing this to? MJCdetroit 20:12, 19 October 2006 (UTC)
Nothing in particular at the moment. But, for example, New Jersey municipalities have several forms of government. This is also true for Connecticut and Massachusetts where you could say that there is a full spectrum of government forms ranging from an open town meeting to a strong mayor-council. I think this was one of the reasons why {{Infobox Town MA}} exists. --Polaron | Talk 20:20, 19 October 2006 (UTC)
Look here: North Brunswick Township, New Jersey. Is this what you were thinking? MJCdetroit 20:37, 19 October 2006 (UTC)
That looks great - thanks. I'll probably start putting infoboxes for the cities/towns of Connecticut over the next couple of weeks. --Polaron | Talk 21:49, 19 October 2006 (UTC)
I think we should add a new (optional) parameter for this rather than overloading one of the leader ones, just so it's more obvious what's going on. -- Rick Block (talk) 23:34, 19 October 2006 (UTC)
I inserted a new optional parameter called government_type (for lack of a better term) at Template:Infobox City/Test, what do you think about? If it is likable we can insert it here or we can tweak it a little. —MJCdetroit 00:20, 20 October 2006 (UTC)
Looks good. I tweaked it so the government type is completely independent of the leader fields. -- Rick Block (talk) 01:09, 20 October 2006 (UTC)
I've included this in the template and updated the empty syntax. -- Rick Block (talk) 01:15, 24 October 2006 (UTC)


[edit] For example, in Canada, MPs and MPPs

Would it be possible to add to the template a link to the MPs and MPPs instead of having to find a list somewhere else on the page like in Toronto? Also, for smaller cities, could we make an option to have the MPs/MPPs on the template? Wikada - Talk Contributions 23:48, 24 October 2006 (UTC)

The Link to the MP and MPPs was removed from the infobox for some reason. It was there October 5th? The infobox for Toronto look like this:

|leader_title3= Legislature
|leader_name3= MPs, MPPs, and Senators.

I'll put it back in today. —MJCdetroit 14:56, 27 October 2006 (UTC)
In response to MJCdetroit, I have outlined my reasoning for removal on my talk page. In short, after a little searching I found no other city with this template that includes such a link. I removed that link to maintain consistency with the other articles, and also because I honestly don't see the usefulness of such information in the infobox. MPs and MPPs are not "leaders" or governmental bodies of the city, so the "leader" attribute seems inappropriate. I will appologize if there was a prior consensus on this issue that I am not aware of. KeL 04:33, 29 October 2006 (UTC)

St. John's, Ottawa , Windsor, Ontario, North Bay, Ontario —just to name a few have them listed. All Canadian cities that used the old template had them listed. Like Thunder Bay, Ontario which still uses the old template. It's more or less a compromise/hold over from that template. MJCdetroit 04:58, 29 October 2006 (UTC)

Thank you for pointing this out as I was not aware of those examples before. I agree the links should be left there for the time being as a compromise. Personally I think the links should never have been there in the first place, so I want to respectfully say it here: MPs, MPPs and Senators are not part of the city government and it makes no sense to include them in the city infobox. I think Canadian cities should have their infoboxes like the American ones. As more and more cities have their infoboxes converted, I hope there will be a consensus to remove those links, for the sake of relevence and consistency. KeL 05:28, 29 October 2006 (UTC)

[edit] Some issues

  • First off, the field "shield" should be called "coat of arms" or "coa", as a shield is only part of the coat of arms
  • Secondly, the link (for coat of arms or seal) needs to link to Coat of arms of ARTICLE NAME or Seal of ARTICLE NAME not Coat of arms of OFFICIAL NAME or Seal of OFFICIAL NAME, as articles of that type are generally not named with the official name (for instance, it's Coat of arms of Toronto, not Coat of arms of City of Toronto (and a redirect is not an acceptable solution)
  • Thirdly, there needs to be an option for LOGO, as several city articles do not have their flags, but instead their official city logos instead (which are not seals or coats of arms)
  • Finally, how are we coming on the area code field?
-- OzLawyer / talk 14:29, 27 October 2006 (UTC)
P.S. - Could someone unbold the postal code section (the actual codes, not the description), since they're out of place bolded
Postal code is unbolded and added an area code field. See Montreal for an example. —MJCdetroit 04:11, 29 October 2006 (UTC)

[edit] City Logo

Example City
(高雄市)
Official flag of Example City
Flag
Official seal of Example City
Seal
Coat of arms of Example City
Coat of arms
Official logo of Example City
Logo
Nickname: "The Harbor City (港都)"

Per Oz's third point above, I added the city Logo field. While unlikely to actually happen, it is now possible to have a city infobox that shows a Flag, Seal, Coat of Arms (Shield), and City logo. To do this and not have it look like—well crap—was the hard part and thanks to some help from 52 Pickup and Rick Block it doesn't look like crap. This is supposed to be used when a city does not have a flag but has a logo. However, we had to plan for the event that someone somewhere would add all 4. In any case it's the best you're gonna get...see example to the right. —MJCdetroit 16:50, 6 December 2006 (UTC)

I found the need to place optional size fields in the template. The first page that I edited with only a city logo had the logo very small. Adjusting the size made the infobox look better. The article was Brantford, Ontario. —MJCdetroit 01:09, 7 December 2006 (UTC)

[edit] Another issue

I don't like how when you have just one population figure, it shows up as City: xxx,xxx. No kidding it's the population of the city? I'd assume that most articles will only have one population (no "metro" or "urban" populations), so perhaps something can be done about this. OzLawyer / talk 17:45, 27 October 2006 (UTC)

I have another issue; Why isn't there a density for urban area? Cities in Sweden are municipalities, so the city area is the whole municipalitie area. The thing is that the city (municipality) that I'm working on right now is 450 km², but the urban area is of the "acctual city" (not political area so to speak) is only 199 km² and with a larger population since the urban are stretches over three diffrent municipalities. The dencity for the urban area reflects better of how people live them the dencity for the municipality.
Since there's both dencity for city and metro area, why not for urban area? --Krm500 13:35, 29 October 2006 (UTC)


I added the following two fields:
|population_density_urban_km2 =
|population_density_urban_mi2 =
Happy editing. —MJCdetroit 01:50, 30 October 2006 (UTC)

Great, thanks! --Krm500 01:59, 30 October 2006 (UTC)

[edit] Motto field

I have removed the quotation marks and italics from this field, as it messes up any attempt to display a Latin (or other foreign language) motto and its translation. It shouldn't have been in italics anyway if it was in English—the foreign language goes in italics, not the English. Now the motto can be given its own formatting by the user. For a more complicated fix for this, one would require three fields, all optional:

  1. The foreign motto field, which would be formatted in italics
  2. The translation field, which would be formatted in roman, but with brackets around it
  3. The English motto field which replaces the above two and is neither in italics nor brackets

OzLawyer / talk 15:08, 3 November 2006 (UTC)

That issue has come up before, thanks for taking care of that. We should probably identify what language the motto is in and being translated from; latin, french, etc. —MJCdetroit 15:30, 3 November 2006 (UTC)


[edit] Adding a "subdivision" field

I was wondering whether we could add a "subdivision" field, for cities that consist of a group of well-defined entities, such as the boroughs in New York City. Something like:

Subdivision type    Subdivision entities

E.g. for NY city (just an example):

Boroughs        The Bronx, Brooklyn, Manhattan, Queens, Staten Island


Obviously, cities who do not have significant internal subdivision just wouldn't use the field. --Nehwyn 17:50, 5 November 2006 (UTC)

I added two more subdivision fields. MJCdetroit 19:11, 5 November 2006 (UTC)
Thanks, that should do it even for the more complex city subdivisions. --Nehwyn 19:18, 5 November 2006 (UTC)

[edit] Gentilic

Can we add a field for the city's gentilic? This wouldn't be too hard and would be useful. I noticed several other more specific infoboxes for cities and towns have this.

--Alekjds 01:50, 18 November 2006 (UTC)

I think that's what the "nickname" field is for. -- SatyrTN (talk | contribs) 16:09, 18 November 2006 (UTC)
It's a little different. Gentilic, or demonym, is what the residents of the city are called, not a nickname for the city itself. Like "New Yorker" for New York City. --MattWright (talk) 22:43, 18 November 2006 (UTC)
Oops - you're right. I misunderstood a Template_talk:Infobox_City/Archive_2#Misunderstanding_of_.22nickname.22_field previous post on this very topic. My bad :) -- SatyrTN (talk | contribs) 02:40, 19 November 2006 (UTC)

[edit] A couple of few things: Location of Subdivision names, Coordinates, Auto-categorisation, Auto-Calculation

The template {{Infobox Australian Place}} has been designed to cover not just Australian cities, but towns, suburbs and local government areas, and so is more suitable for Australian locations than this template. See talk page for some examples. But the Infobox City template has a number of cool features that could be implemented at IAP, and I have a few questions/comments about this template:

  • Location: Instead of listing the country, state, etc. that the city is located in, wouldn't it look better to display them directly under the name of the city?
  • Coordinates: Inside the infobox or at the top of the article? New York City does both and looks a bit silly.
  • Auto-categorisation: It is possible to take the entry for "established_date" and auto-assign the entry to "xxxx establishments" (so long as only a year is given). Some further categorisation is also possible using the "subdivision" fields - this works really well for the Australian infobox but this is perhaps not such a good idea for such a generic infobox as this.
  • Calculation of area/population: With {{Infobox Former Country}}, it is possible to automatically calculate area in sq.mi. if the area is given in km2. Population density can be calculated directly from population and area (km2) and can then be also converted to density per sq.mi. - this reduces the number of fields that you need to fill in. The drawback is that the entered data must contain just the numbers (no commas, no other text) otherwise the fields will display error messages. So if you have already implemented this template for a lot of entries, changing to this auto-calculation might not be worth the trouble.

I didn't go through the entire chat log for this template, so maybe some of what I've said has already been covered. - 52 Pickup 13:32, 5 December 2006 (UTC)

  • Location: We could compare them in a sandbox? It's worth looking at.
  • Coordinates: The NYC example had an additional template at the bottom of the page that places the coordinates at the top of the page. This is independant of the infobox template. I removed that template so now there is just one set of coordinates.
  • Calculation of area/pop. Great idea! I don't know if the prep" could be done with AWB or even fast enough with AWB. If not, you would need to have a bot programmed to "prep" all the present infoboxs that have the commas (and spaces) in the area and density fields be removed before placing the auto-calc/auto-format on those fields. Bot request?? —MJCdetroit 15:52, 5 December 2006 (UTC)
  • Location:I've put up a rough version of the NY infobox here. I have only added the fields to the top, but they are still displayed in the normal area below. I thought that perhaps only the first two levels of subdivision are enough for the top section. For the Australian infobox, one or two levels are displayed, depending on the location type.
  • Co-ords: Actually, I preferred the co-ordinates at the very top instead of in the infobox. Perhaps the extra co-ord template could be automatically used by the city template?
  • Calculations:So far I've found no way to automatically remove commas. There are some string functions in the works over on Metawiki that would do just this, but they are not yet implemented on Wikipedia. This is why this calculation feature has not yet been used by the Australian infobox. The same auto-calculations can also be done for "elevation", so long as a single value is given instead of a range.
  • Establishment date: I have just added the auto-categorisation of establishment date to the infobox, using the content of established_date. It appears to work (see New York City). For the benefit of people using this infobox for testing, you can turn off the category-assignment by entering the parameter "_noautocat=yes" - 52 Pickup 16:41, 5 December 2006 (UTC)
Your example looks good but I am torn because I like the first two subdivison names (in this example:State, Country) on the top but I still like having them under the map to "tie" together the state, county/parish, ward/district/borough, et cetera. Maybe we could have subdivision_name (i.e. country) only on the top and keep the other subdivision types and names in their current location.
As for the auto-categorization, it is nice to have the option and since it can be turned off, I wouldn't have a problem with it.
I do prefer the coordinates under the map, but I'm flexible. —MJCdetroit 21:25, 5 December 2006 (UTC)
I think what levels of subdivision are appropriate to display at the top might be kind of variable. It might be best to simply avoid this issue and keep the subdivisions under the map. I prefer the coords under the map as well (the template that shows them at the top only works in monobook skin). -- Rick Block (talk) 01:22, 6 December 2006 (UTC)
Ah. I wasn't aware that the coords template only works for one skin. As for the what things to display at the top, I was thinking that a maximum of two is right. But which ones to use is pretty flexible. For Australian locations, this works rather well. For example, Sydney has the state listed at the top (perhaps it should say "Australia" too), but the Sydney suburb of Parramatta says "Sydney, NSW" instead of "Sydney, NSW, Australia". The Aussie template has different display settings for city, town, suburb and LGA (is this infobox intended to cover city, town and suburb althogether?). But it's true that Australian locations do not have counties (LGAs are the closest we have - they don't count really as counties: the Sydney area contains 38 of them) so it is not as complicated as some places. Perhaps some more testing is needed. - 52 Pickup 08:41, 6 December 2006 (UTC)
I have done a bit more experimenting: Cologne and Sydney. The Sydney one is to test the application of some features of this template to the Australian one, while the Cologne one is to compare this infobox with the German infobox {{Infobox Town DE}}. While I am not saying that we should go ahead and replace the German one with this, it does look pretty nice with Infobox City - except for the map. Given the north-south elongation of Germany, comapred to the USA or Australia, the map is far too big if nothing is given for mapsize. In this respect, the German infobox is better. But even if the mapsize is reduced, the infobox layout looks a little funny. There will be other locations that will have this problem, so it deserves some consideration. One quick and nasty way around this problem is to place the map image in one of the smaller image fields (eg. flag, seal), but unfortunately that would require extra fields for captions so the wrong text is not displayed. - 52 Pickup 17:51, 6 December 2006 (UTC)
One more thing. Apparently having the co-ordinates at top has some benefits - the deletion of the NYC coordinates was reverted with a referral to User:Dschwen/WikiMiniAtlas. - 52 Pickup 18:09, 6 December 2006 (UTC)
I played with the mapsize and Cologne looked ok to me. The Sydney draft seemed to work well too. — MJCdetroit 19:00, 6 December 2006 (UTC)

[edit] auto-categorisation for established_date

So what does that do? How does it work? -- SatyrTN (talk | contribs) 19:13, 5 December 2006 (UTC)

When you enter a year in the field "established_date", the template will automatically place the article in the category "xxxx establishments" if that category already exists. For example, according to the New York City article, the New Amsterdam settlment was founded in 1613. So I entered ";established_date = 1613" and now the article is automatically listed under "1613 establishments". At the moment, it is listed under the value given for "official_name" (City of New York) instead of the page name (New York City). Which is better? It is necessary to have the "if that category already exists" condition in case something other than a year (or a wikiliked year) is given - otherwise you get funny results. - 52 Pickup 08:56, 6 December 2006 (UTC)
Good - so it won't break if I've already entered XXXX establishments as a category on the page, or if I've wikilinked the year already. Kewl - nice job! -- SatyrTN (talk | contribs) 15:29, 6 December 2006 (UTC)
No, it shouldn't break - I hope we ironed out most of the problems when implementing it in Infobox Australian Place. If the wrong thing is added (ie. a full date including day and month), it should simply do nothing. If the category has been explicitly entered, it should also do nothing. There are a heap of other auto-categorisation things that can be done - for example, we have the Aussie infobox to assign cities to "Cities in {{{state}}}" - but this probably shouldn't for such a global template as this. - 52 Pickup 15:54, 6 December 2006 (UTC)
Does this only work with "established_date"? Or does it also work with "established_date2" and "established_date3"? -- SatyrTN (talk | contribs) 23:06, 8 December 2006 (UTC)
At the moment, only with the first one. Changing it to work for the others is possible, but I'm not sure if it should be done for all of them. - 52 Pickup 10:31, 10 December 2006 (UTC)

[edit] It is really screwed up

I do not know exactly what to do or say about it but with the recent edits, This template has been screwed up. The edits of this template effect wikipedia drastically and should not be taken lightly. The edits may work on some articles but not on others. If a coat of arms or logo section works better for some areas, great, but it should simply be set as optional to either have one of the three (coat of arms, logo, or seal) or somthing similar. The current format streches out the template really badly and without other images that some cities don't have, It looks shotty.

Simply, all I am saying is that it needs to be fixed. --MJHankel 00:38, 9 December 2006 (UTC)

I think I've fixed it. I've got all posibilities of flag,logo,seal,and shield tested. See User:Salix alba/sandbox. --Salix alba (talk) 01:09, 9 December 2006 (UTC)
Almost... The original thing I was trying to fix (and I'm totally sorry for messing it up!) is an extra space that's showing up after the seal/logo/flag/shield section. On the Salix alba test page, take a look at numbers 6, 8, 11, 12, and 15. -- SatyrTN (talk | contribs) 01:31, 9 December 2006 (UTC)
Yes I see. Feel free to mess on the test page, it uses a copy of the template to changes there won't have a big hit on the server. --Salix alba (talk) 01:36, 9 December 2006 (UTC)
Indeed. I believe there is a syntax error, which I tried to fix with this edit, but it got even worser and I reverted. This is indeed a real mess. --Ligulem 12:43, 12 December 2006 (UTC)
ok. Got it "{{!}}}" expands to "|}" which closes a "Manske" wiki-table. Still, if you copy the call from Charlestown, New Hampshire into Special:ExpandTemplates and let it expand, you will notice that you get a truckload of empty lines inside the wiki table syntax. This produces vertical space as can be seen on Charlestown, New Hampshire. I strongly suggest to convert this mess here to html syntax (example: Template:Infobox Politician). This here is way over the complexity level to manage the wiki-table syntax quirks on top of everything. One of which are that line feeds are syntax elements. --Ligulem 13:25, 12 December 2006 (UTC)



[edit] Infobox City question...Extra spaces

The following discussion was copied from MJCdetroit's talk page archive. It led to the solution that was saved at about 03:09, 8 January 2007 (UTC)

Hi, MJCdetroit. Got a question for you: Do you see a difference between Charlestown, New Hampshire and Wikipedia:Sandbox/Infobox City2? I see an extra space under the Town Seal on the first one, but not on the second one. The really weird thing is I can't see a difference between the two templates - (respectively) Template:Infobox City and Wikipedia:Sandbox/Infobox City. If you have a moment, would you take a look and see if you can figure out where that extra space is coming from? Thanks!!! -- SatyrTN (talk | contribs) 23:56, 8 December 2006 (UTC)

I took a look at it, but I don't have much time. I'll play with it some more later. —MJCdetroit 19:25, 10 December 2006 (UTC)
Ok the problem seems to occur when either |image_flag = or |image_seal= or both are entered without the other two images. It does not occur when either of the other two images are entered; not when they are by themselves or entered with the flag and seal (all 4 together). It looks like when the |image_flag = is enter by itself the problem gets even worse. The solution that you came up with (Wikipedia:Sandbox/Infobox City) will not work. Look what happens when there are more than one image: Wikipedia:Sandbox/Infobox City2. I tried messing with it a little in my Sandbox but without any luck. I am just not sure as to why it does that. I'll see if someone else can look at it. —MJCdetroit 01:26, 12 December 2006 (UTC)
My Template Sandbox and how it displays ——MJCdetroit 01:38, 12 December 2006 (UTC)
The issue seems to be blank lines generated in the table from the #if's for the parameters that aren't provided. I've tried a couple of workarounds which don't seem to work. I'll get more help. -- Rick Block (talk) 02:36, 12 December 2006 (UTC)
Rick, MJC - you guys are awesome :) -- SatyrTN (talk | contribs) 05:13, 12 December 2006 (UTC)
Seeing what progress we are making, I also asked 52 Pickup to take a look at it.—MJCdetroit 13:20, 12 December 2006 (UTC)
One possible cause of the problem is the use of {{border}}. You get a lot of funny alignment problems when using that. Since only image_flag currently makes use of this border, this is perhaps why there are extra problems when image_flag is involved. For example, {{border|[[Image:Flag of France.svg|30px]]}} [[Image:Flag of France.svg|30px]] → . Until border is improved, it shouldn't really be used. There might be something else causing problems, I'll keep looking. - 52 Pickup 13:51, 12 December 2006 (UTC)
I'm certain border has nothing to do with it. I asked user:Ligulem to take a look, his response is at Template_talk:Infobox_City#It_is_really_screwed_up. It won't talk long to make a version of the inner table using HTML table syntax which will fix the immediate problem. Mixing HTML table syntax with wkitable syntax is not generally recommended, so we might want to consider converting the entire thing to HTML syntax. -- Rick Block (talk) 19:57, 12 December 2006 (UTC)
The version in MJC's template sandbox now uses HTML for the inner table. I think the extra vertical space issue is fixed, but if there's only one of flag or seal it's left aligned in the top row (this is fixable as well). I need to get back to work at the moment, but will take a look later to see how things are going. -- Rick Block (talk) 20:10, 12 December 2006 (UTC)
Hmm - maybe not fixed. Take a look at Wikipedia:Sandbox/Infobox_City2. That's the exact information from Charlestown, New Hampshire, but using the template from MJCdetroit. -- SatyrTN (talk | contribs) 21:46, 12 December 2006 (UTC)

So, what's the current state of this? I tried some changes today that didn't seem to help. Is this simply still pending a fix? -- Rick Block (talk) 04:22, 23 December 2006 (UTC)

Well, I made a stab at table-fying the template and think I've got it somewhat down. The "somewhat" is because I didn't do the fancy bit that would always put two on a row. In any case, take a look at Sandbox/Alpha2, where I have an example of each possible combination of Seal, Flag, Coat of arms, and Logo. Let me know what you think, and if someone with more experience with #expr wants to do the fancy bit, that would be great! -- SatyrTN (talk | contribs) 14:48, 25 December 2006 (UTC)
Sorry, I've been a little M.I.A. lately with Christmas and all and I'll continue to be for about another week. However...
I took a look at the Sandbox/Alpha2 and I am sure that someone will complain about the single images "stacked" on top of one another when for example an instance of Seal and Coat of arms ocurres. I think that the single images and the 3 and 4 images look great. It seems that this is the best so far. I would be in favor of going live with this.—MJCdetroit 21:34, 26 December 2006 (UTC)
Are Rick or 52 Pickup reading these? Maybe they could clean up that last issue? -- SatyrTN (talk | contribs) 22:27, 28 December 2006 (UTC)
I'm reading, but haven't looked at fixing it yet (I'm still puzzled by the "extra space" issue). The code to fix it has to decide whether a new row is needed after the 2nd image (if both the first two images are there) and after the 3rd image (if two of the first three images are there). This shouldn't be terribly difficult. I'll take a look sometime soon. -- Rick Block (talk) 23:52, 28 December 2006 (UTC)
Thanks, Rick! I knew the logic that should be used, but am too inexperienced in wiki coding to have done it. The extra space seems to have come from some combination of the wiki tables and the code. -- SatyrTN (talk | contribs) 00:28, 29 December 2006 (UTC)
Sorry, been caught up on other things lately...
Going from SatyrTN's work, I've put up a modified version at User:52 Pickup/Template Sandbox2 which might solve the problem. Since the only problem now was what to do when there are only 2 images given, the template first checks if there are any images at all, then checks if there are exactly 2. If there are 2, then it creates a single row of 2 elements and fills the first one by checking for the presence of flag-seal-shield-logo (in that order). To fill in the second element, it checks these elements in the reverse order (logo-shield-seal-flag) - this way, nothing is duplicated. After this, the only options left are if 1, 3 or 4 images are given, which are already nicely handled by SatyrTN's version. All possible combinations are shown at User:52 Pickup/Alpha1.
To help get more people involved in helping with such infobox issues, do you think it would be worth forming something like WikiProject Infoboxes as a place for infobox developers to come together and help each other? Just a thought.- 52 Pickup 08:23, 29 December 2006 (UTC)
Wow - very nice! I wouldn't even have thought of doing it that way! Which is a good argument for having a WP:PI... :) Thanks very much! -- SatyrTN (talk | contribs) 15:41, 29 December 2006 (UTC)
Looks perfect! —MJCdetroit 15:42, 1 January 2007 (UTC)

[edit] January 8th upgrade

I've saved the changes 52 Pickup created to the template today (around 03:09, 8 January 2007 (UTC)). It looked ok to me but if not we can always revert it. It seems to have fixed the extra spaces at Charlestown, New Hampshire. —MJCdetroit 03:09, 8 January 2007 (UTC)

[edit] Some suggestions for this template

Do you really have to indicate the area of a city? I mean, many cities in the world don't have official city limits, and even more cities have an "unknown" area. And shouldn't there be a possibility to write the denonym of the citizens??? --Escondites 19:07, 13 December 2006 (UTC)

[edit] Tiny font

Why the tiny font? Think of the sight impaired. I believe we should use normal fonts everywhere on Wikipedia without exceptions. /81.170.235.234 13:14, 17 December 2006 (UTC)

It's not a fixed size so users can increase the physical size of the characters using their browsers settings. --MattWright (talk) 15:28, 17 December 2006 (UTC)
And you believe that everyone knows how to do that? Escpecially the elderly who have just got their first computer with an internet connection? I don't get why it's so important with a smaller font size. /81.170.235.234 22:43, 17 December 2006 (UTC)
Because the average Wikipedian is in the twenties and thinks a webpage should look like coming out of a printer? :-). I completely agree with your complaint, but I have given up nagging about small fonts on this wiki. The majority here wants those (bad) small fonts, I was told. --Ligulem 23:16, 17 December 2006 (UTC)

Yes, and how about replacing ² (superscript 2) with <sup>2</sup> everywhere it occurs in the template? On many screens the font superscript 2 or superscript 3 looks like a flyspeck and the two are indistiguishable. Sometimes it is possible to infer that the funny-looking blob on the screen is a superscript 2 from the context. Here's how the three available versions look:

  • ²
  • &sup2; = ²
  • <sup>2</sup> = 2

See the difference? And, no, don't tell me to adjust the font size setting in my browser when 99.9% of what I see on the Web looks fine, just not those ridiculous tiny superscripts on Wikipedia. —QuicksilverT @ 00:12, 29 December 2006 (UTC)

Can you give an example of where that is showing up? -- SatyrTN (talk | contribs) 00:31, 29 December 2006 (UTC)
There are several instances of the UTF-8 superscript 2 in this template. You have to view the template code in edit mode to see the occurrences. It probably got in there because it is one of the special insertable symbols that shows up in the box below the editing window in Wikipedia. —QuicksilverT @ 01:16, 29 December 2006 (UTC)
The reason(s) I asked for an example are that a) I just went through the whole template re-writing some of the tables and I don't remember seeing the superscript for anything, and b) doing a quick search on the code doesn't reveal any instance. If you show me a page where it shows up, I can find it in the code much easier. -- SatyrTN (talk | contribs) 06:39, 29 December 2006 (UTC)

[edit] Fix coordinate clashing with donation box

Would adding a <br /> to be transcluded before the entire template or adding the br before

{{#if:{{{latNS|}}}| ! colspan="2" style="text-align: center; font-size: smaller; {{#if:{{{image_map|}}}|padding-bottom: 0.7em;|border-top: solid 1px #ccd2d9;}}" {{!}} Coordinates: {{#if:{{{lats|}}} | {{coor dms|{{{latd}}}|{{{latm}}}|{{{lats|0}}}|{{{latNS}}}|{{{longd}}}|{{{longm}}}|{{{longs|0}}}|{{{longEW}}}|type:city}} | {{coor dm|{{{latd}}}|{{{latm}}}|{{{latNS}}}|{{{longd}}}|{{{longm}}}|{{{longEW}}}|type:city}}

fix the clashing issues? Ddcc 05:10, 22 December 2006 (UTC)

[edit] Appearance

Why did it change its appearance? It looked so organized and nice before, now it looks akward and disorganized? El Greco 20:21, 24 December 2006 (UTC)

Did something happen to the CSS? -- SatyrTN (talk | contribs) 22:29, 24 December 2006 (UTC)
It appears so as all templates (infoboxes) which use the CSS classes "infobox" and "geography" seem to be affected. Caroig 22:41, 24 December 2006 (UTC)
User:Ed g2s edited MediaWiki:Common.css: [2], [3]. I've reverted his last edit [4] as I couldn't find discussion/consensus for removing CSS classes that are in use on prominent templates like this here. You might want to comment on MediaWiki talk:Common.css#Removal of geography related classes. --Ligulem 23:32, 24 December 2006 (UTC)
Thanks Ligulem --El Greco 00:09, 25 December 2006 (UTC)

[edit] Red dot on blank map

Some infoboxes have started to use a generic blank map with a superimposed red dot to show the location of a city, circumventing the need for location map images for every city. Over on the German wiki, someone has come up with a neat way to achieve this, a way that I have not seen on the English wiki. The template de:Vorlage:Infobox Ort in Deutschland makes use of a standard blank map of Germany and requires only the city's geographical co-ordinates to present the final map. This is achieved by an internal template which performs all the necessary calculations to place the dot in the right place. Pretty clever, I thought.

I have put up an English version of this infobox at {{Infobox German Location}}, which also refers to this internal template, known as {{Lageplan}} (directly copied from the German wiki). The reason for a separate infobox for German cities comes from the desire to directly import infobox data from entries on the German wiki (which is why most variables still have German names) - but I have added a few extra features and changed the appearance to something more like Infobox City. For example, see Cologne.

Perhaps something like this could be used in this infobox. For this, the user would need to pick a map from a set of default images. And the Lageplan template would need to be generalised. Worth a thought. - 52 Pickup 18:49, 6 January 2007 (UTC)

But what about if you want to color/highlight in the region where the city is located? El Greco 20:47, 6 January 2007 (UTC)
Unfortunately, that doesn't work. So this probably won't be possible for most cities in US/Canada, for which many segmented maps have been made. But for locations in other countries, this could save a lot of work. - 52 Pickup 21:13, 6 January 2007 (UTC)
I tried something like this in Infobox:City, but it kept getting reverted by people who weren't interested in learning how it worked. It is hanging on in places like Groveland, New York which don't use Infobox:City. It is implemented in Template:GBNewYorkState. PAR 21:27, 6 January 2007 (UTC)
There's also a thread on this at http://en.wikipedia.org/wiki/Template_talk:Infobox_City/Archive_2#Pin_coords_parameter. -- Rick Block (talk)
Where do you get the map, to use for the red dot? Cause some of the maps, I've seen look very nice. Take Paris or Alexandria for example. I might be interested in a better map of Greece, to use for some Greek cities which is why I'm asking. El Greco 18:01, 7 January 2007 (UTC)
The best place to find such maps would have to be the Commons - then you would need to do a few calculations to calibrate the map to suit the co-ordinate range involved. For Greek locations, someone has taken the Lageplan template and applied it to {{Infobox Town GR}}. For example, see Heraklion. It's a shame that this approach had previously been reverted for this template, perhaps now is a good time to retry it. - 52 Pickup 13:47, 8 January 2007 (UTC)
Thanks for the assistance, 52 Pickup. El Greco 18:20, 10 January 2007 (UTC)
Once you have a map, you then need to come up with the mathematical equation that corresponds the geographical co-ordinates to the location on the map (in terms of a 0-100% scale in each direction). This is the tricky part. - 52 Pickup 08:25, 11 January 2007 (UTC)

[edit] flag and seal captions

The flag image appears to have automatic text caption of the form "Flag of {the page name}", even if the image exists and has a different title. What is the purpose of this bit of text? Same for the seal. First noticed on Providence, Rhode Island, but it appears to be consistent(ly weird) on many pages. DMacks 20:00, 22 January 2007 (UTC)

This issue was first brought up in October in the Some issues heading above. I think (but I'm not positive) that the links were placed in there to encourage editors to create articles about the flags and seals if there was not an article present. The problem that you touched on gets even weirder when the official name is not the common name (i.e. City of New York, City of Toronto). I would not be opposed to just removing those links all together. —MJCdetroit 20:49, 22 January 2007 (UTC)
I finally fixed this quirk. Unless the following fields have values (i.e. some other wikipage) filled in then the caption will not be linked. This is not an automatic link it must be filled in manually.
|flag_link=
|shield_link=
|logo_link=
|seal_link=
See Toronto for an example. —MJCdetroit 01:32, 27 February 2007 (UTC)

[edit] Automatic Unit Conversion

Just so everyone is aware, the concept of adding automatic unit conversion from metric to imperial has been proposed as a feature request for the wikimedia software. The feature discussion would benefit from participation. Alan.ca 12:57, 23 January 2007 (UTC)

This has been used on other templates like Template:Infobox Former Country very well. However, as I explained on Alan.ca's talk page, it maybe a lot of work to implement. We'll just have to weigh out how much work it would be and then decide if it is worth it. —MJCdetroit 16:20, 23 January 2007 (UTC)
  • As an initial step to automatic conversion, I implemented a population_footnotes field to separate the footnotes from the population values. Check out {{Infobox City}} and let me know what you think. I implemented the change in the Hamilton, Ontario article. Alan.ca 12:07, 23 January 2007 (UTC)
Yes, there already is an automatic conversion for this exact thing and it works very well with a new template. It has been very successful over at Template:Infobox_Former_Country. The problem with infobox city is that it is an old and very used template. In order for this to work you would need to have the fields (in this case km2) entered in without any puncuation, no commas, no spaces, nothing. Some of the U.S. Cities have sq miles entered in before the square kilometers; i.e. this is on one line, in one field total area. If everything is not perfect, then you will get an error expression. Also, the numbers in the fields would be automatically formatted with a comma every three spaces and some people prefer a space and visa-versa. Due to the amount of pages that use infobox city template, changing the total area field to no punctuation and only km2 may be more work than it is worth, but it is worth a look. —MJCdetroit 15:47, 23 January 2007 (UTC)
Follow-Up: There are about 3,500 pages that use the infobox city template. If a small group of editors were to prep all those pages, then the the automatic conversion could be installed very easily. By prep, I mean removing any punctuation or superscripts or anything that is not numbers from the desired field. For example if total_area= 11,000 then it would have to be changed to 11000. Editor comments seem to be OK. It is not the template but the prep work itself that would be the hard work. I don't know if AWB would be helpful in this either. I would probably take 30-40 second per page. I think in the long-run auto-conversion would be the best way to go. —MJCdetroit 21:30, 23 January 2007 (UTC)
Ultimately we would modify the template to only do the calculation if the corresponding unit field was empty while the other was provided. However, I'm not certain if there is anyway to check that the input is valid before rendering a conversion. Possibly there is a way to test that the conversion is correct before displaying it. This would allow us to provide nothing in the space if the conversion was unsuccessful. Alan.ca 22:12, 23 January 2007 (UTC)
I've started the slow process of changing the pages to accommodate automatic unit conversion. This involves removing any commas, spaces, and references from certain fields. For example, in some cities, square miles and square kilometers are listed on the same line (diff) and because it is the field intended for square kilometers the square miles were removed. Auto-conversion will put the square miles back in at a later date. If someone wants square miles (or density/sq mi) added back in before then they can enter them into the appropriate sq_mi fields. There's about 2,700 pages to check so some help would be great. —MJCdetroit 03:22, 27 January 2007 (UTC)
Please stop! This is not appropriate to remove English measurements in preference for metric and force someone else to clean up your mess. Removing conversion is against policy, is unfriendly and reduces the usefulness of articles. If it is worth doing, do it right. So it is right now and in the future. Don't create more problems for others to fix. Rmhermen 01:00, 12 February 2007 (UTC)
Rarely, have I removed any English/Imperial measurements that I did not put back in their correct fields (i.e. Total_area_sq_mi, Elevation_ft, etc). Here are a few examples: example example2 Example 3. If I did remove anything there was a reason for that and in about a week that won't matter because all pages will have both measurement systems displayed and you RmHermen will even be able to swap the unit order if you wish. I have editted close to 2,000 articles and have 800 left to do. At the rate that I am going, I will be done in about 4 days. Do you think you can wait that long? If you can't, and you have a metric only page, then read my instructions above and place the units back into the correct fields. I would have been done by now if AWB had a Macintosh version...P.S. As for preference...as my user page notes, I happen to prefer English measurements over metric.—MJCdetroit 05:32, 12 February 2007 (UTC)
OK, all the pages using this template (Infobox City) have been prepared for this so it should be a smooth transition.MJCdetroit 03:32, 18 February 2007 (UTC)

[edit] How it works

[edit] Calculations

For the area, population density and elevation fields, values can be converted and even placed in an order. For example many pages only have the metric values entered, automatic conversion will calculate the corresponding imperial values and display them in the infobox. The reverse is also true. Many U.S. pages only have the imperial values entered, automatic conversion will calculate the corresponding metric values and display them too. The calculations will work as long as the values are raw numbers only; no commas or spaces or reference tags. Editor notes (<!--Ed note:-->) are ok. The template will format the numbers displayed in the infobox. There are reference fields (area_footnotes & population_footnotes) if a reference is available; use the <ref name=>Your reference here </ref> tags. If both metric and imperial fields such as area_total =259 and TotalArea_sq_mi = 100 are filled in then both values will be displayed regardless if they are correct or not. This overrides the automatic conversion and can be helpful if the value is a range (see next section).

[edit] Elevation ranges

If one value in one of the elevation fields is entered correctly then automatic conversion will convert it and display it. However, if a range is entered such as elevation_ft= 33&ndash;330 '''or''' elevation_ft= 33-330 then automatic conversion will try to convert it but will either generate an Expression Error or will convert it incorrectly base on the - (minus sign). So in this example above:

elevation_ft= 33&ndash;330 will generate this error when trying to convert to meters:
(Expression error: Unrecognised punctuation character "&" m)
However: elevation_ft= 33-330 will generate a negative conversion:
33-330 ft (-67.6 m)

When an editor wants to display an elevation range for a city then they must enter the ranges in both the fields like this elevation =10&ndash;100 elevation_ft=33&ndash;330 . This will over-ride the automatic conversion and display the fields correctly in the infobox.

[edit] Unit order

Cities in the United States that have the United States (or some variation of the name) in the field subdivision_name=, will automatically have the unit order switched to imperial first then metric in parenthesis as suggested by 52 Pickup below . However, not all pages have the country name in the subdivision_name field (sometimes it was state name or county). Therefore, if a page is metric first and an editor would like imperial first then metric, they can add unit_pref=Imperial (or English, etc) and the units will flip-flop. Leaving unit_pref blank or entering Metric (or SI) will display the metric units first if the subdivision name is not United States.

I hope that was clear, but any question or errors happen this is the place to post 'em. —MJCdetroit 03:32, 18 February 2007 (UTC)

[edit] Location map

I have tried to use {{Location map}} in this template but have not been able to. Could someone correct this? --Eleassar my talk 16:06, 23 January 2007 (UTC)

[edit] Proposed changes to support the Location map template

Due to popular demand, I've prototyped some changes to this template to enable support for the {{Location map}} template. I've encapsulated the {{Location map}} template within the {{Infobox City}} template, and exposed two new parameters pushpin_map and pushpin_position which provide the map name and label position configuration for the location map, along with the existing mapsize, map_caption and latitude and longitude parameters of this template. You can see and test the prototype at {{Infobox City Maptest}}. An example of it in use is shown here: Template talk:Infobox City Maptest. The location map will only be displayed if the pushpin_map parameter is specified, and the existing image_map parameter continues to function as before. Please post your feedback here about these proposed changes... (MichaelJLowe 18:21, 23 January 2007 (UTC))

  • Does this feature really need to be part of this template, or should it be a separate template that is included inline by those who wish to use it? Not that I object to it, but it just seems this template is never ending as far as fields are concerned. Alan.ca 22:23, 23 January 2007 (UTC)
The main reason for including it as part of the city template is to avoid duplication and double entry of data fields - it uses the values from the existing latitude and longitude coordinate fields of the city template to position the pushpin, as well as the mapsize and map_caption fields. The customized city templates that people are creating to make use of the Location map template such as {{Infobox_Swiss_town}} and {{Infobox_London_place}} take the same approach. The alternative you suggest would still need the addition of at least one parameter to the city template, since the existing image_map parameter is not compatible with the approach {{Location map}} uses, and it would force users to double enter the latitude and longitude coordinate fields as mentioned. (MichaelJLowe 02:02, 24 January 2007 (UTC))
One thread above also asked about this feature. It would be great if the {{Location map}} template is supported, because it saves times to create a lot of city locator map images for thousands of cities. Otherwise, several projects chose their own city infoboxes, such as the {{Infobox India City}}, etc. — Indon (reply) — 09:13, 24 January 2007 (UTC)
As I am the one that asked about this feature above, I of course am waiting impatiently to see this implemented. My opinion is that many users already know how to use the {{location map}} so it would be most simple and convenient to just insert it in the image_map field and not to have to learn how to insert such data by using some new parameters. Of course, if someone uses this infobox a lot and doesn't know the {{location map}}, he would have more problems. However, let those that know it do this work. --Eleassar my talk 14:35, 24 January 2007 (UTC)
As I mention above, I don't believe it is possible to integrate it into the image_map field. Furthermore, as I also mentioned above I don't believe it is desirable. My proposed approach is identical to how {{location map}} is itegrated with other city infobox templates such as {{Infobox_Swiss_town}}, {{Infobox_London_place}} and {{Infobox India City}}. As far as simplicity is concerned, nothing could be more simple! With my changes, you need to specify only 1 parameter (pushpin_map - the name of the map) to get the location map to work - everything else is specified as part of the normal parameters of Infobox city. I think most people using Infobox city would not want to use two separate templates as you propose to get a simple map displayed. (MichaelJLowe 16:23, 24 January 2007 (UTC))
Ok, feel free to do as you like. Both ways are fine for me. --Eleassar my talk 16:38, 24 January 2007 (UTC)
The way you have set it up in the test template is very good. Nice and simple. The people who have worked on Location map have done very well in coming up with the right mathematical equations for each map (something i requested above, when i didn't know about location map).
For integration with image_map, perhaps you should first check for image_map, THEN go to the pushpin_map if no image_map is given. This should prevent disruption of currently used infoboxes. Using the {{Lageplan}} template, this is how {{Infobox German Location}} works (a separate template was needed for German locations, due to the need to transfer a lot of Germany-specific details from the DE-wiki). Lageplan has also been implemented at {{Infobox Town GR}} for Greek locations. I have tested Location map on the German infobox here and compared the two versions at User:52 Pickup/Drafts/Frankfurt. From the comparison, there are some other features of Location map that should be editable to make it suitable for this infobox instead of using Lageplan. The following list is from my post on the Location map talk-page, but has been copied here for completeness:
  • Border: Is there any way to turn off the image border? It is alright for some cases but, as you can see, not for this one
  • Error: Instead of shifting the dot off the edge of the map if the co-ordinate values are either not given or out of range, would it be neater to have some sort of error display? In Lageplan, a second map can be displayed (DE: Image:Missing Map of Germany.png, GR: Image:Prefectures Greece nocoord.png). So either the addition of a second error image or the overlaying of a question mark image would look better.
  • Dot size: (a minor issue) Can the size of the dot be adjustable?
  • Floating text: (another minor issue) Can the float text be modifiable? Also, Lageplan makes it possible for the dot to also have float text of its own
A final thing: Maybe you should not have the city name present on the map as well (i.e. blank the "label" field), but that's just me. - 52 Pickup 08:59, 25 January 2007 (UTC)
Based upon your feedback 52 Pickup, I've made two changes: (1) the border is no longer present around the map. I think the border should be contained in the map image itself if it is needed. (2) I've added an option to the pushpin_label_position parameter called none which allows you to turn off the label text. The options for pushpin_label_position are therefore left, right, top, bottom, none. Your other comments are more related to the features of the Location map template I think. I've therefore now added the pushpin map functionality to the Infobox City template. You can see an example of it in use here: Padang, Indonesia (MichaelJLowe 15:09, 25 January 2007 (UTC))

[edit] WP:CCT Project

Hi! We're discussing the best way we can add the Current City Time CCT to articles. One of our suggestions is to have a main site where the time would be purged and updated. I had a suggestions where it places a link to the category:UTC-1 or whatever the UTC is and then we could link those categories to the articles UTC-1, UTC+0, etc... Any other sugestions. --CyclePat 20:48, 25 January 2007 (UTC)

[edit] Whitespace

This template creates a white space in first line of articles, see Ahvaz for example. Anyone know how to fix this? Khoikhoi 06:33, 27 January 2007 (UTC)

I'm not seeing any difference in the position of the first line of text between articles that use this template and those that don't (at least not with monobook or classic skins using Safari). What skin/browser/OS are you using? -- Rick Block (talk) 22:06, 28 January 2007 (UTC)
Firefox in OS X. I noticed the whitespace again, but when I reverted CyclePat, it disappeared. To Pat: can you please make edits in a sandbox for now? Once they work, feel free to implement them. Thanks, Khoikhoi 08:59, 30 January 2007 (UTC)

[edit] Request for change in behavior of displayed units

I don't know if this is even possible or not, not knowing the internals of this thing, but I have a request: would it be possible to change the template so that either metric or non-metric units would appear first (say, total area), depending on which one was specified first? As it stands now, the default is to display metric units first. This is inappropriate for US cities, where US readers would normally expect to see areas displayed in square miles, not square kilometers.

Any chance of this happening? I understand it may not be technically possible, but it would be a nice amenity, as well as a recognition that the whole world doesn't measure in metric units. +ILike2BeAnonymous 05:05, 28 January 2007 (UTC)

I think some users are working on automatic unit conversion (discussed above), and if this is the case then I think it would be easy (and desired) to put the unit which is supplied first, and the auto conversion value second. --MattWright (talk) 05:54, 28 January 2007 (UTC)
I've created a set of templates that are used within Category:Geobox templates, the existing conversion templates are to be found at Category:Unit display. They automatically convert the figure into its metric/imperial counterpart and print all necessary links. The value from which the other one is calculated gets printed first. The only drawback is the input must be unformatted (i.e. without commas). Check it e.g. on the Vltava (metric values provided) and the Salem River (imperial values provided). – Caroig 09:03, 28 January 2007 (UTC)
To answer ILike2BeAnonymous' question: yes it is possible to swap the unit order. I provided an option for this at {{Infobox Weather}} by entering |metric first= yes. But first we'll take care of the conversion thing, then the order option. —MJCdetroit 16:15, 28 January 2007 (UTC)
Thanks. Glad to see the consensus seems to be that providing this flexibility in the template is a Good Thing. +ILike2BeAnonymous 21:33, 28 January 2007 (UTC)

[edit] CSS|XHTML: Size, Border and Background (Globally)

Hope a third time is a charm! I like to know if it's possible to globally change the width, border and background color of this template? I'm trying to match the border and background color to the city colors, and want to adjust the width of rows and columns, too. Doing so manually would be frightful to those who don't engage in web design. Is this template so hardcoded to not pass a simple style="" override?FResearcher 23:59, 29 January 2007 (UTC)

Based on your question at Wikipedia:Help desk I'm not sure I understand what you're trying do. First, are you talking about city articles at this wiki? If so, which ones? The point of the template is to provide a consistent look and feel to Wikipedia's city articles. If you're talking about articles at some other wiki, you can change the template to do whatever you'd like (and we might be able to help). Like I said at Wikipedia talk:Help desk, the background color and border should be fairly easy to change. The width is currently hardcoded in the template. Please provide some more details about what you're trying to do. -- Rick Block (talk) 02:12, 30 January 2007 (UTC)
My talk page has a living example. Want to replace the default gray color of the city box with the green border; green theader with white font of the tables below it. You can see there, long hand CSS is a mess just to substitute the basics. ADDED: If this city template would have more title/leader slots it would eliminate that whole commissioner/sheriff/coroner table. -- FResearcher 03:06, 30 January 2007 (UTC)
I'm still not sure I understand. Do you want to change the Augusta, Georgia article in this way? The additional table on your talk page is not in this article, so changing the Augusta article would make the table look different than the way it looks on the other 3500 or so articles that use it. I'm not saying this can't be done, I'm just trying to figure out what you're attempting to do. -- Rick Block (talk) 03:20, 30 January 2007 (UTC)
Correct me if I'm wrong, but I think he's saying a city in Kenya could have a different color scheme than a city in Chile. If there were a continent=asia parameter (or country=chile perhaps), then the CSS for the table could say <th class='infobox-city-asia'> and provide a different color scheme than <th class='infobox-city-north-america'>. -- SatyrTN (talk | contribs) 05:21, 30 January 2007 (UTC)
Sort of what what I was saying. It would be nice if we can have some custom color CSS options (green, blue, red, etc.,) so the box can be tailored to the city seals/flags, etc.. Doesn't have to be exact colors, just something close, with an option to change the background via a style override like this <class="infobox_drkgreen" style="background:#fff;">. CSS separates the presentation from the code, making it cleaner for non web designers to add/edit Wikis (none of the style code is shown in the rows, just content), and reduces page weight (length). Furthermore, the days we need to remain in programmer gray, let alone 16 safe colors ended when 16/24/32bit graphics came around 6 years ago, an eon in computing. --FResearcher 16:46, 30 January 2007 (UTC)
The style of the infobox matches the style of similar infoboxes for US states (template:US state, used in all state articles e.g. Georgia (U.S. state)) and countries (template:infobox country, used in nearly all country articles e.g. United States). This style is also used in a few other geographical infoboxes, as sort of a global "wikipedia" style (see Wikipedia:Geographical infoboxes). Adding the ability to change the "look" of this template for selected cities as you're suggesting goes in the other direction. I think this boils down to whether we want "article-specific" style or "site-wide" style. As the main proponent for Wikipedia:Geographical infoboxes (which I admit generated virtually no comments, and is currently labeled as "inactive"), I distinctly prefer "site-wide" to "article-specific". I'm willing to defer to a consensus for "article-specific", but I'm not seeing that (yet). -- Rick Block (talk) 04:35, 31 January 2007 (UTC)
Article wide or global, all I'm asking is the ability to edit the borders, background and width and not be depended on user css pages. The hardcode can stay as it is, just the CSS portion can have a manual CSS override. The default gray is depressing. --FResearcher 08:38, 3 February 2007 (UTC)
The background color is inherited from the CSS definition of infobox, defined in MediaWiki:Common.css. It's a site-wide default for all infoboxes. If you'd like this to be changed site-wide, I suggest you bring it up at MediaWiki talk:Common.css. Less globally, I'm not seeing anyone support your suggestion to make the background color of this infobox become a parameter. This is of course technically possible, but I would be personally opposed to adding such an option. My reasoning is that site-wide style parameters are meant to be site-wide, not customizable article by article. Similar reasoning applies the border style and the template width. -- Rick Block (talk) 17:37, 3 February 2007 (UTC)
As a more general question, though related, I was under the impression that wikipedia wouldn't let you put
<style type="CSS">.classhere {font-weight: bold;}</style>
in a page or template or anything. Is that true? -- SatyrTN (talk | contribs) 04:52, 31 January 2007 (UTC)
Right, you can't directly define a CSS style on a page (see Help:HTML in wikitext). You can define a CSS style in MediaWiki:Common.css or any of the skin-specific stylesheets (e.g. MediaWiki:Monobook.css) and then reference this style in a template or a page. The "infobox" and "infobox.geography" styles are both done this way (in common.css). If you're thinking about changes to these, please note that changes should be proposed on the respective talk pages first. -- Rick Block (talk) 05:17, 31 January 2007 (UTC)
Oppose, I like to see the same thing over the whole wikipedia. --Krm500 20:27, 3 February 2007 (UTC)

[edit] Problem with references

When you try to put a reference within the infobox, it doesn't work. Although it shows up in the references section, there is a mess of code in the infobox where the ref should be. For example, Federal Way, Washington. Any way to solve this problem? --Schzmo 00:37, 6 February 2007 (UTC)

I fixed it. Here's the real short version: One problem that I seen was too many "pipes". You only need them at the begining (preferred) or the end; not both. Also there is a special field for references. Compare the versions to see what I did. Thanks for letting us know.—MJCdetroit 01:01, 6 February 2007 (UTC)

[edit] Land area

Why does this template put emphasis for area on the metric system? It looks odd to see the area listed as kilometers, while miles is stuck in parentheses. Shouldn't there be an option to have it the other way around? TJ Spyke 09:30, 14 February 2007 (UTC)

There will be an option coming soon to change the order if desired. However, I think that I will leave metric as the default and yes I do know that there are more U.S. cities that use this template. —MJCdetroit 13:04, 14 February 2007 (UTC)
Why don't you set the template to first check what country the city is in, and then swap the values around if that country uses imperial units (US,UK)? This way, there is no option, giving all entries a uniform and logical appearance. - 52 Pickup 13:54, 14 February 2007 (UTC)
That's a good idea. TJ Spyke 06:54, 15 February 2007 (UTC)
  • However, Metric units are used in every nation in the world. This is an international encyclopedia and metric is clearly the more popular international unit. If a European is looking at two cities, one from Canada and one from the USA, it would seem to me that it would be sensible for the units to be formatted in a similar fashion. Alan.ca 07:59, 15 February 2007 (UTC)
    • It's not the standard here in the US, it would be like me going to an article about something in Europe and changing it from metric to imperial. The metric units would still be there (just in parenthesis). TJ Spyke 08:32, 15 February 2007 (UTC)

[edit] Bug - population

When there is no population as of parameter, footnotes are not shown. Rich Farmbrough, 10:35 14 February 2007 (GMT).

Can you provide a specific example? And are you talking about the population footnotes or the regular footnotes? —MJCdetroit 13:15, 14 February 2007 (UTC)

[edit] Option for manually corrected article links?

I have a problem with the image description of the seal of Athens since the template automatically uses input from the first parameter as part of the file name. Would it be possible to include a line to allow a manual input of the article name? One of the other infoboxes has this feature, but I can't remembed which one. If this is done, this possibility should exist for article names for both seals, flags and coats of arms. Valentinian T / C 00:21, 17 February 2007 (UTC)

[edit] Another version

Some time ago I created a geography related infobox framework with a few templates (e.g. Geobox River, Geobox Mountain Range) built from scratch. They have certain features such as consistent look, logically named fields, fully automated unit conversion, automated linking and also a version of automated location maps.

I've tried to design a template for Cities/Towns etc. using this system. Having been designed from cratch too it has somewhat more consistently named fields. However, for backward compatibility it also accepts (hopefully) all fields from the existing Infobox City template. So in most situations it can be applied simply by changing the template name to Geobox Town (or Geobox City, which is just an alias). I've started working on this template some time ago, in the meantime some of the issues it deals with have been solved in Infobox City independently too. More info at User:Caroig/Geobox_Town.

You can see the new template at Sandbox:Town. These are copied from existing pages using Infobox City, only the template name has been changed and commas from figures removed and when two values were present, either metric or imperial ones have been removed. If you're interested, you can try it out by simply changing the template name in any existing page (and possibly removing commas from all figures, which is being done on all pages anyway) and post any comments on Geobox Town. – Caroig 16:37, 18 February 2007 (UTC)

Maybe I am misunderstanding you but why would we need another version? We should try and have more of an effort toward using one standard template (this one) and start incorporating some of the smaller and not updated as much city templates into this one. Creating more templates seems like a move in the wrong direction.—MJCdetroit 17:38, 18 February 2007 (UTC)
The template is a part of an effort to unify all geography related infoboxes giving them the same look, same internal logic and consistent field names. Some time ago someone considerably changed the Infobox City template, returning some of the bugs that the previous version had solved, damaging the layout. As various users are adding additional fields they bring even more chaos (take the chaoticly named imperial versions of the fields). Infobox City was primarily designed for US cities, this template tries to be more universal, easier for a newbie user to fill out (e.g. by defining default labes for Country, Region etc. - no need to fill the type in).
The suggested template tries to bring logic into the field names, solves some issues on a more general level (not footnotes someplace but a consistent _note field for everything etc., universal unit conversion) and also tidies the layout which is similar to the existing one, just somewhat neater. It is fully backwards compatible with the Infobox City, accepting all its fields as aliases to the suggested ones. See further info at User:Caroig/Geobox_Town. My primary target are landscape-feature oriented infoboxes, but I've tried to help here too. – Caroig 00:30, 19 February 2007 (UTC)
Actually, Template:US City infobox was designed for US cities and was replaced with this template though a standardization process led by User:Harpchad (who fell off the face of the Earth shortly after); archived discussion here. His user page still has the list of templates that were to be consider for replacement.
I agree that we should probably tried to have better named fields; for example "total_area_km2" and not "area_total" and "sq_mi" on all the imperials and not "mi2". But naming aside, as long as they display properly and look nice...
What are some of the "bugs" that were re-introduced (hope I didn't do that)? —MJCdetroit 17:28, 21 February 2007 (UTC)
I'm really not trying to force anyone to use the other version ... I created a framework with templates for nature elements (rivers, mountains, ranges, protected areas) in a unified style (which was inspirated be Infobox City) and beacause I think it has certain advantages I made a version for Towns/Cities too. I'll try to apply it on Czech and Slovak settlements as they use quite a few various templates but I'm not planning to use them anyplace else (I prefer editing articles on places in my geographic area). I put quite an effort into making the template backwards compatible with Infobox City while also making it more general, more usable for smaller settlemnts.
It's no issue with existing infoboxes how the fields are named, the chaos in field names is rather discouraging for those who wish to use the template on a new location. The Geobox system aims at being as user-friendly as possible.
As of the bugs that had been introduced, I didn't mean your edits but a larger one some time ago (half a year or so …) when somebody completly revamped the internals of the infobox which, at that time, was pretty fine-tuned. That revision returned many issues (well, not exactly bugs) that had already been dealt with (e.g. unnecessary red links on flags etc.) Since then, many of these have been solved again, I guess mainly by yourself. My post had nothing to do with your edits, I was working on the template for some time while you were improving Infobox City as well. I simply thought and think my Geobox had something to offer too, it's a free project so anyone can use it, change it, use parts of it … E.g. it already has some free fields which the next posts asks for. – Caroig 20:38, 21 February 2007 (UTC)
Yes the "red links" in the flag etc are terrible and should be the next thing that is removed. —MJCdetroit 02:52, 22 February 2007 (UTC)

[edit] Merge with Geobox Town and perhaps rename to Infobox Place

I would suggest that we merge the two so that they don't compete against each other.—MJCdetroit 01:59, 4 March 2007 (UTC)

[edit] Longer reply

Well, yesterday I removed all support for the field names from Infobox City as there seemed no interest in that. Its much easier to maintain the code now. Geobox City is a part of a larger series of coherently named and formatted "Infoboxes".

To be sincere I started Template:Geobox Town as I was unhappy with the situation around Infobox City. As I wrote some time before, I stopped using this template some time ago when someone complete reworked its code (I probably wouldn't find the edit now, it was when someone replaced the wiki table syntax with the classic HTML tags), broke the layout and reintroduce too many bugs or issues that had already been solved. And people still keep adding haphazardly named fields which often broke other things. Sorry MJCdetroit, I see you're trying hard to bring some other here but others do their changes too and not always to the best.

To put it in a nutshell, all Geoboxes use the same field names and internal logic, there's always a fieldname which can have modifiers attached. All unit related fields can have _imperial and _unit and _round attached, some fields (where it makes sense) have _type to change the default label (there's always one default value so there's no need to define the label, take mayor – most towns cities in Europe have just mayors, so I don't need to define that, the same applies for coutry, region, postal code etc. but if you need you can still "retype" the label). Most fields have also _note, a field for various notes, references etc. Not only this is easier for a user, there's no need to include those additional fields in a blank template and some day, hopefully, more advanced syntax will be introduced to the Mediawiki software enabling much easier code – there would be a subtemplate which would have the name of basic field as a parameter and the rest will be done automatically. Well, this could be achieved even today but with the current syntax it doesn't seem that useful. The Geoboxes have also a flexible location map system, which allows input data in either the classic way (deg, min, sec) or just positive/negative decimal numbers, the placement of the locator dot can be achieved in two ways, either fully automatically based on coordinates or seme-automatically using relative coordinates of the dot when the former is from various reasons not possible (conical projection, map with an inset).

You can see all the various Geoboxes e.g. here:

The Geoboxes series is just something new, with a new approach. They offer very consistent sytem of template for geography related "Infoboxes". They offer quite a few new things, their biggest disadvantage being they are not compatible with most existing "Infoboxes" – Caroig 08:56, 4 March 2007 (UTC)

This seems like a very good idea to me. Consistent parameter naming is a good thing - the current infobox suffers from internal inconsistencies and could use some refactoring. The geobox series seems to be well thought out, from scratch, so rather than refactor this one perhaps we should institute a project to convert the 3000 or so cities that use the "infobox" template to use the geobox template. -- Rick Block (talk) 15:26, 4 March 2007 (UTC)
Well, I added support for those fields from Infobox City even if it made the code much more complicated and difficult to maintain. I put the post on the talk page and waited if anyone tries to switch an existing page Infobox City to the Geobox. No one has ever done that so I decided to remove that feature. The support for these fields was added mainly to let people try out the new template as painlessly as possible.
Meanwhile, I finished a "beta version" of a new template in the series Geobox Region, same style, same functions plus one new feature (folding subdivisions) which I might, in some way, implement here two. I still keep this page in my watchlist and follow the development here (recently I added support for leader parties). So I'm not giving up here but I don't think reintroducing support for those old messy field names is a way to go. I've written a simple PHP script which helped me easily convert some existing Infobox City into Geoboxes. I did that only on articles from my country (where actually three or four different infoboxes are used). – Caroig 15:51, 4 March 2007 (UTC)
My suggestion was to Merge the two and use the best of both and to rename the template to Infobox Place (which redircts here now). How easy would this be? I think it's clear that there are things about the geobox templates that we like, otherwise we wouldn't be having this discussion. We should have project to somehow merge the two under the name Infobox Place and redirect others to it. That way we all can agree on a new final version before we unleash it. What do you think? —MJCdetroit 18:58, 4 March 2007 (UTC)
Well, but what do you exactly mean by merging? The previous version was "merged" in a way as it accepted all fields with their names from Infobox City. Geobox Town is a part of a still growing project of geography related "infoboxes" which all start with Geobox so I see no reason to change that name (it can be Geobox Place, sure), neither to change the field names which are coherent across the series, nor to change the internals which use common internal subtemplates. – Caroig 19:29, 4 March 2007 (UTC)
We should do our best to have one template with one look. If we chose to redirect to City to Geobox Town (or vise versa or new name) then we should all have our input into a new look and functionality. —MJCdetroit 20:00, 4 March 2007 (UTC)
I agree, however especially for towns/cities there's a special template for nearly every country in Europe and every one looks completely different … And all the Geoxes have very uniform look. I wouldn't enforce anyone to use neither of these templates. Just let the users decide … that's why I posted the notice about Geobox Town here. I simply see Infobox City like an old house, sometimes it is cheaper and more effective to pull it down and build a new one. – Caroig 20:28, 4 March 2007 (UTC)

[edit] Licence plate code

Many European countries specify location in car number plates (See European vehicle registration plates). For example, German number plates starting with "M" come from Munich, while Spanish ones starting with "M" are from Madrid.

Would it be possible to introduce such a field to this template? At the moment, Athens, which uses this template, has the licence plate code in the footnotes field. If this feature were to be added, more European locations could be better served with this template, making it more reasonable to use this template instead of creating more country-specific ones. - 52 Pickup 15:45, 21 February 2007 (UTC)

Sounds fair to me. Besides it would be optional anyway. We should probably think about adding some optional "blank" fields into the template. —MJCdetroit 16:59, 21 February 2007 (UTC)
The addition of some "blank" fields is a good idea - it gives the template greater flexibility. After the request for a new Polish location infobox in WP Infoboxes, it seems that replacing that template with this one is the way to go (discussion here). - 52 Pickup 10:31, 23 February 2007 (UTC)
The suggested Template: Geobox Town (99% compatible with this template) already has such fields, either in the section with postal_code and area_code, or in a dedicated free field section. – Caroig 10:40, 23 February 2007 (UTC)
The Geobox series of templates are brilliant, but we should work on combining them to have a single template. There are many nice features in the Geobox templates that should be imported here. - 52 Pickup 07:33, 26 February 2007 (UTC)
As I wrote earlier, I've put a lot of effort into making the Geobox Town template (aliased as Geobox City) accept the field names from Infobox City. So in most cases if you just switch the name of the template, Geobox Town will work perfectly, however the new field names are preferred. One of the aims of the project is to have consistently named fields across the series as well as consistent formatting of the ouput (done via many subtemplates) which may differ form the output of the Infobox City. (E.g. the first figure for area/population gets displayed on the same line as the label which produces just one line of data for settlements with just one figure for are/population). – Caroig 08:38, 26 February 2007 (UTC)
I tend to agree with 52 Pickup that we should try and implement what is good about the geobox template into this template and keep it at only one standard template. I think the field names should be changed a bit, but not in the exact same way as the geobox.—MJCdetroit 17:27, 26 February 2007 (UTC)

[edit] new field: political party of leader

It is possible that the infoboxes used for Dutch locations will be converted to Infobox City. One thing that the Dutch template has that this one does not is a separate field for the mayor's political party. Separating this from the name of the mayor would be very useful since then you could remove the need to wikilink the name - and set the template to check instead if an entry exists under this name. This would remove a few red links.
To help in this, I've been working on a new template {{Polparty}} where you enter the name of the country and the politcal party, and it gives you the correct abbreviation that links to the entry on that party. For example {{Polparty|USA|D}} = [[Democratic Party (United States)|D]]. To test it, I have modified the entry for Chicago. If the list of countries/parties is expanded in Polparty, this might make it a little easier to have the right political information. What do you think? - 52 Pickup 19:34, 25 February 2007 (UTC)

Following on from what i said yesterday, I have just set the leader_name fields to first check if a given entry exists, and modified the Chicago entry to demonstrate. Previously, this was given:
|leader_name = [[Richard M. Daley]] ([[Democratic Party (United States)|D]])
But now it is given by:
|leader_name = Richard M. Daley
|leader_party = D
And the output is the same as before - Richard M. Daley (D). Breaking it up like this (and removing the wikilinking) is IMO more user-friendly. Many fields should have this ifexist check in place. - 52 Pickup 07:58, 26 February 2007 (UTC)
IMO, autolinking like this is not a good idea. Red links are avoided by the ifexist check, but autolinking the content means if the name happens to correspond to an article it will be linked whether it's the right article or not. At the point of invocation of the template, the user should be free to link (or format the link) however they'd like. There are two issues that come up with the current version, one is names that link to the wrong article and the other is piping links so the presentation looks different from the link. Adding an explicitly formatted link fixes the latter issue, but if most uses of the template use auto-linked "plain" names how to do this will not be obvious. Requiring an explicit link requires 4 extra characters in the "plain" case, but shows (by usage) how to both include a non-linked name and a piped link. I'm all for making templates as smart as possible, but this strikes me as trying to make it too smart. -- Rick Block (talk) 19:07, 26 February 2007 (UTC)
OK, maybe autolinking the name is a bit much, but what about the new field for the party? That was the more important thing that I wanted to do here, as installing this is the main thing that will make it possible to convert the Dutch location infobox {{Infobox Dutch municipality}} to this one. - 52 Pickup 15:25, 28 February 2007 (UTC)
The party thing is a good idea. The only reservation I have about it is using the "subdivision_name" parameter as the combining tool. This is usually the country, but doesn't have to be. It'd be kind of a drag to update all the references (again), but I'd be more comfortable with the party idea if there was a parameter that was explicitly "country". -- Rick Block (talk) 01:19, 1 March 2007 (UTC)

[edit] Time to fully protect this template?

There are over 3000 pages using this template. Is it time for full protection? -- Rick Block (talk) 04:23, 26 February 2007 (UTC)

If that is the only reason. No. But if this pertains to my request because of alleged vandalism, then yes, of course with the prefered version supporting the new categories until the issue is resolved. I have attempted to add new auto-generated categories. Unfortunelly one of them, category:Cities in the UTC-5 timezone, is nominated for deletion. As you probably know, the recent changes to this templates undermine wikipedia's deletion process for categories, which is why I requested this page be reverted and protected. The manner at which you bring it up here doesn't quite please me because it appears to lack many of the afformentioned details. --CyclePat 04:40, 26 February 2007 (UTC)
It's related to the number of recent changes, yes. We generally don't protect to a "preferred version" (except in cases of obvious vandalism, which IMO this is not). Edit warring is very bad. Edit warring on a template used by 3000 articles cannot be tolerated. -- Rick Block (talk) 05:06, 26 February 2007 (UTC)
After manually checking and editing all 3,000 or so pages with the help of WP:AWB, I would be in favor of the protection. —MJCdetroit 15:02, 28 February 2007 (UTC)
Post Scriptum: Of course in the interest of development, we would have to have some type of a "test sandbox" for editors without access to play with. MJCdetroit 15:10, 28 February 2007 (UTC)

[edit] Link fixes

This edit adds parameters for flag_link, seal_link, shield_link, and logo_link (presumably to avoid red links where these articles don't exist). Requiring an explicit link parameter for these articles makes it completely unambiguous whether there's a link or not, and removes any forced association between the name of the city article and the name of the article about the flag (or seal or ...). Unfortunately, it also breaks every link that did exist (like some of the "Flag of" articles here). Another way to do this would be to make these links conditional on the existence of the article (the way the "leader" links are handled, above). Unlike in the leader case, I think it's actually appropriate to automatically link these (if the article exists). These are articles with names like Flag of Denver, Colorado, which are extremely unlikely to need disambiguation. I really think it would be a good idea for folks to start discussing changes to this template before making them. -- Rick Block (talk) 05:04, 27 February 2007 (UTC)

Sorry, my fault :(... The matter has been brought up here a couple different times recently. I do think making the links conditional on their existence would be better so I've reverted my edit. I think changing the way those links are displayed (or not displayed) will improve the template. —MJCdetroit 02:16, 28 February 2007 (UTC)
The only problem is getting people to comment might be worse than pulling teeth. I'd be happy to add ifexist checks for these. Unless anyone has some objection, I'll do this on Friday. -- Rick Block (talk) 02:32, 28 February 2007 (UTC)
Sometimes, you have to just edit and wait for a reaction...—MJCdetroit 14:59, 28 February 2007 (UTC)
Perhaps the additional fields can be used with the following if-format: {{#if:{{{flag_link|}}}|[[{{{flag_link}}}|Flag]]|{{#ifexist:Flag of {{PAGENAME}}|[[Flag of {{PAGENAME}}|Flag]]|{{#ifexist:Flag of {{{official_name}}}|[[Flag of {{{official_name}}}|Flag]]|Flag}}}}}}. This way some control can still be present in linking to the right page, red links are eliminated, and the previously-existing links will still work. - 52 Pickup 15:08, 28 February 2007 (UTC)
Maybe, but if not, I only added the new links to two pages before I reverted. —MJCdetroit 15:13, 28 February 2007 (UTC)
It is a good idea to have these extra link fields. I can't remember where, but I've seen pages which contain such flag/seal information that the template would not have been able detect otherwise. - 52 Pickup 15:18, 28 February 2007 (UTC)
Changed the template to reflect 52pickup's idea. It seems to have worked; see Lethbridge. —MJCdetroit 05:31, 2 April 2007 (UTC)

[edit] Nickname

Why is the nickname just floating between the location map and the flag and seal images now? That seems to be an odd place for it. Kaldari 19:46, 27 February 2007 (UTC)

[edit] Merging template

I've been thinking in merging {{Geolinks-cityscale}} and Establishment date categories into this template, please tell me what do you think. Thanks. --– Emperor Walter Humala · ( shout! · sign? ) 21:46, 2 March 2007 (UTC)

[edit] Master Databases with all City/Town Data for the United States

Does anyone have, know someone who has, or can tell me where I can find databases with all information needed to create infoboxes for every single city and town in the United States? I'm looking to do this in the next few months, but can't find a single source with all the needed data. Right now I'm considering writing a bot to read through every US town/city article and extract the data, but it would much better if I could just find a set master tables (ideally from government databases sitting out there somewhere). I'll also take any information available on counties, census designated places, and any other geographic division that might require infoboxing.

The information I would need is: Town/City name, County, State, population total, population density (per sq mi and per sq km), population date, area total (sq mi and sq km), area water (sq mi and sq km), area land (sq mi and sq km), elevation (ft and m), coordinates, time zone, summer time zone, zip code(s), and area code(s). Optional data would include nickname, motto, type of government, leader type, leader name, website, and any other important notes.

Please let me know if you have anything, and I'll be happy to start compiling it all into a giant Excel spreadsheet for future processing into infoboxes.

Note that this will only be done for cities and towns that currently lack infoboxes (though I could theoretically use it to fill in missing information in cities/towns already having infoboxes).

Thanks, --CapitalR 14:55, 6 March 2007 (UTC)

Maybe we can coordinate something with the UTC time project I tried to do which placed all the cities by time. Or Category:Geography by time. Unfortunatelly not everyone is as enthusiastic about that category but if we ended up making a program that could read through all the information that is on the pages to make a couple SQL like statement searchs into the wiki database on the information provide in the template:infobox city. This could be a another way around my pesky problem of anoying left winged conservatives that don't want to utilise categories. (A database!) Let's talk by email. --CyclePat 22:10, 6 March 2007 (UTC)

[edit] Bug Expression error

In Havířov article it shows up "Expression error: Unrecognised punctuation character" sentence in area parameter. - Darwinek 22:48, 6 March 2007 (UTC) It also shows up in the density field, see Frederiksberg for example. --Darwinek 00:14, 7 March 2007 (UTC)

It is actually not a bug. It happens because the numbers are not entered in a raw format; 24000 and NOT 24,000 or 24 000. The numbers will be converted and formated automatically by the template. I fixed them. See How it works Above for a better explaination. —MJCdetroit 01:06, 7 March 2007 (UTC)
A bit more on this - including punctuation causes the parser functions used to do the automatic unit conversions to fail. The template can neither detect nor automatically correct for this (given that m:StringFunctions are not installed here). -- Rick Block (talk) 01:11, 7 March 2007 (UTC)


[edit] Color for city

I don't really like the "colored" infobox header version. A graphic designer would be horrified. Please someone revert!.--((F3rn4nd0 ))(BLA BLA BLA) 07:20, 7 March 2007 (UTC)

Anyone else feel the same way? I placed a new version in the test template here. Take a look and talk about it. —MJCdetroit 01:35, 28 March 2007 (UTC)

[edit] Government section and blank fields

Actually, there isn't really a "section". It is just kind of there with the subdivision and the established dates. Therefore, I am going to separate it with a line and give it a section heading like Area and Population have. I think it will make the template look better, but if it makes you puke (like the name color) then feel free to revert it. Also, how about some blank fields for each section and the template? —MJCdetroit 02:27, 9 March 2007 (UTC)

Here's an example of where blank fields would be handy Template:Infobox London/Test. If noone objects, I'll insert them soon. —MJCdetroit 01:25, 15 March 2007 (UTC)
  • I'm in favor of a blank field in each section, as I have some uses for such fields in certain articles. Also, could someone look at Durham, Connecticut. Note that the "Government Type" field has a problem; the word "Type" in "Government Type" wraps to the second line, which is okay, but on the right hand side, the value "Selectmen-town meeting" starts on the same line with "Type" instead of the top line with "Government" (at least on my IE7). This should be examined and fixed. Thanks, --CapitalR 10:25, 18 March 2007 (UTC)
I added two additional blank fields. The fields are named blank_name paired with blank_info and blank1_name paired with blank1_info. This can be useful for cities in Europe that have license plates issued for that city. Example: Warsaw. —MJCdetroit 03:43, 25 March 2007 (UTC)

[edit] Geobox Town/City, Chapter Two

Hello, for those interested, a short update on the recent development of this template:

  • several issues concerning display of some fields (especially the maps) in IE7 have been solved
  • a set of fields dedicated to municipal parts has been introduced, there can be a pretty long list which upon the load of the page is "folded", see e.g. here: Pilsen
  • some fields can make use of the title HTML attribute (they're named field_label), i.e. a text displayed on hover (see Plasy and stop your mouse over Little District. This might introduced to all field labels.
  • the coordinates-related fields are more flexible now, they can be filled in in the classic format (deg, min, sec) or using the decimal format, with negative values for the Western and Southern hemisphere (the locator dot system works well with both systems too of course)
  • a secondary field for another map (without the locator dot system, just a plain picture) used e.g. here: West Chester, Pennsylvania - that Geobox makes use of a calibrated Pennsylvania State map so the locator dot is placed based on the coordinates
  • Geobox Town can be used together with Geobox Region when a region has the same name as the town/city and thus there's no need for a special page for that administrative unit (which would usuallly contain not much more than some statistical data anyway). Rather extensive use of the Geobox Region can be seen here: Pilsen Region, a combination of Geobox Town and Geobox Region e.g. here: Radnice. – Caroig 20:33, 11 March 2007 (UTC)
  • News as of 2007-03-16: if value auto is assigned to any population_density field, the actual density figure is calculated automatically from appropriate area and population values. – Caroig 19:42, 16 March 2007 (UTC)

[edit] Geographic coordinates with only degrees

Is there a reason (technical or otherwise) to not to support geographical coordinates where only degrees are listed? GR1 provides coordinates in decimalized degrees, without minutes and seconds. It make sense to enter this information directly without requiring a calculation that can introduce error or rounding that reduces accuracy. David H. Flint 07:19, 15 March 2007 (UTC)

For reference, on the technical side, it seems that the relevant change could be to replace

  <tr class="mergedbottomrow">
        <th colspan="2" style="text-align: center; font-size: smaller; padding-bottom: 0.7em;">Coordinates: {{#if:{{{lats|}}}
  | {{coor dms|{{{latd}}}|{{{latm}}}|{{{lats|0}}}|{{{latNS}}}|{{{longd}}}|{{{longm}}}|{{{longs|0}}}|{{{longEW}}}|type:city}}
  | {{coor dm|{{{latd}}}|{{{latm}}}|{{{latNS}}}|{{{longd}}}|{{{longm}}}|{{{longEW}}}|type:city}}}}</th>
  </tr>

with

  <tr class="mergedbottomrow">
        <th colspan="2" style="text-align: center; font-size: smaller; padding-bottom: 0.7em;">Coordinates: {{
  #if:{{{lats|}}}
        | {{coor dms|{{{latd}}}|{{{latm}}}|{{{lats|0}}}|{{{latNS}}}|{{{longd}}}|{{{longm}}}|{{{longs|0}}}|{{{longEW}}}|type:city}}
        | {{#if:{{{latm|}}}
                | {{coor dm|{{{latd}}}|{{{latm}}}|{{{latNS}}}|{{{longd}}}|{{{longm}}}|{{{longEW}}}|type:city}}
                | {{coor d|{{{latd}}}|{{{latNS}}}|{{{longd}}}|{{{longEW}}}|type:city}}
  }}</th>
  </tr>

I'd prefer not to make such a change myself, as I do not know the reasons for why it is the way it is now or what could break. David H. Flint 07:50, 15 March 2007 (UTC)

You might want to borrow the code from the Geoboxes, particularly the {{Geobox coor}} template which does the same plus it also accepts negative values for the western and southern hemisphere, see the examples. There's also the {{Geobox coor title}} template which accepts the same input values and prints the coordinates in the article title. Actually, you can use these templates directly. – Caroig 08:56, 15 March 2007 (UTC)
Those templates are pretty neat. Handling signed coordinates properly makes sense too, though I wasn't sure of the best way to do so. Why are there three versions of Coor templates anyway? I noticed the Geobox Town template though, and it actually solves several other issues that I have with the Infobox City template. I have switched to that, but have encountered two small issues which I will bring up on its discussion page. David H. Flint 19:05, 15 March 2007 (UTC)
I tweaked the template using the fix suggusted by Caroig. It seemed to work well in the Sandbox. What were the other issues that you have with the template? —MJCdetroit 03:20, 16 March 2007 (UTC)

[edit] Other issues

Thanks for responding so quickly to my problem. The other issues I have with Infobox City are primarily aesthetic. The biggest thing that made me a convert (besides the degree issue) is that Geobox Town does imperial<->metric conversion automatically, thereby eliminating a possible source of error. Another thing is the overall consistency of field names in terms of _type, _imperial and _note. Anything that makes the job of an editor easier should be encouraged. Both templates do their jobs adequately; I just think Geobox Town will be better going forward.
Of course, it would be nice if we could settle on one template, but a lot of the advantages of Geobox Town are only afforded by an outright adoption, and not a modification of Infobox City. Given that at least 5,000 pages use Infobox City, it is a decision that would need to be weighed heavily and garner broad support, especially considering the effort that would be involved in such a conversion and the relatively small benefit from the perspective of a reader. As it is, I might convert those pages in my region, or that I stumble upon, or that need improvement, but I have other, higher priorities.
I appreciate your hard work on this template, and I am sure that it will continue to be used for some time to come. David H. Flint 04:53, 16 March 2007 (UTC)
As for your first issue, this template (Infobox City) does have dual automatic unit conversion; imperial to metric or metric to imperial and it can be over riden for (instances like ranges in elevation) by entering both imperial and metric values. I also made it to try to automatically swap the unit order based on subdivision_name being some variation of United States. There is also unit_pref=Imperial. I think we should make a better table explaining all the fields possible with this template.
As for the names, yes they do need to be improved and some of us have talked about doing that. We've also discussed fixing the flag, logo, seal, shield links that are red on many pages. And some didn't like the nickname and motto position.
I am sure that there are other things that could be tweaked but if no one says anything thing we won't know. So thanks for the coordinates things—I would not have thought of it. —MJCdetroit 17:41, 16 March 2007 (UTC)

[edit] Adding to all US Cenus Areas (41,903 cities/towns/townships/villages/etc.)

[edit] Overview

I've spent a while compiling a giant database of information on US census division statistics, and I'm nearly ready to request permission to use a bot to add this template to all 41,903 articles that I have information on. However, a serious discussion will need to take place first to determine if this is the correct template to use, and what kind of modifications need to be made to it before its usage jumps from 4100 to 45000 articles. Thus, I will start that discussion here, so please add your comments. I haven't applied for a bot account yet, and will only do so when/if a consensus is reached here that adding this template to the articles is the right thing to do.

My database, which I compiled from many government databases, contains the following information. These are nearly all articles added by User:Ram-Man and User:rambot, but there are about 5000 that are missing (and which I will add in the style of the rambot). The percentage refers to the number of records, out of 41,903, that I have that information on:

  • Name and type (city/town/township/CDP/borough/charter township/balance/etc.) (100%)
  • State and all counties that the location is in, along with all corresponding FIPs codes (99.91%)
  • Place ID, from national geography database (97.80%)
  • Population year, total, density (100%)
  • Area total, water, land, in both km and mi squared (100%)
  • Latitude and Longitude (99.91%)
  • Elevation (97.79%)
  • Time zone, UTC offset, Daylight Savings use, DST offset (100%)
  • Area codes (69.00%, mostly missing from CDPs and townships)
  • ZIP codes (62.20%, mostly missing from CDPs and townships)
  • I also plan on generating and uploading new, standard, and prettier maps for all 41,903 locations (based on a combination of St. Paul, MN, Concord, NH, and Miami, FL map designs).

Information I can't find in public databases (if you know where to find an item, let me know):

  • City/town website listings
  • Area code and ZIP code geographic boundary files
  • List of mayors or other leaders of all cites in the US
  • List of dates settled/incorporated for all locations in the US

Note that I will not overwrite information in articles that already have an infobox, but I will add missing information (though I will record all information already in infoboxes, so I can later examine if it is accurate, and replace it later on if it is not accurate). Also, I do not plan on using the bot to edit the largest 200 cities or so, and these articles will be edited by hand to add the information.

The new maps will only be used on articles that contain no map, or contain one of the simple red-dot maps. Articles with more sophisticated maps will not have their maps modified. However, the maps for all locations will be uploaded, even if it is not used in the infobox, so someone can manually add the new map to an article later on if they choose.

Certain states, such as Massachusetts and New Hampshire already have most of their cities/towns/etc using this template; this project would just be a continuation of this process to extend the templates to all cities/towns in every state.

I have a few requests/suggestions for changes to be made to the template before this huge-scale use:

  1. See Durham, Connecticut. Note that the "Government Type" field has a problem; the word "Type" in "Government Type" wraps to the second line, which is ok, but on the right hand side, the value "Selectmen-town meeting" starts on the same line with "Type" instead of the top line with "Government" (at least on my IE7). This should be examined and fixed.
  2. The five strangely named parameters for area, "TotalArea_sq_mi", "LandArea_sq_mi", "WaterArea_sq_mi", "MetroArea_sq_mi", and "UrbanArea_sq_mi" should be named with more standard names. It would be good if someone could make both the old names and five new names usable, until I can convert all instances of the old names to the new standard names with a bot. At that point these old names could be completely removed.
  3. It would be useful to have a way to include FIPS codes and a FeatureID (see the File Format section in [5]) in this template to help people keep track of the exact record of the city in census and geographical databases. Many places have the same name within states (for example, there are four Exeters in Pennsylvania), and it is difficult to tell them apart without such a number. Perhaps we could add a few official fields at the end (something like id_type1, id_number1, id_type2, id_number2, etc) that don't actually display anything, but just exist for classification purposes only. Or perhaps they could display the ID numbers at the bottom in very small print.

So, please add any questions and comments about this proposed use of the template below. --CapitalR 10:55, 18 March 2007 (UTC)

[edit] Discussion

This is not directly connected with your suggestion yet let me point out the existence of {{Geobox Town}} (or if you wish {{Geobox City}} which is just its alias). It was nor originally designed for US cities but as of its current version it can easily accommmodate all its fields from Infobox City and it provides much more functionality in a cleaner design. The fully consistent field names are also useful for any import/export to/from a database.

As of your three issues with Infobox City:

  • {{Geobox Town}} prints all field labels on one line thus you never get the field label split in two parts.
  • one of major advantages of {{Geobox Town}} is that it uses consistent field names, all imperial/customary units are have suffix _imperial (i.e. are_imperial, area_water_imperial, population_density_metro_imperial etc.); furthermore there exist additional fields with the _note suffix that accompany every basic field (for any type of notes, references etc.), there are also _type additional fields (for every basic field) that allow to redefine the default field label
  • there exist four code fields which could be used this way (always code for the value and code_type for the field label, there's code, code1, code2, code3) or four free fields (defined always as free and free_type)

Additionaly, there are two fields for a map, both of which can make use of an automated locator dot placement (given a calibartion template exists for the given map), then there's no need for a special map for each and every place. Of course, plain maps can be used as well. The use of two maps (state map and the location of the state within the USA) is recommendable as non-US readers are usually not familiar with the location of US states.

Some users tried to use this template for US places, see e.g. Springfield, Illinois or West Chester, Pennsylvania. – Caroig 12:17, 18 March 2007 (UTC)

CapitalR, "My what a big database you have"—good job.
"Goverenment type" actually doesn't split. Government is the section title (much like Area and Population) and "Type" should have a dash in front of it. That should be easy to fix.
As for the field names, we've been discussing them and they will be changed to more consistent names soon.
We can always add ID fields to the template as well but we should work on the names first. —MJCdetroit 16:01, 18 March 2007 (UTC)
I do like the idea of having some consistency throughout the city articles. For instance, Bakersfield, California has a seal & logo in box, but picture and dotmap are outside the box. Fresno, California has a seal, picture, flag, and dotmap in the box. Ontario, California has only a picture and dotmap in the box. I'm sure this list continues ad nauseum, as these are just the first three cities I opened up.
Anyway, I think it's a good idea. My hat is off to you, I think even with a bot it's a lot of work. Brien ClarkTalk 04:33, 28 March 2007 (UTC)
See Bakersfield, California. The logo was a little long, so I placed it in the image_map1 field instead of the city_logo field. —MJCdetroit 16:57, 28 March 2007 (UTC)

[edit] Rename to Infobox Settlement

Would it make sense to rename this template to Infobox Settlement instead of the current Infobox City? This template is now designed to be used by any settlement type instead of just cities, and I want to make sure that people aren't confused when they see this template in an article that isn't about a city. For example, when I added this template to the 301 Massachusetts towns, some people reverted the changes on the basis that a town isn't a city (it was very irritating to have to go fix these and explain that this template is for more than just cities). I know that Infobox Town redirects here and I could have just used that instead, but I still think that the master template should be named Infobox Settlement, and the Infobox City, Infobox Town, Infobox County, Infobox Township, etc, should all redirect to the master. Just some thoughts to consider, --CapitalR 12:14, 19 March 2007 (UTC)

Infobox Settlement as the master is a change that we could live with. However, the default "settlement" would still be city unless changed in the field "settlement_type". By the way, Infobox Place also redirects here.
Also, in regards to some of your comments above, I have managed to change most of the field names in a sandbox but there's one that is giving me problems, so once we fix that, we'll do some testing before implementing them on the live template. —MJCdetroit 15:17, 19 March 2007 (UTC)
What's the status of merging this with Template:Geobox Town. Is there any reason we need both? What does Infobox City offer that Geobox Town does not? --MattWright (talk) 15:29, 19 March 2007 (UTC)
I suggested it before. It would be in our best interests to have just one standard template having the focused effort among editors. We can call it whatever. There are a few differences, but with Infobox City transcluding on 3,500 pages there would have to be some compromises made to not upset the editors of those 3,500 plus pages. —MJCdetroit 17:12, 28 March 2007 (UTC)
Hey MJC, thanks for the reply (I had seen it). I didn't followup because I didn't have any great solutions for merging them and hadn't had the time to explore it more. --MattWright (talk) 20:43, 29 March 2007 (UTC)

[edit] New more consistent parameter names and an explaination table

The parameter names have been (or will be) changed so that they are a little more consistent with each other. Infobox City/Test has already been changed. It has side by side infobox comparisons —which look the exact same. It also has a table showing the new field names and the deprecated (old) names. After the new names are implemented in the template, the old names will still work and we can get a bot to switch all the pages using this template to use the new names. Please see Infobox City/Test. —MJCdetroit 01:06, 22 March 2007 (UTC)

Nice job getting those new names in there. --CapitalR 16:25, 23 March 2007 (UTC)

Edit conflict...I made the change to the live template so that it will accept the new names. The documentation on the main template page has been updated to reflected this change. There is also a table to help explain the template a little better. The only article that I changed to the new names was San Jose, California. We can get a bot to change the rest. In the future, articles should only use the new parameter names. —MJCdetroit 16:34, 23 March 2007 (UTC)

[edit] Google Maps & Earth external links inside the infobox

Since Wikipedia is an encyclopedia whose contributors are the readers themselves today I attemped to produce an easier connection (which I really thought it was needed) between the article of a city and the major external services relating to its geographical coordinates. At the present State of the Art Google is a sort of standard in this respect and I've thought that now it's time to have this link directly embedded into the infobox. It is true that a complete external service is already permanently linked on the top right side of many city articles, under "coordinates", by means of the templates of the coor and geo* families and http://tools.wikimedia.de/~magnus/geo/geohack.php?, but as a user I did find not very practical having to open that link and to scroll the long and always growing list of geohack in search of the maybe most requested today (in its 2 most popular versions): Google Maps and Google Earth. So I've thought -maybe wrongly?- that a discussion wasn't even needed if I was simply trying to use some parameters (latitude and longitude) already present in the city infobox and attempting the best layout of their easy and (today) needed quick link. Under the infobox city title seemed to me the best and practical place (for its immediate use), but if it is too invasive for the eye the same can be done under the map and the geo coordinates below. So now, if you agree, following the suggestions received, I'll try to move the code I produced to that location inside the infobox. Sorry for my bad English, but I was and I am really trying to help :)--Florenus 20:41, 2 April 2007 (UTC)

Hi Florenus. I certainly understand you were only trying to help. Personally, I don't think these two links should appear in the infobox. It is unusual for external links to appear outside of the external links or references sections. Although these may be commonly used mapping services, different users may have different preferences, and these are all available by clicking the coordinates themselves. Furthermore, maps of the locations are already shown in the infobox to provide a general overview of location. This is just my opinion, and maybe we can get other editors to weigh in here. I'm fine with them being added if that is the consensus. --MattWright (talk) 20:56, 2 April 2007 (UTC)
Ok, I just put them for a trial in the lower location I previously announced.

I personally think that it is very useful for any user a quick location of a Geo subject to Google Earth or Maps, possibly -in my humble opinion- close to the city name, but where it is now it's equally fine, I think. I might improve also the layout to make it more 'gentle'. Some suggestions for this? I don't have much time now, but I can try to make soon 2 small icons to substitute the 'SEE' and that way can be less intrusive. What do you and other users think? :) --Florenus 21:17, 2 April 2007 (UTC)

I'm still against it -- especially since one of the links requires some special software to be installed (Google Earth) to make use of it. I'll leave it up to other editors whether to revert or leave it. --MattWright (talk) 21:23, 2 April 2007 (UTC)

I don't think this is a very useful addition to the infobox at all. It's too prominent and arbitrary in its use of google earth and google maps. I'd say remove it or provide a very good reason before adding it to one of the most commonly used infoboxes. There is a perfectly good alternative for those users who want to view maps or satellite images. Right clicking on the coordinates provides an list of all available possibilities, not just two arbitrary ones. Leaving it like it was doesn't offend the common user and doesn't limit other users in their possibilities to view maps. I see no reason to keep it, I can only agree with MattWright. --Eric Bronder 22:31, 2 April 2007 (UTC)

OK I give it up. --Florenus 07:58, 3 April 2007 (UTC)
How about trying something like this out at Template:Infobox City/Test first? —MJCdetroit 04:49, 3 April 2007 (UTC)
Static Wikipedia 2008 (no images)

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - en - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu -

Static Wikipedia 2007 (no images)

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - en - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu -

Static Wikipedia 2006 (no images)

aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu