Template talk:Infobox settlement/Archive 22

Archive 15

←

Archive 20

Archive 21

Archive 22

Archive 23

Archive 24

Archive 25

Formatnum on population messes up dated templates

When you have a dated template (e.g. "citation needed") after a population figure in the infobox, the automatic category creation for that "citation needed" becomes incorrect. E.g. Bsharri has now a first (and redlinked) category Category:Articles with unsourced statements from August 2,011, while it should be Category:Articles with unsourced statements from August 2011. This is caused by the formatnum magic word, which changes "2011" into "2,011". Any ideas on how to fix this? The same happens e.g. on Flagstaff, Arizona. All in all, for the moment some 17 articles have this problem. Fram (talk) 11:56, 10 April 2012 (UTC)

The {{citation needed}} should be in the |population_footnotes= parameter (as should any <ref>...</ref>), not in |population_total= which is intended for a pure quantity. Similarly, if the quantity is in one of |population_urban=, |population_rural= or |population_metro= any {{cn}} or <ref>...</ref> should be in |population_urban_footnotes=, |population_rural_footnotes= or |population_metro_footnotes= respectively.

I have fixed Bsharri and Flagstaff, Arizona. --Redrose64 (talk) 23:20, 10 April 2012 (UTC)

Thanks for the explanation and correction. Fram (talk) 06:44, 11 April 2012 (UTC)

type:city(population)

Hi guys, please help me understand why the coordinate generated by Infobox settlement in Ames, Iowa is not setting the type:city parameter (with a population number). At first glance it seems that if teh population_total parameter is set in the template, that coordinate parameter should be autogenerated. This is causing me a bit of grief, as I'm not getting all the information I could when extracting the coordinates of settlements. I'm using the type:city(population) parameter from the coord template to determine the display style of the coordinate on the map. Depending on population the cities/settlements get deiierently sized icons and get displayed with different priorities. And currently I'm having a sh*t ton of cities displayed wrongly. And that seems like an issue that could easily be fixed. --Dschwen 15:17, 13 April 2012 (UTC)

And to make matters even more complicated: The swiss canton (state) of Aargau has a type:city(xxx) attached, where type:admin2 would be appropriate. --Dschwen 15:34, 13 April 2012 (UTC)

In Ames, Iowa: {{{coordinates_type}}} is supplied, though with only a markup comment in the argument value, so it is effectively set to a zero-length string in {{Infobox settlement}}, instead of being overridden by the city type: {{{coordinates_type|type:city{{#if:{{{population_total|}}}|{{#iferror: ... }}}. Assuming this is untintentional, I think this could be fixed by changing {{Infobox settlement}} to something like {{#if:{{{coordinates_type|}}}|{{{coordinates_type}}}|type:city{{#if:{{{population_total|}}}|{{#iferror: ... }} — Richardguk (talk) 17:14, 13 April 2012 (UTC)

Yes, see my comment at Template talk:Infobox settlement/Archive 21#Edit request on 11 February 2012 also the entry for coordinates_type under Template:Infobox settlement#Maps, coordinates. But for situations similar to Ames, Iowa, I haven't yet found a genuine need to use |coordinates_type=, so I normally simply remove this parameter completely. --Redrose64 (talk) 17:21, 13 April 2012 (UTC)

It would be more intuitive/robust to ignore any blank {{{coordinates_type}}}.

In Aargau, the problem is cause by the reverse situation: an unintuitive default output where a parameter is missing. {{Infobox settlement}} is transcluded there via {{Infobox Canton}}, which does not allow for {{{coordinates_type}}}. As shown above, {{Infobox settlement}} currently defaults to inserting type:city (with population and/or region etc if supplied) whenever {{{coordinates_type}}} is not defined.

— Richardguk (talk) 17:34, 13 April 2012 (UTC)

{{Infobox Canton}} does not allow for {{{coordinates_type}}} - It does now. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:39, 13 April 2012 (UTC)

I've now amended Template:Infobox settlement so that if |coordinates_type= is present but blank, it will be ignored so that the default action for type: and region: will operate as intended. --Redrose64 (talk) 18:42, 13 April 2012 (UTC)

Thanks guys! We'll see after tomorrow's data extraction if this helped. --Dschwen 20:02, 13 April 2012 (UTC)

Thanks Redrose and Andy. Possibly the new {{{coordinates_type}}} parameter in {{Infobox Canton}} should default to the region code with something like coordinates_type={{{coordinates_type|CH-{{{abbr}}} }}} instead of an empty string, when calling {{Infobox settlement}}; or, more generally, perhaps {{Infobox settlement}} could be further edited to detect certain cases where city should not be the default type even when {{{coordinates_type}}} is blank or missing (as in the {{Infobox Canton}} subtransclusion). But I'm not sure whether there's a reliable way to detect whether {{Infobox settlement}} is being transcluded to a non-city type (other than by editing pass-through templates). Depending on the intended use, the template documentation might also need updating (it currently states "If |coordinates_type= is present, but is left blank, no coordinate parameters will be set", which was incorrect both before and after today's template edit). I've not edited the templates myself as you may understand their intended purposes better. Hope that makes some kind of sense! — Richardguk (talk) 23:28, 13 April 2012 (UTC)

{{Infobox Canton}} has a separate |coordinates_region=, wih defaults to CH-{{{abbr}}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:28, 14 April 2012 (UTC)

@Richardguk: the sentence "If |coordinates_type= is present, but is left blank, no coordinate parameters will be set." was added to the documentation by me some weeks ago, to reflect the actual behaviour of the infobox. It was certainly true before my edit yesterday: the "coordinate parameters" referred to are the scale:, dim:, source:, region:, and type: shown in the three bullets immediately preceding, and it was not intended to refer to any other coordinate information (such as latitude or longitude). As the OP noted, {{Infobox settlement}} was generating coordinates but "is not setting the type:city parameter (with a population number)". I have now amended the documentation again, to match the behaviour since my edit yesterday. --Redrose64 (talk) 12:11, 14 April 2012 (UTC)

@Andy: Indeed; but the settlement template only suppresses the "city" type if a non-blank value for coordinates_type is supplied, hence the unchanged spurious parameter in Aargau (i.e. params=47_5_N_8_0_E_type:city(612611)_region:CH-AG). The only way to suppress "city" (without further editing the settlement template) is to pass the Canton region through coordinates_type too/instead.

@Redrose: Thanks, it's certainly clear now!

— Richardguk (talk) 13:41, 14 April 2012 (UTC)

Dunams

Until now the coverage of dunams had been quite limited. Only the total area was covered and you had to both specify dunams as the prefered unit and input the area in this unit. It is now possible to specify any of the area measurements (total, land, urban, metro, etc.) in dunams. Dunam input and output are no longer interdependant.

• Dunams will be automatically converted to hectares or square kilometres and acres or square miles dependant on size (independant of whether the unit pref is for dunams).
• It is also now possible to convert to dunams; setting the unit pref to dunams will display dunams (and conversions) whether or not dunams were input.

Automatic conversions from area in dunams are also enabled when one of the density parameters is set to auto. A link to the Dunam article is produced automatically. The link can be moved or removed using a new dunam_link parameter: set it to land, for example, to link the Dunam article from the word dunam in the land specification; setting it to on or total or leaving it blank will make the link from the word in the total area line; setting it to something else that does not refer to an area measurement, to off for example, turns the link off. The order of magnitude link now works when dunams are used, setting area_magnitude to a non-empty value will make the link from the conversion (linking from here so as not to interfere with the link to the article). JIMp _talk·cont 05:55, 20 March 2012 (UTC)

Please could you let me know when you're done in the sandbox; I'd like to add the derivation parameters discussed above - unless you'd like to do them at the same time? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:36, 20 March 2012 (UTC)

Yes, if need be let's work in parallel but I don't think I have anything left to twist about right now. JIMp _talk·cont 15:45, 20 March 2012 (UTC)

Sorry; I got side-tracked. Where are we up to? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:39, 9 April 2012 (UTC)

You were going to play in the sandpit and were wondering how we could share the sand without getting it in each other's eyes. JIMp _talk·cont 07:03, 18 April 2012 (UTC)

Length and width

I have added length and width parameters as requested last month. Here are the new parameters.

|length_km            =
|width_km             =
|length_mi            =
|width_mi             =
|dimensions_footnotes =

JIMp _talk·cont 06:51, 18 April 2012 (UTC)

Remember to please update the documentation. —Stepheng3 (talk) 17:53, 18 April 2012 (UTC)

Done. JIMp _talk·cont 00:29, 19 April 2012 (UTC)

Help

I'm not sure how to use this template (the parameters and stuff, you know?), at least not well enough to convert from an older more specific location template to this one. I changed the template at Trikarpur to use this one, but I've just left all of the old parameters because I don't know what the heck to do with them. If anyone is able to convert them, I'd appreciate it.
— V = IR (Talk • Contribs) 03:32, 24 April 2012 (UTC)

The template {{Infobox Indian Jurisdiction}} itself was supposed to be merged into this template, probably as a wrapper first and then later perhaps subst'ed into the articles. For now, these conversions shouldn't be happening on the articles themselves. If I recall, there was some functionality from that template that was supposed to be included in this template before the wrapperizing occurred, and this perhaps has stalled. I'm going to revert your edit at that city page for now... Maybe it would be a good time for one of the more involved people on the development of this template to chime in, or take up the torch as far as getting them merged? Calliopejen1 (talk) 03:49, 24 April 2012 (UTC)

OK.
— V = IR (Talk • Contribs) 04:52, 24 April 2012 (UTC)

Transclusion anomalies (Template:Country Data..., etc.) 7 May 2012

Under normal, proper use of this {{Infobox settlement}} template, I am finding that strange templates (see ^ below) are being transcluded while using {{Infobox settlement}}. I have drilled down and eliminated all parameters that do not seem to cause the anomaly, and I discovered that the following are somehow related to the anomaly : When any non-null value is used for subdivision_name, latd, and longd, then the anomaly occurs. If any one of these 3 parameter's values are null, the anomaly won't occur. A non-null value such as a period or zero, etc. for each of the 3 parameters will cause the anomaly. I've looked at the {{Infobox settlement}} source but become lost as to which subtemplate may be the cause.

{{Infobox settlement | subdivision_name = 0 | latd = 0 | latm = | lats = | latNS = | longd = 0 | longm = | longs = | longEW = }}

^ These are some of the strange templates showing under "Pages transcluded onto the current version of this page:"

Template:CAN (view source) (protected)
Template:CHE (view source) (protected)

Template:Country data Canada (view source) (protected)
Template:Country data China (view source) (protected)
Template:Country data Comoros (view source) (protected)
Template:Country data Côte d'Ivoire (view source) (protected)
Template:Country data Equatorial Guinea (view source) (protected)
Template:Country data Gambia (view source) (protected)
Template:Country data Georgia (view source) (protected)
Template:Country data Macedonia (view source) (protected)
Template:Country data Malaysia (view source) (protected)
Template:Country data Mauritius (view source) (protected)
Template:Country data NED (view source) (protected)
Template:Country data Nepal (view source) (protected)
Template:Country data Netherlands (view source) (protected)
Template:Country data People's Republic of China (view source) (protected)
Template:Country data Philippines (view source) (protected)
Template:Country data Poland (view source) (protected)
Template:Country data Republic of China (view source) (protected)
Template:Country data The Gambia (view source) (protected)
Template:Country data Timor-Leste (view source) (protected)
Template:Country data USA (view source) (protected)
Template:Country data Ukraine (view source) (protected)
Template:Country data United States (view source) (protected)

Template:MKD (view source) (protected)

Template:PRC (view source) (protected)

Template:ROC-TW (view source) (protected)
Template:TLS (view source) (protected)
Template:UKR (view source) (protected)
Template:USA (view source) (protected)

CM2G0005 (talk) 11:37, 7 May 2012 (UTC)

the problem is with template:CountryAbbr2 and/or template:CountryAbbr. they use a big switch statement to set region codes for the coordinates. you can eliminate the use of these templates by explicitly setting |coordinates_region= to the correct region code, which bypasses the templates. Try this instead:

{{Infobox settlement| coordinates_region = US | subdivision_name = 0 | latd = 0 | latm = | lats = | latNS = | longd = 0 | longm = | longs = | longEW = }}

to see what I am talking about. Frietjes (talk) 16:37, 7 May 2012 (UTC)

A large image

This template orders the location map in a row ("tr") and the coat of arms and the flag in another row ("tr"). For most of the countries that is OK, but you may know that Chile is a very long country and the infobox get very large, too large in my opinion. See for example Santiago (commune).

Hence, I have played with Template:Infobox settlement/sandbox and put the flag, the coat of arms and a little communal map in a column along with the large location map of Chile: you can take a look to Template:Infobox settlement/testcases.

My first question is: is it necessary? Do you know another way to get similar results?.

I think it is necessary and therefore I wanted to edit and publish a new template Template:Infobox settlement Chile, but it doesn't work as you can see in the red message in the first line. (the current version is only a copy of "Infobox settlement". the changes are to be merged from sandbox)

Second question: how can I bring my new template to work?. --Best regards, Keysanger (what?) 15:29, 14 May 2012 (UTC)

resolved. --Best regards, Keysanger (what?) 21:04, 14 May 2012 (UTC)

any reason why you had to fork the template, rather than just add this feature to this template? Frietjes (talk) 22:30, 14 May 2012 (UTC)

I don't know how to add this feature to the general template.

The original template has reached a high degree of complexity and to add a new feature to the template means:

• to raise the error-proneness of the template
• to make the maintenance of the template almost impossible for most of users
• to call experts every time a change is needed

Moreover, a template designed specially for a determined use makes the maintenance of the articles easier: width of the images and tables, text and its position in the table can be central defined. Using a general template implies that articles (in the same category) can have different colours, widths or texts.

--Best regards, Keysanger (what?) 08:39, 15 May 2012 (UTC)

you should have at least asked if it were possible before forking it. when you fork the template, it makes it harder to sync changes. it's much better to at least try to add the features here first. Frietjes (talk) 22:06, 15 May 2012 (UTC)

The forked template is nominated for deletion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:13, 17 May 2012 (UTC)

Image parameters without syntax

Is it possible to add optional alternative image parameters that don't automatically add image syntax, so an editor would have to add [[File:Example.png|frameless|250px|alt=Example alt text]] (or similar) themselves to make the image show, rather than just the image name?

There are various graphic templates that would be useful in some circumstances in an infobox. However, if they are used in the image_skyline parameter (or any of the image parameters), the syntax will appear around the image. So image parameters that didn't add the syntax automatically would be very useful for these templates.

The only way I can see to use a graphic template in the infobox is to add it to the image_caption parameter before the caption, separated from it by a <br /> (or with the unbulleted list template), and to add blank.gif for the image parameter (so the caption and image template shows) with an image size of 0px. But this seems like a pretty dodgy workaround, and may not always render correctly. Understanding very little of how templates are created on Wikipedia, I'm not sure if adding an additional "image_skyline_no_syntax" (or similar) parameter is simple, complicated, or impossible.TimofKingsland (talk) 00:19, 16 May 2012 (UTC)

This would add more complication to a template which is already very complicated. Most infoboxes are moving towards the idea of separate parameters for image information, and those retaining parameters that allow the full image syntax in one parameter have often marked these as deprecated (see for example {{infobox UK place}}, where four separate parameters |static_image_name= |static_image_width= |static_image_caption= |static_image_alt= are preferred to the deprecated single parameter |static_image=). Can you give some examples of articles where a single parameter will be significantly useful? --Redrose64 (talk) 09:52, 16 May 2012 (UTC)

Short answer: no. I first realised it wasn't possible to use a template when I was playing around with {{Css Image Crop}} to see what an image would look like cropped on a page's infobox, but as the template's documentation says, the image should be (and was) replaced with a cropped image anyway. I used that workaround I mentioned above to try it out. But I thought hypothetically templates like {{Site plan}}, {{Location mark}} and {{Location mark+}} might be useful for this infobox, allowing editors to mark a certain point on an image that might only be necessary when the image is small. For example, there could be a photo of a largely unoccupied valley with a small settlement the article is covering in the image, but only taking up a small portion of the entire image. When the photo is seen on its own page, the settlement would be obvious, but in the infobox might not be. Obviously an editor could edit the image and upload it with a mark on it, but this could spoil the look of the image. Moreover, it seems more difficult than using one of the templates, so the editor could opt to use the workaround I mentioned before and have the infobox look different under different browsers, or just leave the image out altogether. {{Text-superimpose}}, {{Annotated image}} and {{Superimpose}} could have similar uses, by allowing editors to superimpose text or images without having to upload alternate versions of the image.

When you say "[t]his would add more complication to a template which is already very complicated", are you talking about the source code being complicated or the use of the template itself? If you're talking about its use, I would have thought an explanation for the parameter like the following would be clear - "Does not insert the usual image syntax. For when an editor wants to use a template to display an image." Anyone who is able to understand the use of the template as it is now would surely understand that too, and it seems less complicated than forcing the editor to edit and upload a new image when a template would quickly and easily do the job for them. If you're talking about the source code, it's obviously a different story, and I'd have to take your word for it.

My experience in web design tells me it's not usually a good idea to restrict options, especially not for something that might be used in many different ways, like this infobox. To me it seems counter-productive to prevent editors from using any of the current (or possible future) graphic templates in infoboxes. I can't say how often they might have been used to good effect if they were available, but experience tells me if options are available, they will be made use of. — TimofKingsland (talk) 03:51, 17 May 2012 (UTC)

Complication within the template source code, not for the end user. If you don't have edit rights for this template, you can still view its source code. Look for [[File: to see where the fifteen images are presently set up, and imagine recoding those to allow two different methods. For me, this would need a strong argument in favour of "we need this, and cannot manage without, because..." --Redrose64 (talk) 13:01, 17 May 2012 (UTC)

OK. As I said before, I understand very little of the way templates are created on here. It does look complicated, and not being able to do it myself, it seems like a lot to ask of another person. And it seems like the potential to make a mistake causing problems for thousands of pages is relatively high, given the template's complication. I still think it would be a good idea to have the option, but in the absence of an easy way to do it, I'm willing to let it go. Thanks for your answer. — TimofKingsland (talk) 05:34, 18 May 2012 (UTC)

city(size) missing in St. Louis, Missouri

Hi, another case of a missing city(size) in the type: parameter of the coordinates generated by this template. Any idea why? --Dschwen 17:01, 18 May 2012 (UTC)

my guess is that this was the problem. Frietjes (talk) 17:26, 18 May 2012 (UTC)

Yes, thank you! --Dschwen 17:27, 18 May 2012 (UTC)

That fixes the coords in the infobox, but it doesn't fix the title coords. This edit fixes those too. --Redrose64 (talk) 15:26, 20 May 2012 (UTC)

Problems with template

Could someone check out this template on Tobique First Nation? I'm trying to work out why this template has errors with the image there, but may not be able to fix it without help with the code. Thanks! - Kathryn NicDhàna ♫♦♫ 20:13, 27 May 2012 (UTC)

There are no coordinates. If you specify |pushpin_map=New Brunswick you must also fill in |latd= and |longd= at the very least, and optionally |latm= |lats= |latNS= |longm= |longs= |longEW= as well. --Redrose64 (talk) 21:23, 27 May 2012 (UTC)

surprise

Hi, what a surprise! Would it be possible to calculate population_density_km2 and population_density_sq_mi to avoid such weird results. regards. --Herzi Pinki (talk) 22:54, 11 June 2012 (UTC)

Why do you consider them to be weird? --Redrose64 (talk) 23:38, 11 June 2012 (UTC)

Yes, it would be possible to calculate these to avoid the weird results. To auto calculate density set the density parameters to auto. It's been done, by the way. Also, you would consider them weird given that the total area is given as 69.5 sq mi (180.0 km²) and the total population is given as 117,517. Thus the desity should be 117,517⁄69.5 sq mi (117,517⁄180.0 km²) which is about 1,700/sq mi (650/km²) as opposed to 1,070.7/sq mi (413.6/km²). Perhaps those are old figures. JIMp _talk·cont 10:10, 12 June 2012 (UTC)

thanks for fixing, did not know about the parameter value of auto, although it is described in the infobox. As always, RTFM would have helped. :-) But, there is a lot of uses of this infobox (> 277.000). Wouldn't it be better to make the value of auto the default, meaning that when population and area are given, the density is always calculated from that values (but could be overwritten in special cases with manually calculated values, always check all values given explicitly against calculated values to find wrong / outdated values). Manually calculated values for density will always be outdated when population changes (which is done once a year or so), it is quite easy to forget to update. So my proposal was not to auto-calculate density triggered by a special value, but by default. --Herzi Pinki (talk) 23:04, 12 June 2012 (UTC)

I agree that having autoconversion as the default would be better. I'm not sure why it wasn't set up that way in the first place. JIMp _talk·cont 23:15, 12 June 2012 (UTC)

what if there are two or more urban areas?

The parameters area_urban_footnotes, area_urban_km2, population_urban_footnotes, population_urban_km2 etc. assume that there is only one urban area within city limits. However, in the case of a municipal merger there may be two or more (i.e., two or three former cities that merged into one, resulting in two or three population centers with possibly semi-rural area in between). How should this be handled? See for instance Baie-Comeau (note the automatically converted square-mile density figures come out wonky).

At the risk of complicating an already large template, is it feasible to consider adding parameters area_urban1_km2, area_urban2_km2, area_urban3_km2, ... and population_urban1, population_urban2, population_urban3, ... and so forth? — P.T. Aufrette (talk) 16:54, 24 May 2012 (UTC)

there are area_blankX and population_blankX fields (see Template:Infobox settlement#Geographic information). you could always use those. Frietjes (talk) 15:08, 13 June 2012 (UTC)

Map higher

Can we possibly change the template to have the map higher up the infobox? If not above the skyline, then at least above the flag/shield. The location is more important and shouldn't be pushed so far down, where it may well be below the fold on small screens. Rd232 ^talk 13:03, 19 June 2012 (UTC)

this might be possible whenever the merge of Infobox settlement Chile happens. that merge will require adding an option to move the map to be next to the flag/shield. there was also a request for having an option for swapping the order of the pushpin_map and the image_map, discussed in the last thread at template talk:Infobox townlands. Frietjes (talk) 16:29, 19 June 2012 (UTC)

Official languages

Would it be possible to add official_languages in the infobox parameters? If so, that would be much appreciated. Buttons (talk) 08:25, 19 July 2012 (UTC)

Settlement with two names used equally

The unincorporated community of Helendale, California has two names - Helendale and Silver Lakes. The names are used pretty much equally. Both names are officially recognized - Helendale by the US Post Office and Silver Lakes by the US Census. How do I enter these two names into the template? Ego White Tray (talk) 04:29, 4 August 2012 (UTC)

Interesting. Try looking at the GNIS search engine and enter the two names to see what comes up. [1] You will see even GNIS lists both, but the "Helendale" map is the basic reference. The real wrinkle comes with the fact that Silver Lake, San Bernardino County, California is an entirely different location. With this in mind, follow what's on WP:TITLE. For the template, I think putting Silver Lake in parens will work. Something like [[Helendale, California|Helendale (Silver Lakes)]] would work. (It will show up as "Helendale (Silver Lakes)".) Also, post an inquiry on Template talk:San Bernardino County, California to see if anyone responds. (Not likely that they will because the template is on less than 30 watchlists.) --S. Rich (talk) 05:10, 4 August 2012 (UTC)

Name Other Name
Official Name
Nickname:  Nickname

You could try various combinations of |name= |official_name= |other_name= |nickname= to find one which gives the best result. --Redrose64 (talk) 16:03, 4 August 2012 (UTC)

I used other name and it seems to work well. Ego White Tray (talk) 06:46, 5 August 2012 (UTC)

Why not add sister cities or twins to the infoboxes?

Separately, they do not merit much inclusion in the article since the sections at most are just lists. We should consider fitting them in somewhere in the infobox so that the articles are better looking. (Tigerghost (talk) 09:01, 9 August 2012 (UTC))

I'd support adding these to the infobox; but please bear in mind that infoboxes are supposed to summarise the facts that are in the article. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:41, 9 August 2012 (UTC)

I would question whether these are notable enough for the infobox. --John (talk) 11:31, 9 August 2012 (UTC)

better to just leave them to a section at the bottom of the article. in many cases, the infobox is much larger than the article, because editors are more inclined to add stuff to an infobox than to write prose. Frietjes (talk) 15:48, 23 August 2012 (UTC)

Using multiple images in skyline

I hope this is the correct place to put this: San José, Costa Rica has some stray code around its skyline, and I've already spent way too long trying to fix it. I tried comparing the skyline infobox code to examples from other cities that use a montage, but I noticed most of those just use a single file that is a montage itself, not multiple source files to generate the montage in situ. A weird bit is that I cannot even find the "stray code" that shows up in the article if I do a copy and then search for the copied text... So my question is: how can I fix this stray code, and is it good practice to use multiple images instead of a single one? I've got nothing to do with the article, I was just reading it and saw the mistake; then I reckoned it must be an "infobox: settlement" property, since the text that shows up is not in the "source code" for the page itself. Thanks. Stijndon (talk) 12:42, 23 August 2012 (UTC)

the image_skyline parameter currently requires a raw image name, so really the best way to do it would be to create a single image from those multiple images. this is also more robust in terms of making sure it looks the same on all browsers. Frietjes (talk) 15:46, 23 August 2012 (UTC)

Thanks, I made the montage a single file and now it looks correct. Stijndon (talk) 18:01, 3 September 2012 (UTC)

Crowding out text

All of the sudden, I'm having to place "clear"s above text apparently because of size increase of not only settlement but other infoboxes as well. See, for example (skip change to top of article). Something has happened somewhere to cause this. Can someone help? We need to be able to place the infoboxes next to article text, usually. Thanks. Student7 (talk) 20:43, 31 August 2012 (UTC)

Looks OK to me. Has anybody else reported a problem?

Student7: what browser are you using? Does the font size in general text (outside of all boxes) look normal? --Redrose64 (talk) 20:54, 31 August 2012 (UTC)

Fine for me too; I've removed the "clear". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:49, 31 August 2012 (UTC)

Sorry. It's probably my display driver. Thanks for the responses. Student7 (talk) 23:38, 4 September 2012 (UTC)

Languages

In this conversion from {{Geobox/Province}} to {{Infobox settlement}}, we lost a list of languages. Should we add a |languages=, or even a |free=, as used in the Geobox? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:15, 6 September 2012 (UTC)

I think this is covered by "Demographics (section 2)" in the documentation or by one of the many blank section parameters. Frietjes (talk) 15:20, 6 September 2012 (UTC)

also the capital is the seat. Frietjes (talk) 15:24, 6 September 2012 (UTC)

In-line templates broken when used in numerical fields

Placing {{Citation needed}} or other similar in-line templates in auto-formatted number fields in this infobox (and possibly others) results in broken categories like Category:Articles with unsourced statements from July 2,012. Is there a way to prevent this? Editors tagging such numbers may not be familiar with the template fields, and unaware that references and such tags should go into a separate field. --115.67.34.95 (talk) 05:43, 11 September 2012 (UTC)

this has been discussed before, and there is no simple fix. the only solution right now is to check these categories and then move the tag to the corresponding "notes" or "footnotes" fields. Frietjes (talk) 17:44, 11 September 2012 (UTC)

"Auto" density should compute based on land area, not total area

Population density has to do with settle-able area. While there are cities with "houseboat" units, these are never a significant portion of any particular settlement and, if there were such a settlement, it ought to use a different template. I fear that a lot of the listed densities for cities are wrong due to this error. Zelbinian (talk) 07:30, 21 August 2012 (UTC)

100% agree. See Lauderdale-by-the-Sea, Florida whose actual population density is 6,913 persons/sqmi (when calculated based on land area) and not 3,900 persons/sqmi (when calculated based on total area). 70.42.69.221 (talk) 14:15, 21 September 2012 (UTC)

If the land area is given, sure. But if only the total area is known, the template should still display a density. —Stepheng3 (talk) 17:06, 21 September 2012 (UTC)

how about if we add the option for "density_km2 = land" to have it use the land area? Frietjes (talk) 19:28, 21 September 2012 (UTC)

We shouldn't have different instances of this template displaying values calculated using different methods, under the same heading. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:58, 21 September 2012 (UTC)

Autolinking of leader_name

The documentation says that autolinking can be disabled by addition of &nbsp;. However this doesn't seem to work. See for example Cape Agulhas Local Municipality which still links Richard Mitchell despite the entry now being Richard Mitchell &nbsp;[2]. I also tried adding &nbsp; at the beginning and in the middle all to no avail. Tassedethe (talk) 20:58, 13 October 2012 (UTC)

Cape Agulhas Local Municipality doesn't use {{Infobox settlement}} directly (which despite its documentation has no autolinking facility for |leader_name=) - it uses {{Infobox South African municipality}}. This infobox uses the parameter |muni_code=WC033 to select metadata from subtemplates; this metadata generates the link in question. In this case the subtemplate is Template:Metadata South Africa/muni/mayor. --Redrose64 (talk) 22:27, 13 October 2012 (UTC)

Thanks for the info. Tassedethe (talk) 22:38, 13 October 2012 (UTC)

Default map

I have several Texas articles that use this infobox. Someone has recently made the Texas relief map available at Template:Location map USA Texas. i would like to use the relief map instead of the flat map, and have a pushpin and pushpin label for it. How do I make that work? I've already tried inserting the Relief Map at the "pushpin map =", but it gives me an error message. I can use the relief map with "Image_map", but I have no map dot and no label. Loyal Valley, Texas is just one of many on which I use a Texas map.— Maile (talk) 18:03, 17 October 2012 (UTC)

to make this work in a very seamless manner, we would need to add "|relief={{{pushpin_relief|}}}" to the {{location map}} call in the template. until this happens, there are a couple hacks that will make it work: (1) set |pushpin_image=Relief map of Texas.png and (2) create {{Location map USA Texas relief}} which is the same as Template:Location map USA Texas, but with the image and image1 values swapped. I would recommend we do the first, add a |pushpin_relief= option to this template, and will make an edit request to add this feature. Frietjes (talk) 18:36, 17 October 2012 (UTC)

Relief maps

per this thread, please replace the code with this version which implements this change. once this is implemented, we will (1) bypass template:location map which is just a frontend for template:location map+/template:location map~, and (2) we will allow one to use a relief map by specifying |pushpin_relief=y or |pushpin_relief1=y for pushpin_map and pushpin_map1. Frietjes (talk) 18:52, 17 October 2012 (UTC)

Thank you. — Maile (talk) 19:50, 17 October 2012 (UTC)

Looks good. I will make the change. Plastikspork _―Œ^(talk) 23:32, 17 October 2012 (UTC)

Done. Please update the documentation when you have a chance. Thanks! Plastikspork _―Œ^(talk) 23:38, 17 October 2012 (UTC)

And it WORKS! Thank you. — Maile (talk) 00:07, 18 October 2012 (UTC)

Removing default pushpin map sizes?

Bangkok กรุงเทพมหานคร (Krung Thep Maha Nakhon)
City
Seal

Bangkok กรุงเทพมหานคร (Krung Thep Maha Nakhon)
City
Seal
Highest elevation
Lowest elevation

I suggest removing the default push-pin map width of 250 pixels. I.e. replacing the following line:

|width = {{#if:{{{pushpin_mapsize|}}}|{{{pushpin_mapsize|}}} | 250 }}

with:

|width = {{#if:{{{pushpin_mapsize|}}}|{{{pushpin_mapsize|}}} }}

The idea is to allow inheriting of the default width for each specific map, partly enabled by this edit to {{Location map+}}. It would allow easy fixes to settlements in places where the map is vertically oriented without having to manually specify the width in every transclusion of the template. The above example to the right is what the current template gives when the width is not manually specified, and the lower is the sandbox version with the mentioned changes.

There is a slight snag though. The default width given by {{Location map}} is 240 pixels, which would result in a slight misalignment with other images in the infobox. This could either be ignored, or the widths of the other images could be changed to 240 pixels so that they all agree. --Paul_012 (talk) 08:38, 25 October 2012 (UTC)

we could also add a defaultwidth parameter to {{location map+}}, i.e., replace every 240 in that template with {{{defaultwidth|240}}} or {{#if:{{{defaultwidth|}}}|{{{defaultwidth}}}|240}}. this would allow us to pass a value of 250 to that template. or we could have that template updated to change the 240 to 250, if there wasn't a strong reason for the 240. or, we could grab the defaultwidth from the location map here, and send it to {{location map+}}, multiplied by 1.04. Frietjes (talk) 21:16, 25 October 2012 (UTC)

I think I'll look into the first option. Need a different name for the parameter though, as {{{defaultwidth|}}} is already used. --Paul_012 (talk) 02:34, 26 October 2012 (UTC)

The parameter {{{defaultwidth|}}} is not used by {{Location map+}} as far as I can tell. The parameter {{{width|}}} is used, but not {{{defaultwidth|}}}. If you have any ideas about how to deal with very long and skinny maps, like Chile, let me know. I think we are going to eventually add an option to have very skinny location maps aligned with the flags and map next to the map. I am still pondering how best to do this in a seamless manner. Thanks! Plastikspork _―Œ^(talk) 04:41, 26 October 2012 (UTC)

The use of defaultwidth was added in this this edit. My intention was to have {{Location map+}} pull the value from each {{Location map country}} template, so that vertical maps of different proportions may have different default widths specified. I've added a value of 136 for {{Location map Thailand}}, the effect of which is visible in the lower example. It doesn't address the putting-flags-on-the-side issue, but it was a small edit. However, defaultwidth is still overridden by width, for which this template specifies a default value of 250. I've proposed an edit to add a default_width parameter to {{Location map+}}, so that it may be passed from transcluding templates such as {{Infobox settlement}}, without overriding the defaults for vertical maps. I intend to update the documentation after this has been sorted out. --Paul_012 (talk) 18:13, 26 October 2012 (UTC)

{{Location map+}} has been updated to allow a default_width parameter, which will be modified by a defaultscale parameter specified in each individual map template. Please update this template with the code in the sandbox:

|width = {{#if:{{{pushpin_mapsize|}}}|{{{pushpin_mapsize|}}}}}
|default_width = 250

--Paul_012 (talk) 10:43, 6 November 2012 (UTC)

Your proposed change introduces changes to the |label= field as well - is this intended? — Mr. Stradivarius ^{(have a chat)} 14:45, 6 November 2012 (UTC)

No, sorry; I missed that there had been subsequent changes to the live template. Sandbox now updated accordingly.[3] --Paul_012 (talk) 15:24, 6 November 2012 (UTC)

there are two pushpin maps, and the additional #if is no-longer necessary, I believe this is what you want[4]. Frietjes (talk) 15:55, 6 November 2012 (UTC)

Yes it is, thank you. --Paul_012 (talk) 06:05, 7 November 2012 (UTC)

Ok, Done. — Mr. Stradivarius ^{(have a chat)} 12:44, 7 November 2012 (UTC)

Parameters ignored??

After trying for several days to get a different pushpin_mark and size, looking here suggests that the mark parameter itself is ignored and the size is fixed as 6. Or am I reading this wrong? - I don't know much about wikimarkup and templates etc. Float too seems ignored. Check out Yao Islet for example. Johnmperry (talk) 09:03, 14 November 2012 (UTC)

Double column "parts"?

In the Philippines, the fourth level of administration is the municipality which itself comprises a number of lower levels called barangays. These barangays have both a name and a number, which isn't necessarily contiguous, and the ordering is not necessarily alphabetic either, as new ones are just added to the end of the list, without re-numbering. Look at Bantayan, Cebu - the wiki link on each barangay name includes the number (three digits with leading zeros).

What I would like is two columns of parts:

p1-name   p1

thru

p50-name   p50

Perhaps with indenting the first column. What chance? Johnmperry (talk) 09:33, 14 November 2012 (UTC)

In fact three or four columns would be even better - I could add in population without needing to create a separate page for it. Something like:

p1_col1     p1     p1_col3

thru

p50_col1    p50    p50_col3

or remap existing, i.e. make both columns available for users to format as they require . Johnmperry (talk) 13:01, 14 November 2012 (UTC)

Forget I spoke - I have set up an ad-hoc infobox outside. Johnmperry (talk) 07:41, 15 November 2012 (UTC)

Can't add ref field to area

... it throws a syntax error wobbler, presumably because it is trying to convert to numeric Johnmperry (talk) 12:52, 14 November 2012 (UTC)

The infobox should summarise data which is also in the body of the article; that's where the reference belongs. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:08, 14 November 2012 (UTC)

That's exactly the opposite of my thinking. First of all, it is completely silly to replicate data - I'm a third normal form fan. Secondly, an infobox is there for at-a-glance statistics that you wouldn't easily glean from the article body. That's if they were even there, which I doubt. Johnmperry (talk) 07:46, 15 November 2012 (UTC)

use |area_footnotes=. Frietjes (talk) 15:02, 14 November 2012 (UTC)

10 hectares

This template displays area_total_ha=10 as "10 ha (0 acres)". Somewhere inside {{Infobox settlement/areadisp}}, the code is trying to choose an appropriate level of rounding and is losing too many significant figures:

• {{Infobox settlement/areadisp|ha=8}} --> 8 ha (20 acres)
• {{Infobox settlement/areadisp|ha=9}} --> 9 ha (22 acres)
• {{Infobox settlement/areadisp|ha=10}} --> 10 ha (20 acres)
• {{Infobox settlement/areadisp|ha=11}} --> 11 ha (27 acres)
• {{Infobox settlement/areadisp|ha=12}} --> 12 ha (30 acres)

-- John of Reading (talk) 16:43, 14 November 2012 (UTC)

I noticed this also. the problem appears to be with using {{precision}} without checking for negative values:

• {{precision|8}} --> 0
• {{precision|9}} --> 0
• {{precision|10}} --> -1
• {{precision|11}} --> 0
• {{precision|12}} --> 0

Frietjes (talk) 17:10, 14 November 2012 (UTC)

note the current work-around is

• {{Infobox settlement/areadisp|ha=10.}} --> 10. ha (25 acres)
• {{Infobox settlement/areadisp|ha=10.0}} --> 10.0 ha (24.7 acres)

Frietjes (talk) 17:15, 14 November 2012 (UTC)

Gets it wrong with 100 too Johnmperry (talk) 00:37, 15 November 2012 (UTC)

okay, I may have fixed it, check

• {{Infobox settlement/areadisp/sandbox|ha=8}} --> 8 ha (20 acres)
• {{Infobox settlement/areadisp/sandbox|ha=9}} --> 9 ha (22 acres)
• {{Infobox settlement/areadisp/sandbox|ha=10}} --> 10 ha (20 acres)
• {{Infobox settlement/areadisp/sandbox|ha=11}} --> 11 ha (27 acres)
• {{Infobox settlement/areadisp/sandbox|ha=12}} --> 12 ha (30 acres)

Frietjes (talk) 01:27, 15 November 2012 (UTC)

Depends on your definition of "fixed"! 8 ha = 20 acres, 9=22, 10=25 11=27,12=30. It might be close enough for big numbers, but it's a too wrong here. I don't know why the coding is so convoluted when it could all be done with a single call to {{convert}} Johnmperry (talk) 07:59, 15 November 2012 (UTC)

Well it's still not right - gives 150 ha as 400 acres, which is nearly 10% wrong. Maybe the function should be renamed to imprecision? ;-) Johnmperry (talk) 12:44, 15 November 2012 (UTC)

Regarding {{convert}} vs {{#expr:}}, please see my reply here. --Redrose64 (talk) 10:42, 15 November 2012 (UTC)

I'm sorry but that is a feeble answer. When I first started programming in 1969 I was told things like "Don't use the compute verb, it's very inefficient." Maybe it was. So people would spend hours, days, getting results (and trying to debug them) with BCD and DCB and shift left and shift right and whatever else. Meanwhile, compute became the way to go. In fact, the only way to go. If code is inefficient, the answer isn't to ignore it, but to hone it so it is not inefficient. Nothing lasts forever. There is a saying "if the only tool in your toolbox is a hammer, everything looks like a nail". Time to get more tools, apart from the Manchester screwdriver. Johnmperry (talk) 12:44, 15 November 2012 (UTC)

My answer may seem "feeble", but I dislike posting the same thing in multiple threads. The problem with the COMPUTE verb is that its action varies between compilers (even versions). I was taught to use ADD, SUBTRACT, MULTIPLY and DIVIDE because their actions were consistent within the limitations of a given data division picture. But that is beside the point. Wiki markup is not terribly efficient to begin with, and once we start building complex templates we soon realise the limitations. Discussions of this nature are a regular feature at WP:VPT where I have spent some three years reading and assisting with the questions posed there. Once we have mw:Lua we shall rewrite many of the calculation-heavy templates; until then, we make the best of what we've got, such as the 40-level transclusion limit. --Redrose64 (talk) 13:42, 15 November 2012 (UTC)

Error in line 460?

You reference _blank2_acre but I think it should be _blank1_ (same as rest of line). Johnmperry (talk) 00:34, 15 November 2012 (UTC)

yes, that is a typo, please make this change. Frietjes (talk) 01:16, 15 November 2012 (UTC)

You talking to me, or any passing admin? Johnmperry (talk) 02:01, 15 November 2012 (UTC)

Done The attention of any admin who has Template:Infobox settlement on their watchlist; or one who has User:AnomieBOT/PERTable on their watchlist; or one who monitors Category:Wikipedia protected edit requests is drawn by the presence of an unanswered {{edit protected}}, see WP:EDITREQ. I'm in groups 1 and 2. --Redrose64 (talk) 10:15, 15 November 2012 (UTC)

Another error?

I don't understand the half dozen lines of code from 158 onwards. Apart from the fact that the variables don't appear to be used again, it's a very strange use of 'float', because all other instances of it treat is as left|right|center etc. Johnmperry (talk) 16:29, 16 November 2012 (UTC)

What is on line 158? The Wiki edit window has no line numbering. --Redrose64 (talk) 17:15, 16 November 2012 (UTC)

|float = Red pog.svg
|float_width = 6px
|float_alt = {{{dot_map_alt|}}}
|float_caption = {{{dot_map_caption|}}}
|x = {{{dot_x|}}}
|y = {{{dot_y|}}}


I have to copy out of the box, but I can't paste straight into notepad becasuse the line terminator isn't right. So it has to go via wordpad. Notepad without word wrap lets you see line number. I suppose I could paste to Word, which can even put line numbers on the page, but hey! wikiedit development item?? Johnmperry (talk) 17:35, 16 November 2012 (UTC)

It's part of a larger chunk which reads, in full,

<!--***Dot Map*** -->
{{#if:{{{image_dot_map|}}}|
<tr class="mergedrow">
<td colspan="2" style="text-align:center" align="center"><center>{{superimpose
|base = {{{image_dot_map|}}}
|base_width = {{px|{{{dot_mapsize|}}}|180px}}
|base_alt = {{{dot_map_base_alt|}}}
|base_caption = {{#if:{{{official_name|}}}|{{{official_name|}}}|{{{name}}}}}
|float = Red pog.svg
|float_width = 6px
|float_alt = {{{dot_map_alt|}}}
|float_caption = {{{dot_map_caption|}}}
|x = {{{dot_x|}}}
|y = {{{dot_y|}}}
}}{{#if:{{{dot_map_caption|}}}|<small>{{{dot_map_caption}}}</small>}}</center>
</td>
</tr>
}}

This lot checks that |image_dot_map= is non-blank; if so, it adds a row to the infobox; the row consists of a single cell two columns wide. The cell contains one or two items: the first item is an instance of the {{superimpose}} template, the second consists of the value passed in |dot_map_caption=, provided that is non-blank. Returning to {{superimpose}}: that is supplied with ten parameters, six of which are the ones that you list above. All of them are described on the documentation for that template. |float=Red pog.svg indicates that the superimposed dot is to be shown using File:Red pog.svg; |float_width=6px gives the size of that dot; |float_alt={{{dot_map_alt|}}} and |float_caption={{{dot_map_caption|}}} indicate that two items of text are to be taken from the |dot_map_alt= and |dot_map_caption= parameters that were passed into {{Infobox settlement}}; and |x={{{dot_x|}}}|y={{{dot_y|}}} indicate that the dot position is to be taken from the |dot_x=|dot_y= parameters that were passed into {{Infobox settlement}}. --Redrose64 (talk) 18:00, 16 November 2012 (UTC)

Sorry for wasting your time. I wonder why the writer chose such parameter names. I hope lua is better than this! Johnmperry (talk) 18:08, 16 November 2012 (UTC)

the whole image_dot_map is a leftover from a long time ago, and is basically deprecated now in favour of {{location map}}s. you will find a lot of strange parameter names that are left over from long ago. Frietjes (talk) 21:29, 16 November 2012 (UTC)

Formatting of nickname looks ghastly

Look at Silion Island. It has no background colour, and it's in a different font from its surrounds. Can something be done? Johnmperry (talk) 16:33, 16 November 2012 (UTC)

it looks fine to me, but you can always use |other_name= or |native_name=. Frietjes (talk) 21:30, 16 November 2012 (UTC)

That looks better thanks Johnmperry (talk)
—Preceding undated comment added 02:00, 17 November 2012 (UTC)

I'm surprised media has been overlooked

Content such as local radio (tv) station, local newspaper.

I know, I know, use the spare fields Johnmperry (talk) 01:41, 17 November 2012 (UTC)

Another not-quite-right

image_skyle does not align properly. It's fine on my pc, because the infobox is the same size. When I look on my tablet though the infobox is much wider, and image_skyline is aligned left within the box. I tried adding |center after the image name, and while it didn't grumble, it didn't do anything either. Look at Santa_Fe,_Cebu Johnmperry (talk)
—Preceding undated comment added 12:26, 18 November 2012 (UTC)

I suspect that this is nothing to do with {{infobox settlement}} per se, but another of those annoying differences between MediaWiki:Common.css and MediaWiki:Mobile.css. --Redrose64 (talk) 19:37, 18 November 2012 (UTC)

Well I'm sure you're right, but that doesn't help me. It's only image_sky which is wrong, other graphics such as pushpin_map are OK. If you look at lines 164 and 190 you will see that pushpin_map is surrounded by <center>...</center> and image_sky isn't

<td colspan="2" style="text-align:center" align="center"><center>
{{location map+|{{{pushpin_map|}}}
|border = none
|alt = {{{pushpin_map_alt|}}}
|caption =
|float = none
|width = {{{pushpin_mapsize|}}}
|default_width = 250
|relief= {{{pushpin_relief|}}}
|AlternativeMap = {{{pushpin_image|}}}
|places = {{Location map~|{{{pushpin_map|}}}
 |label = {{#ifeq: {{lc: {{{pushpin_label_position|}}} }} | none | | {{#if:{{{pushpin_label|}}}|{{{pushpin_label}}}|{{#if:{{{name|}}}|{{{name}}}|{{{official_name|}}}}}}} }}
 |lat = {{#if:{{{latm|}}}{{{latNS|}}}| |{{{latd|}}} }}
 |long = {{#if:{{{longm|}}}{{{longEW|}}}| |{{{longd|}}} }}
 |lat_deg={{#if:{{{latm|}}}{{{latNS|}}}|{{{latd|}}}| }}
 |lat_min={{#if:{{{latm|}}}{{{latNS|}}}|{{{latm|}}}| }}
 |lat_sec={{#if:{{{lats|}}}{{{latNS|}}}|{{{lats|}}}| }}
 |lat_dir={{#if:{{{latNS|}}}|{{{latNS|}}}| }}
 |lon_deg={{#if:{{{longm|}}}{{{longEW|}}}|{{{longd|}}}| }}
 |lon_min={{#if:{{{longm|}}}{{{longEW|}}}|{{{longm|}}}| }}
 |lon_sec={{#if:{{{longs|}}}{{{longEW|}}}|{{{longs|}}}| }}
 |lon_dir={{#if:{{{longEW|}}}|{{{longEW|}}}| }}
 |marksize =6
 |position = {{{pushpin_label_position|}}}
 }}
}}{{#if:{{{pushpin_map_caption|}}}|<small>{{{pushpin_map_caption}}}</small>|{{#if:{{{map_caption|}}}|<small>{{{map_caption}}}</small>}}}}
</center></td>


{{#if:{{{image_skyline|}}}|
<tr><!-- ***Skyline Image*** -->
<td colspan="2" style="text-align:center; padding:0.7em 0.8em">[[File:{{{image_skyline}}}|{{#if:{{{imagesize|}}}|{{{imagesize}}}|250px}}|none|alt={{{image_alt|}}}|{{{image_caption|Skyline of {{#if:{{{name|}}}|{{{name}}}|{{{official_name}}}}}}}}]]{{#if:{{{image_caption|}}}|<small>{{{image_caption}}}</small>}}</td>
</tr>

It seems like <center> isn't as deprecated as I thought! Johnmperry (talk) 23:24, 18 November 2012 (UTC)

I was going to mention too about higgledy-piggledy output. However this seems to be a rendering dispute between browsers - it comes out better on Chrome than in MSIE. Chrome is in the office of course, no way would I have it on my own computer. Ditto firefox - complete pants anyway, depart of last resorts. John of Cromer in China (talk) mytime= Mon 12:07, wikitime= 04:07, 19 November 2012 (UTC)

The difference is primarily in how the CSS class "geography" is handled. There is plenty of styling for this in MediaWiki:Common.css, none whatsoever in MediaWiki:Mobile.css. I shall alert MediaWiki talk:Mobile.css. --Redrose64 (talk) 09:55, 19 November 2012 (UTC)

There has been a response at MediaWiki talk:Common.css#The geography class in Mobile view. --Redrose64 (talk) 13:26, 19 November 2012 (UTC)