Template talk:Convert

For the technical discussion of template design see Template talk:Convert/Technical

Please change default double output to default single output: "1 carat (0.20 g; 3.1 gr)" to "1 carat (0.20 g)"

The default output for carats is:

• "1 carat (0.20 g; 3.1 gr)"

please can we change it to

• "1 carat (0.20 g)"

Regards Lightmouse (talk) 09:41, 28 July 2011 (UTC)

Why? ― A. di M.​_plé​^dréachtaí 12:02, 31 July 2011 (UTC)

Consider the following:

• a large 52 carat (10 g) sapphire ring

The grain value is only necessary if Americans understand neither the carat nor the gram values. Is it normal in America to say "a 160 grain sapphire ring"? Lightmouse (talk) 12:29, 31 July 2011 (UTC)

Any more comments? Lightmouse (talk) 16:35, 20 August 2011 (UTC)

I can't speak for Americans, but I don't see any reason to change the default here. I'm presuming the reason we default to two units is that none of the three unit is universally more commonly understood than the others. If for stylistic or other reasons two conversions are not appropriate in some circumstances then the default can be overridden for those pages without reducing the informativeness elsewhere. Thryduulf (talk) 21:44, 20 August 2011 (UTC)

i vote for removing the grain amount, and only showing gram. my reasoning is that people who use traditional units (carats, grains), use one unit for one purpose. they won't want to know a gem in grains, they want to know it in carats. one-unit-for-everything is the SI philosophy.Bewareircd (talk) 08:18, 29 August 2011 (UTC)

The default-default is one output only. Each case of non_default-default needs a strong case. Some, like this one, are just legacy that hasn't been challenged lately. This should be reset to the default single output unless anyone claims formats like "a large 52 carat (10 g) sapphire ring" need the value in grains. Lightmouse (talk) 13:07, 21 August 2011 (UTC)

Any further thoughts? Lightmouse (talk) 14:50, 10 September 2011 (UTC)

The default should be "a large 52 carat (10 g) sapphire ring". As far as I know, the grain value adds no value in that phrase. Can we make the change please? Lightmouse (talk) 11:54, 2 October 2011 (UTC)

Done. JIMp _talk·cont 04:47, 3 October 2011 (UTC)

Thank you. Lightmouse (talk) 07:45, 3 October 2011 (UTC)

Please change US pint default output to suit majority need

• 8 US pints (3.8 L; 6.7 imp pt)

The US pint is converted by default to ml and imp fl oz. The majority need for US pint conversion doesn't include imp fl oz. It may also be that litre is better than ml, but that's another issue. We have (or should have) a higher standard for multiple output defaults. In the few cases where the imp fl oz is needed, it can be specified. Please can the default be updated? Lightmouse (talk) 11:44, 31 July 2011 (UTC)

It should convert to litres and imperial pints, for consistency with the imperial pint which converts to litres and US pints (13 imperial pints (7 L)): in the situations where an American uses small pints, a Briton uses large pints and a continental European uses litres. ― A. di M. _plé ^dréachtaí 12:01, 31 July 2011 (UTC)

You say there's 1:1 usage between Americans and British pints but the ratio is a *lot* more imbalanced. The pint commonplace in the US but legacy in the UK except for one notable exception: draught beer (bottles and cans are ml). The litre is the default unit in the UK. There's no need for Wikipedia to turn back the clock to the days of Empire and the colonies. Lightmouse (talk) 12:41, 31 July 2011 (UTC)

Don't they use (milli)litres and/or fluid ounces for bottles and cans in the US, too? Also, that “one notable exception” makes up for a sizeable fraction (if not the majority) of all the times I've ever used any unit of volume when speaking English. ― A. di M. _plé ^dréachtaí 12:46, 31 July 2011 (UTC)

Yes, Americans use fluid ounces but it's the US one, not the old British Empire version. Yes, the pint of draught beer is a *notable* exception and your experience fits with that. It's great that the template permits multiple outputs by choice. But Wikipedia articles aren't dominated by beer usage. they add clutter and are only *default* as exceptions. In this case, we should reset it back to the normal convention of only a single default output. Lightmouse (talk) 13:20, 31 July 2011 (UTC)

My point is that even in American articles pints are much more likely to be beer or milk than petrol or Sprite (the latter would likely use gallons and litres/ounces respectively, instead), so converting to imperial pints seems reasonable to me. (Also, the difference between a US fluid ounce and an imperial one is quite small, so I wouldn't normally worry about that: if they are rounded to two sigfigs you can't even always see the difference (12 US fluid ounces (12 imp fl oz)) and more precise measurements than that are likely to come from technical contexts where it's unlikely they'd use ounces in the first place). ― A. di M. _plé ^dréachtaí 14:34, 31 July 2011 (UTC)

As far as I can detect, the 'USpt' or 'U.S.pt' template option is only used as input in:

Article	Default chosen?	What was done	Default imp fl oz output appropriate?	imp pt output appropriate?	L or ml only output appropriate?
Energy star	No	Chose to output in litres only	No	No	Yes
Hypovolemia	No.	Chose to output in litres only	No	No	Yes
Ink cartridge	Yes		No	No	Yes
Milk	Yes		No	No	Yes

In all cases here, the litre-only output was either chosen or would have been appropriate. It may only be four instances for this unit but it's an indication that other multi-output *defaults* are excessive. Lightmouse (talk) 11:38, 1 August 2011 (UTC)

How is the imperial pint inappropriate in Milk? According to *that same article*, in the UK “[m]ost stores stock imperial sizes: ... or a combination including both metric and imperial sizes. Glass milk bottles ... are typically pint-sized...” As for hypovolemia, I did heard about pints of blood in Ireland once (though I admit that a sample size of 1 is insufficient). (I have no idea of how dehumidifiers are rated in the UK and I didn't even know they sold printer ink in bulk, so I won't comment on the other two.) ― A. di M. _plé ^dréachtaí 13:12, 1 August 2011 (UTC)

Let's look at each conversions within the article:

• In the Milk article it has a section about *America* that says:
  • The .5 US pints (0.24 L; 0.42 imp pt) milk carton is the traditional unit as a component of school lunches, though some companies have replaced that unit size with a plastic bottle, which is also available at retail in 6 and 12-pack size.
  • It's describing an American carton of 0.5 US pint. The ml conversion as required by UK law is appropriate for British readers. The "8.3 imp fl oz" is weird and "0.42 imp pints" wouldn't be an improvement.
• In the hypovolemia, the editor chose to convert US pints into litres. I would have done the same. British and Irish medicine uses litres to measure blood. Any mention of 'pints' is colloquial and just means an amount that could range from 400 to 600 ml. In any case, we're straying from the point - real conversions from US pints only need ml or litres.

I hope that helps Lightmouse (talk) 14:09, 1 August 2011 (UTC)

• Agree. So, the change will be inside Template:Convert/USpt to set "|o=ml" (rather than "|o=ml impoz"). -Wikid77 17:05, 1 August 2011 (UTC)

  In any event, litres would be more appropriate than millilitres, IMO. ― A. di M. _plé ^dréachtaí 15:14, 2 August 2011 (UTC)

The one in hypovolemia isn't about “medicine”, it's about a f***in' film, for heaven's sake. What would be wrong with using a “colloquial” unit there? I'm not sure the movie used US pints in the first place because that's what US medicine uses, either. (And the fact that UK law “requires” millilitres doesn't, by itself, mean that they're commonly used: for that matter, the EU requires energy values in kilojoules on food labels, but I don't think I've ever heard an European use kilojoules for that unless they were compelled to. ― A. di M. _plé ^dréachtaí 15:14, 2 August 2011 (UTC)

The Hypovolemia article has a litre-only conversion. We don't know what you think it should say. Please can you show us? 15:46, 3 August 2011 (UTC)

Any response? We'd like to make progress. Lightmouse (talk) 15:24, 10 August 2011 (UTC)

Any response from anyone? Lightmouse (talk) 16:34, 20 August 2011 (UTC)

Any further thoughts? Lightmouse (talk) 14:50, 10 September 2011 (UTC)

This has been fully explored. Can we make the change please? Lightmouse (talk) 11:54, 2 October 2011 (UTC)

Done. JIMp _talk·cont 04:48, 3 October 2011 (UTC)

Thank you. Lightmouse (talk) 07:45, 3 October 2011 (UTC)

Kelvin

• 1 K (−272.15 °C; −457.87 °F) -> "1 K (−272.15 °C; −457.87 °F)"
• 1 K (−272.15 °C; −457.87 °F) -> "1 K (−272.15 °C; −457.87 °F)" - should be 1 kelvin (−272.15 °C; −457.87 °F)

Lightmouse 09:20, 13 August 2011 (UTC)

Since the template's creation temperatures have defaulted to the abbreviated form. I suppose Drumguy did it this way since "°C" and "°F" are more common than their spelt-out forms. To change this now would almost certainly lead to chaos. When I added kelvins and degrees Rankine I followed this for consistency. You might argue, though, that since these are not as well known they should be spelt out by default but my gut feeling is that this could lead to potential ugliness like "1 kelvin or −272.15 °C" (whereas you'd prefer the consistency of "1 K or −272.15 °C" ... or at least I would). Note that {{convert|1|K|abbr=out}} is now working and will give the result you desire (but {{convert|1|K|abbr=off}} is broken). JIMp _talk·cont 02:19, 14 August 2011 (UTC)

Interesting and understandable. I didn't realise all temperature units were anomalous. If I understand it correctly, the migration to consistency is easy:

• Bot run to add '|abbr=on' as required
• Update the default.

I can't see any downsides to that. I think it's worth doing. Lightmouse (talk) 12:44, 21 August 2011 (UTC)

Any further thoughts? Lightmouse (talk) 14:50, 10 September 2011 (UTC)

The change would be as follows:

Step 1: Do a bot run to add '|abbr=on' to templates using C, F, or K (with or without '°').

Step 2: Change the default to abbr=off

If I do step 1, is anybody willing to do step 2? Lightmouse (talk) 13:08, 19 September 2011 (UTC)

I could look into it. I do prefer consistency. My only worry here is that we might start seeing a whole lot of "degrees Celsius" and "degrees Fahrenheit" spelt out in all their glory when we'd prefer the abbreviations. People will almost surely neglect to turn the abbreviations on. JIMp _talk·cont 01:22, 20 September 2011 (UTC)

It's a legitimate worry. But I don't think it'll be a major problem and at least it's a correct format. There are already lots of incorrect formats like '22 C', '14 degrees', '12degF'. But I'm planning on doing a bot run on temperatures to fix all these. I'm quite keen on the convert template improving consistency across WP and within itself (hence the attempt to reduce low-added-value double output units). Lightmouse (talk) 18:32, 20 September 2011 (UTC)

Convert e9m3 with abbr=off

I have a rare case of converting a "33-billion-cubic-meter" amount, but the "abbr=off" did not work with adj=on, so I hard-coded the conversion as the "1,200-billion-cubic-foot" result (in article "Economy of Israel"). As always, I hard-code the conversion when it is a rare option, to allow more weeks to fix it. The current status:

• {{convert|33|e9m3|e9cuft|adj=on}}       → 33-billion-cubic-metre (1,200×10^⁹ cu ft)
• {{convert|33|e9m3|e9cuft|abbr=off}}      → 33 billion cubic metres (1,200 billion cubic feet)
• {{convert|33|e9m3|e9cuft|adj=on|abbr=off}} → 33-billion-cubic-metre (1,200-billion-cubic-foot)

I am still looking, in Template:Convert/LoffAnoneDbSonEng, to see why the final "cubic-foot" gets a calculation error, after correctly showing "1,200 billion". Internally, the singular {{{n}}} should be "cubic foot" but shows "{{{n}}}" by plural "cubic feet" for {{{l}}}. It is a very rare conversion, so there is no hurry to fix the problem. -Wikid77 (talk) 11:19, 17 September 2011 (UTC)

Somehow a comma was finding its way into an #expr ... JIMp _talk·cont 02:15, 20 September 2011 (UTC)

That's got half the problem fixed but somehow the template seems to be forgetting adj=on by the time it gets to the output unit. JIMp _talk·cont 03:27, 20 September 2011 (UTC)

Fixed. JIMp _talk·cont 06:16, 20 September 2011 (UTC)

There is still some problems as {{convert|2.8|to|3.3|e12oilbbl|e9m3|abbr=off}} for Oil shale article does not work. Another problem occurred with [edit] by Lightbot. Beagel (talk) 16:05, 26 September 2011 (UTC)

I notice from your contributions you've been helping a lot with oil and gas articles. Thanks. I'm a frequent user of this template but I don't understand all permutations. I look forward to seeing what others say about these problems. Lightmouse (talk) 16:22, 26 September 2011 (UTC)

conversion of regionally used units

It would nice to have the ability to use the convert template for regional units such as below:

• bigha
• ropani
• or any listed here Indian weights and measures

more info here

I come across these from time to time patrolling new articles, particularly on India, and would like to make them more accessible to readers by converting them to units more recognizable worldwide.--RadioFan (talk) 14:07, 18 September 2011 (UTC)

It would be nice, yes, however there seems to be a rather major problem here. I've just had a look at the article you link to and discovered that there is no consistent definition for the unit. We cannot just choose one as the official bigha. If we do that, we're sure to get miscalculations. We'd have to have several: bigha (Assam), bigha (Himachal Pradesh), bigha (central India), bigha (Madhya Pradesh), bigha (Uttar Pradesh), bigha (Uttaranchal), bigha (West Bengal), bigha (Bangladesh), bigha (Nepal), bigha (Fiji) ... Which would be used? Which would be misused? JIMp _talk·cont 01:50, 20 September 2011 (UTC)

Yuck. I see your point. It sounds like the best course of action is to discourage use of these regionalized measurement systems where there is no consistent conversion possible. --RadioFan (talk) 18:21, 20 September 2011 (UTC)

Volume divided by time

Can we have volume divided by time conversion? For example:

• 1,000 cubic feet per year (0.90 m³/Ms)
• 1,000 cubic feet per minute (28 m³/min)
• 1,000 cubic metres per minute (35,000 cu ft/min)

Lightmouse (talk) 15:38, 20 September 2011 (UTC)

Cubic feet per year exists in the form of cuft/a ("a" for "annum"). I'll look into the other two. JIMp _talk·cont 23:21, 20 September 2011 (UTC)

1,000 cubic feet per annum (28 m³/a)

Done. JIMp _talk·cont 00:19, 21 September 2011 (UTC)

Thanks. Can you also do other unit permutations:

• 1,000 inches per day (290 mm/ks)
• 1,000 square kilometres per day (4.5 sq mi/ks)
• 1,000 kilometres per day (620 mi/d)
• 1,000 cubic centimetres per day (0.71 cu in/ks)
• 1,000 cubic millimetres per day (0.00071 cu in/ks)
• 1,000 cubic kilometres per day (3.5×10¹³ cu ft/d)
• 1 to 1,000 cubic kilometres per day (3.5×10¹⁰ to 3.5315×10¹³ cu ft/d)
• 1,000 billion US gallons per day (44,000 m³/s)
• 1 to 1,000 US gallons per day (4.4×10⁻⁸ to 4.3813×10⁻⁵ m³/s)
• 1 to 1,000 billion US gallons per day (44 to 43,813 m³/s)

Lightmouse (talk) 11:28, 21 September 2011 (UTC)

Also:

• 1 to 1,000 barrels per second (9.5 to 9,539.2 m³/min)
• 1,000 barrels per second (9,500 m³/min)
• 1,000 barrels per minute (2.6 m³/s)
• 1,000 barrels per hour (44 m³/ks)
• 1,000 million barrels (160,000,000 m³)
• 1,000 billion barrels per day (1.6×10¹¹ m³/d)

Regards Lightmouse (talk) 14:24, 22 September 2011 (UTC)

An apparent inconsistency

Look at the following:

• 1 million cubic feet (28×10^³ m³)
• 1 million cubic feet (28,000 m³)

Why are the output formats different? Lightmouse (talk) 14:37, 22 September 2011 (UTC)

The formats are different because the output default for e6cuft is not m3 but e3m3 or e6m3 (depending on size). These e3, e6, e9, etc. codes serve two purposes: they either add "thousand", "million", "billion", etc. or they output engineering notation. Which of these is actually output depends on whether or not we're using the abbreviated form. When they were created what I had in mind is that it would make sense to go from e3, e6, e9, etc. to e3, e6, e9, etc. (e.g. e3cuft to e3m3). Well, it does make sense if the input and output are in the same form (with respect to abbreviation) but where they are different (as in the example above) it doesn't. I wouldn't mind if we change it but it would be good if we could have a bot go through and find any transclusions with an e3, e6, e9, etc. input plus abbr and/or disp set (to something other than the default) since abbr or disp can be used to make the output & input the same with respect to abbreviation. JIMp _talk·cont 23:59, 25 September 2011 (UTC)

I'd be happy to do this by bot although I don't quite understand all the permutations. Can you provide:

• A sample list of target units to get me started - it doesn't need to be complete. If this extends into units outside my existing bot scope, I'll need to apply for an extension. That's not a bad thing, it's just to let you know there'll be a delay before I can address those units.
• The range of 'e'. I know it goes from 3 to 12 but I don't know if it goes lower or higher.
• If it applies to all values of 'disp'. It's much easier to code if I simply detect the presence or absence of disp. I don't quite understand the role of 'disp' in this issue.
• Some examples of the before and after permutations you'd like. I understand the principle of your explanation but I don't quite get how it works in detail.

Lightmouse (talk) 08:43, 26 September 2011 (UTC)

What's the difference

Between 'e6' and 'M' in the following:

• 1 million cubic feet (28×10^³ m³)
• 1 million barrels (160×10^³ m³)

Lightmouse (talk) 17:11, 22 September 2011 (UTC)

The difference shows up when the input is abbreviatied.

• 1×10^⁶ cu ft (28×10^³ m³)
• 1 Mbbl (160×10^³ m³)

JIMp _talk·cont 00:01, 26 September 2011 (UTC)

Ah. I see. Thanks. Lightmouse (talk) 08:28, 26 September 2011 (UTC)

Possible validation of first number

Important: I think we need to validate the first number, despite the overhead, to reject a decimal comma, of the form "1,35" and require "1.35" because "1,35" is treated as "135" and quietly gives the wrong conversion:

• {{convert|1.35|m|ft}} → 1.35 metres (4.4 ft)

• {{convert|1,35|m|ft}} → 135 metres (443 ft) -- as of 7 Oct 2011

As you know, there are thousands of articles being translated from other languages where the "decimal point" is the comma, such as "4,73" meaning "4.73" and unfortunately, that gets accepted as 473 because, in recent years, we ran decomma by {FORMATNUM:|R} for readability of "20,000,000" (not 20000000). Note: these decimal commas had been rejected by Convert years ago, but then we used FORMATNUM and we did not create a "smart" {{Decomma}} to check for invalid use of commas. The overhead could be kept minimal by only validating input which contains commas:

• {{#ifeq: z{{{1}}}|z{{FORMATNUM:{{{1}}}|R}}
       |<!--then no comma-->{{{1}}}
       |<!--else validate for commas-->{{Decomma|{{{1}}} }} }}

Then check for invalid-comma numbers, such as too short, when "55,6" or "1,35" (without commas) compares as less than 1000. That would even quickly reject "1,00.97" as invalid, rather than convert it as 100.97.

The validation by Template:Decomma would only be run on the first number, after a 2-depth-level check for commas. Due to all the interwiki translations, as well as many English-as-second-language editors, I think this might be a critical issue. In many German-based articles, the areas are given as 2-decimals, "xx,xx". The result for "1,35" (as 135) is off by a factor of 100x, not just a 5% error, but a 10,000% error in some articles. I try to focus on major issues of concern. There's no hurry on this, and we could create a temporary category (for Decomma) to log how often 1 or 2-place decimal commas are being used in Convert, to prove what size numbers are a common problem. -Wikid77 (talk) 10:34, 23 September, revised 12:55, 7 October 2011 (UTC)

I have the following comments:

• It's a pity that we can't accept both the period and the comma as a decimal separator. Could we have an option?
• It's common for Indians to express numbers as 1,00,000 because of they way their numbering system works. We need to be careful not to reject those as incorrect decimals.

Lightmouse (talk) 10:46, 23 September 2011 (UTC)

But how can you tell what 1.001 and 1,001 mean? Do they mean a number close to one or one thousand? Sadly, there is no way to tell in these cases and we must therefore default to the symbols used by native English speakers. Other languages Wikipedias should, of course, default to their own styles.  Stepho  talk  13:52, 23 September 2011 (UTC)

• Limit within 4-digit numbers: If we restrict validation to comma-only numbers, I think we could also limit validation to at most 10,000, rejecting "xx,xx" or "xxx,x" or "x,xx" (etc.) by checking for "x," in 4-digit amounts or reject n < 1,000 as not valid with commas. So that would allow any large numbers, such as "1,00,000" to be valid. I favor rejecting only the troublesome amounts, and not accept "1,50" (as neither 1.50 nor 1500) but an invalid typo. Meanwhile, FORMATNUM in other-language Wikipedias removes dots "." and leaves the decimal-comma such as in "20.000.000,125". -Wikid77 14:23, 23 September 2011 (UTC)

This is a worthwhile idea. {{Decomma}} could place all those articles which have a number formatting problem into a special category. Editors could then go to these problem articles and fix them by hand. I'm afraid, Lightmouse, that I must respectfully disagree with what I read you as suggesting. We cannot and should not accept the comma as anything but a separator for positive integer powers of one thousand (when it comes to numbers, sentences are another story). "1,35" for 1+35⁄100 is not valid in English nor is "1,00,000". This is the English WP. We should be writing in English, not German, not French, not Hindi. JIMp _talk·cont 00:22, 26 September 2011 (UTC)

This change is the first (that I'm aware of) that destroys international neutrality in the template. It's easy for the dominant cultural users to take international conveniences away in many small pieces, particularly if the programmers are in that culture. It's possible to require multiple regional interfaces but it's better if a universal high-quality interface has international scope.

I'm not convinced you're correct to say 1,00,000 isn't valid in English, although it may depend on your definition of 'valid'. I think that format is used in India, Bangladesh, Nepal, and Pakistan, some of those countries have English as an official language and it's not just used by Hindi speakers. I'm not sure about cause and effect but it's consistent with the use of crore and lakh. I'm not a big fan of crore and lakh or that format but I'm trying to make sure we don't add an inconvenience. I'm more concerned about resolving the decimal separator issue. Is the convert template really only used on en.wiki? Lightmouse (talk) 08:26, 26 September 2011 (UTC)

User:Jimp wrote "This is the English WP. We should be writing in English, not German, not French, not Hindi". Which variant of English should we be using? The variant used in the SI Brochure uses spaces as 1000's separators, not commas. South Africa, where English is an offical language, the mother tongue of a sizable minority and that country's lingua franca uses commas as a decimal separator. I think that we should take note of the conventions adopted by The Times of India regarding the use of the crore and the lakh in matters pertaining to the South Asian subcontinent - after all The Times of India is the world's largest English language newspaper. Martinvl (talk) 09:49, 26 September 2011 (UTC)

If you write things in Hindi style then only Hindi readers will understand it - leaving out the rest of the world. If you write it in US or UK style then all English readers will understand it. Aim for the wider audience. Aim for it to be unambiguous.  Stepho  talk  10:04, 26 September 2011 (UTC)

What is 'Hindi style'? Lightmouse (talk) 10:19, 26 September 2011 (UTC)

I meant the 1,00,000 style that you mentioned in the context of Hindi speakers. Apologies if I got the name wrong or offended anyone.  Stepho  talk  10:50, 26 September 2011 (UTC)

The 1,00,000 style isn't related to Hindi. It's used by English speakers. Lightmouse (talk) 11:01, 26 September 2011 (UTC)

I see the template is used directly or translated into at least 16 languages. It may be used on more than one wiki within each language. I suspect translation only involves unit names. If this is an important issue, could we:

1. reject all 1000 separators in numbers with up to 5 digits. I think that would be equally inconvenient all numbering systems.
2. reject all 1000 separators for up to 5 digits to the left of the decimal separator
3. reject all 1000 separators for up to 5 digits to the right of the decimal separator
4. provide a global setting for the separators which could be configured by the translators for each wiki

Would that resolve most of the issues raised in this thread? Lightmouse (talk) 11:46, 26 September 2011 (UTC)

Sorry for the multiple consecutive posts. The threshold of five digits is an inconvenience the forbids one 1000 separator. If the threshold is three, then that inconvenience disappears. If we have a global switch for template translators to define the meaning of comma and period (which I now accept may be required), then this issue becomes easier. We only need to look for invalid locations of the period and comma. Lightmouse (talk) 12:29, 26 September 2011 (UTC)

Which varient of English should we be using? Australian, of course ... no, it depends, it's best to follow WP:ENGVAR but WP:ENGVAR says nothing specific about this issue. MOSNUM, however, does. MOSNUM recomends grouping digits by threes (or fives in certain maths contexts). MOSNUM allows commas to the left of the decimal separator or gaps both sides (the style recommended by the SI). MOSNUM allows only a dot as the decimal separator. This is the norm in almost all varieties of English. The Indian style or the continental European style is bound to confuse the majority of English speakers. We must keep in mind that we're writing for an international audience. I'm all for encouraging the use of different varieties of English but we should avoid confusion. This template may have been copied into a dozen or so other languages but it would have to have been adjusted to accomodate them. Let {{decomma}} be adjusted similarly. JIMp _talk·cont 00:34, 27 September 2011 (UTC)

OK. I think you've persuaded me. I only ask that we try to keep regional settings to the minimum and in a way that makes them easy to change at point of copy/translate. I'll leave the decision to you guys. Thanks. Lightmouse (talk) 09:40, 27 September 2011 (UTC)

• I have noticed several uses of 2-digit comma style ("10,00,000") but not in conversions, so I think editors working on articles about India would not be affected much. However, I guess we should count the frequency in a sample of such cases. Meanwhile rejecting "1,35" as invalid should not be delayed, because such numbers are incorrect by a factor of 100x. -Wikid77 (talk) 12:55, 7 October 2011 (UTC)

Experimenting with Template:Decomma

I have created a simple Template:Decomma to show the rejection of improper commas:

• {{Decomma|1,600}} → 1600
• {{Decomma|1,60}} → 160
• {{Decomma|16,0}} → 160

However, when considering how other users often change templates (without prior discussion with even the people who recently edited those templates), then I think it is too dangerous for Convert to use common utility templates, and instead we should create a {Convert/decomma} which is specifically optimized for Convert and not an easy target for non-discussed "improvements". Because working on WP involves a zillion details, many people do not have time to "gain consensus" for changes, so they just change templates with no prior discussion and no post discussion to explain what all has been changed. That seems to be human nature in busy situations, so {Convert/decomma} should be controlled to avoid unneeded changes. Hence, Template:Decomma can be used to try various comma-validation tests, but do not be surprised when it is radically changed by other users, some day when having the least time for unexpected problems. The main concern, now, is to try using some specific markup to reject improper commas. -Wikid77 (talk) 12:16, 27 September 2011 (UTC)

Use of "|to|" or "|and|" in {convert|x|LT|t...}

Here are examples of conversions that give me headaches:
950 to 1,000 long tons (965 to 1,016 tonnes)
950 and 1,000 long tons (965 and 1,016 tonnes)

Using "to" or "and" in most other units I've needed it in so far, works just fine. Examples:
950 to 1,000 miles (1,529 to 1,609 kilometres)
950 and 1,000 miles (1,529 and 1,609 kilometres)
950 to 1,000 pounds (431 to 454 kilograms)
950 and 1,000 pounds (431 and 454 kilograms)

Please help! André Kritzinger (talk) 21:39, 26 September 2011 (UTC)

fixed by creating a redirect here. Frietjes (talk) 22:33, 26 September 2011 (UTC)

Perfect, thank you! André Kritzinger (talk) 23:40, 26 September 2011 (UTC)

acre foot

In the template, I see people use 'ft', 'foot', 'feet'. People using hyphens, dots, and spaces between 'acre' and 'foot'. Yet, I see two templates:

• Template:Convert/acre.ft
• Template:Convert/acre.foot

Do two templates cover all the permutations? If so, why can't it be just one? Lightmouse (talk) 12:41, 28 September 2011 (UTC)

Are we talking output or input?

• If you mean what the template spits out, I don't believe we should be trying to cover all possible permutations. We should settle on what is to be used. The acre-foot is like the newton-metre and kilowatt-hour: hyphens when spelt out and dots when abbreviated ... but there is no abbreviation for the acre (and it wouldn't do to half abbreviate) so "acre-foot" (in some varieties of English, as far as I know, "foot" pluralises to "foot") and "acre-feet".
• If you mean the template code, I notice acre-feet & the three versions with spaces all redirecting to the dot versions & all hardly used. We could dispose of them.

JIMp _talk·cont 04:51, 29 September 2011 (UTC)

I was talking about the template code. We can't conclude the current permutations are evidence of what editors do. I did a bot run to eliminate all permutations apart from 'acre.ft' and 'acre.foot'. Furthermore, I've added a lot of acre feet templates over the years, so a lot of what was there may be permutations I chose. Other instances may be due to people copying formats I've used within the same page or others. I've not been consistent so it doesn't surprise me that others aren't.

I asked the question because the number of input permutations exceeds the number of templates, I'm merely curious about whether having two templates is efficient. If we can reduce complexity in the code without reducing flexibility for editors, that would be ideal.

You raise a new point that acre foot is similar to newton metre and kilowatt hour. I just looked and found article titles are inconsistent. See:

• Acre-foot
• Newton metre
• Kilowatt hour
• Foot-pound (unit of force)
• Foot-candle

I note that editors use several template input permutations for those units too. The BIPM says "Multiplication must be indicated by a space or a half-high (centred) dot (·)"]. I note the SI unit titles are compliant with that. I'm not sure what to conclude. Lightmouse (talk) 09:16, 29 September 2011 (UTC)

A bug or a feature

Is the following a bug or some feature I don't understand?

{{Convert|-18|C}}→−18 °C (0 °F)

Thanks.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); September 28, 2011; 15:58 (UTC)

Google converter says -18 degrees Celsius is -0.4 degrees Fahrenheit. It looks like the template is using integer precision. What do you think it should say? Lightmouse (talk) 16:02, 28 September 2011 (UTC)

I think it should say "0 °F", not "−0 °F". Normal people might have a problem with the latter :)—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); September 28, 2011; 16:10 (UTC)

Ah yes. I agree. Lightmouse (talk) 16:33, 28 September 2011 (UTC)

The problem is that the decision of whether or not the result is positive or negative is made using the unrounded number, in template:convert/LoffT. If the unrounded result is negative, this template calls template:convert/roundT1, but that template has no check to see what happens after rounding. So, one could either put in an additional check for zero after rounding in template:convert/roundT1, or one could put in an additional check for zero in template:convert/LoffT. In both cases, it looks like you are going to be increasing the complexity of the template. It might work to just nudge the value up by 0.5 where it is used in the check before branching to either template:convert/roundT0 or template:convert/roundT1, since {{rnd}} can technically handle negative numbers, but there must be a reason why we needed to branch to these two different templates? Frietjes (talk) 19:26, 28 September 2011 (UTC)

Yes, it's a bug all right. JIMp _talk·cont 04:36, 29 September 2011 (UTC)

• Some scientists think "-0" is a feature: Because the calculation is rounding a negative number, to zero, then "-0" has been interpreted by some scientists, for many years, to indicate a rounding towards zero from a negative number. Hence, it is somewhat of a feature (rather than just always a bug). Instead, a real bug is when "1,35" in a German-based article is treated as being "135" such as:

• {{convert|1,35|m|ft}} → 135 metres (443 ft)
• {{convert|1.35|m|ft}} → 1.35 metres (4.4 ft)

Because the result of converting "1,35" is off by a factor of 100, then it is a very real bug; however, we do not know how many times such numbers are being used in WP articles. That is why a {Convert/decomma} could categorize articles with numbers < 1,000 which have commas, as an estimate of how many articles have that bug. Hopefully, we could quickly edit to fix each of those articles. -Wikid77 (talk) 13:26, 29 September 2011 (UTC)

• At the risk of sounding anti-elitist, Wikipedia is written for general populace, not for some scientists. Most regular people would have a real problem with seeing a negative zero—to the point of discarding the whole section which uses it as "bug-ridden"! If it could be fixed, I think it would only be an improvement. After all, in an article about some town does anyone really care that a temperature in a climate box has been rounded to zero from a negative number? This is an encyclopedia, after all, not a scientific paper.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); October 10, 2011; 13:51 (UTC)

US fluid ounce: default should be ml only

The current default for US fluid ounce is:

• 1 US fluid ounce (30 ml)

I added the default template to "12 ounce beers" and received the following complaint:

• "Changing 119 12-ounce beers in 6 hours to 119 12-US-fluid-ounce (350 ml; 12 imp fl oz) beers in 6 hours is not my idea of a sane conversion"

I agree. The ml value is sufficient, even in the UK. UK and US fluid ounce values are very close. They're identical in many instances, such as this. The reasoning is similar to that used for the change we've just made to US pints. We can increase support for 'sane conversion' and eliminate an anomalous double output by changing this. Lightmouse (talk) 08:24, 3 October 2011 (UTC)

• The phrase "12-ounce" is part of the cultural language (as in "12 ounce curls"), and with beer being a liquid, I do not see the need to specify "12-US-fluid-ounce". So, the phrase "12-ounce beer" should be kept in that context. Similarly, the phrase "40-ounce malt liquor" should be kept, or "5-gallon gas can" likewise. Otherwise, there is a sense of excess precision, such as calling a "2-liter bottle" to be a "2.0-litre bottle" or "1.90–2.10-litre bottle" or whatever the precision of contents of such bottles. In cases of ambiguity, then prefix with "US" such as a "US 5-gallon gas can" or such. These cases are probably so rare that hand-coding of conversions would be fine. -Wikid77 (talk) 23:48, 3 October 2011 (UTC)

I have no real objection to defaulting to millilitres only. Pints were changed, it would make sense for fliud ounces to follow suit.

As for the example, as I mentioned last time I ran across this conversion, the real insanity here is converting the bottle size when what we're really interested in is the amount of beer drunk. The conversion really should have been something like "119 twelve-US-fluid-ounce bottles of beer (42 L) in 6 hours". We could include gallon conversions too to make it clearer to those of us who think in gallons: "119 twelve-US-fluid-ounce bottles of beer (42 L, 11 US gal or 9 imp gal) in 6 hours".

I do, though, see Wikid's point that it's undesirable to disturb the flow by adding the clarifiers "US" and/or "fluid". Context can make these unecessary, here, for example, we're talking about beer so it must be fluid ounces. If need be we could put the US in brackets ("119 twelve-ounce (US) bottles of beer (42 L) in 6 hours") or in a footnote. JIMp _talk·cont 01:56, 4 October 2011 (UTC)

OK the example is a bit of a distraction. What's the next step in making the change to ml output only? Lightmouse (talk) 17:51, 4 October 2011 (UTC)

The next step is done. JIMp _talk·cont 02:01, 6 October 2011 (UTC)

Thanks. Lightmouse (talk) 09:27, 6 October 2011 (UTC)

Degrees (angle/temperature)

{{convert|100|F|C}} generates "100 °F (38 °C)". As WP:MOS#Units of measurement (4th bullet from the end) states: "Units of degrees, minutes and seconds for angles and coordinates, and the percent sign, are unspaced.", please could it be changed to generate "100°F (38°C)"? --Stfg (talk) 17:58, 5 October 2011 (UTC)

This guideline applies to degrees of angle not temperature. Read it again "Units of degrees, minutes and seconds for angles and coordinates," (emphasis WP:MOS's but do note it well). For further detail see WP:MOSNUM#Unit symbols.

• Values and unit symbols are separated by a non-breaking space. The {{nowrap}} template or the &nbsp; character can be used for this purpose. For example, use 10 m or 29 kg, not 10m or 29kg.
  • Exceptions: Non-alphabetic symbols for degrees, minutes and seconds for angles and coordinates and the percent sign are unspaced (for example, 5° 24′ 21.12″ N for coordinates, 90° for an angle, 47% for a percentage, but 18 °C for a temperature). See also Manual of Style—Geographical Coordinates.

Note the "but 18 °C for a temperature". Thank you nonetheless for your concern. JIMp _talk·cont 01:59, 6 October 2011 (UTC)

Thanks for taking the time, and apologies for my oversight. --Stfg (talk) 08:33, 6 October 2011 (UTC)

No worries. Perhaps we've uncovered a lack of clarity in the guidance. I wonder whether we should bring it up at WT:MOS. JIMp _talk·cont 23:14, 6 October 2011 (UTC)

US pint and quart: default should be single output

Current defaults are:

• 1 US dry pint (550 ml)
• 1 US quart (950 ml)
• 1 US dry quart (1,100 ml)

Please can we make those single output to match the others? Lightmouse (talk) 09:38, 6 October 2011 (UTC)

What's good for the goose is good for the gander ... how about these ducks though ...

• 1 imperial fluid ounce (28 ml; 0.96 US fl oz)
• 1 imperial quart (1,100 ml; 38 US fl oz)
• 1 imperial pint (0.57 L)
• 1 imperial gallon (4.5 L; 1.2 US gal)

... or even these swans?

• 1 millilitre (0.035 imp fl oz; 0.034 US fl oz)
• 1 litre (0.22 imp gal; 0.26 US gal)
• 1 kilolitre (35 cu ft)

JIMp _talk·cont 23:19, 6 October 2011 (UTC)

Fair points. But (to change the metaphor) my last attempt at listing all dead trees in the wood ended up with no dead trees being removed. Can we cut the three dead trees on the edge of the wood first? Thus USdrypt, USqt, and USdryqt. Lightmouse (talk) 16:58, 8 October 2011 (UTC)

Dynamic conversion

Copied from by talk page: begin
I question the benefit of using {{convert}} to do dynamic conversion of (e.g.) km to miles (as you have done in various articles), especially where the equvialent has already been provided. Such conversions need to be done only once, not every time an article is generated. And if an editor feels a "round" number is appropriate then you should not be unilaterally replacing it without prior discussion. – J. Johnson (JJ) (talk) 22:38, 4 October 2011 (UTC)

Thanks for contacting me. I welcome feedback. Just on the technical side of things, can you clarify what you mean by:

• "conversions need to be done only once, not every time an article is generated"

? Lightmouse (talk) 22:43, 4 October 2011 (UTC)

...the dynamic conversion is where the conversion is calculated everytime the article text is rendered for someone. As opposed to an editor -- or even a bot -- calculating the conversion once and inserting it into the article text. Dynamic calculations are useful where something is frequently changing, but although it is suspected that the kilogram bar is gaining weight it is not at a rate we need to be concerned about. _ J. Johnson (JJ) (talk) 21:29, 7 October 2011 (UTC) Copied from by talk page: end

It's an important question that deserves an answer. I know benefits but not cost. So I can't do a cost-benefit analysis. Please can somebody answer user:johnson? Lightmouse (talk) 15:51, 8 October 2011 (UTC)

IIRC, it's not exactly a dynamic conversion; internally, it's only redone when {{convert}} (or a subtemplate) is edited, and when the article is edited or purged. There are internal storage costs, but I think we've been directed by the developers not to consider those, unless we're hitting the maximum template expansion count in the article. In some cases, it's been strongly suggested that we substitute citation templates, because of that problem. — Arthur Rubin (talk) 16:11, 8 October 2011 (UTC)

I'll let Lightmouse talk about the benefits in more detail Although I believe his bots and semi-automated edits sometimes make serious mistakes, if the {{convert}} template is properly in place, it's much easier to maintain if the numbers do change or are corrected; and it shortens the editable article text. — Arthur Rubin (talk) 16:15, 8 October 2011 (UTC)

And how often do we expect the km/mile conversion to change? _ J. Johnson (JJ) (talk) 19:55, 8 October 2011 (UTC)

And how often do we expect someone to edit "1.5 km (0.9 mi)" and change "1.5" to "1.6", without changing the "0.9" to "1.0"? — Arthur Rubin (talk) 00:27, 9 October 2011 (UTC)

I prefer the use of 'convert' over manual conversions because I can trust it. If I see an instance of 'convert' then I know that I don't have to check its arithemetic (except perhaps to explicitly make the rounding factor to a certain number of digits). Whereas manual conversions often have mistakes. Also, many articles have mixes of miles first of km first. By adding 'disp=flip' to some of them I can make them consistent while keeping the input value true to the source reference.

• Convert km/miles is actually lightning fast: I am a computer scientist and have developed or used text-formatting systems for decades. I cannot emphasize enough how quickly the conversion of km/miles actually runs these days (even though it can seem overly complex). I think speed analysis will show how using Convert is over 1000x (one thousand times) faster than formatting references by {{Cite web}} or {{Cite book}}, but those cite templates are widely used. Also, I have no objection to hand-coding some conversions, such as "80&nbsp;kilometers (50&nbsp;mi)" especially near the top of an article, but we really have seen several people change one amount and not hand-convert the equivalent unit. Of course, we try not to gunnysack the mistakes made by users, so we just remember that general users might change a speed limit of 50 to "70 mph" leaving "80&nbsp;km/h" rather than 70 miles per hour (110 km/h). As for rounding of amounts, we have discussed the rounding for years, and searching into articles will confirm that most people put whole hundreds when they mean "approximately 200" or "nearly 400" and it is rare when an amount is exactly 300, so feel free to put "300.0" (or round "300|0") to force the precision in those rare cases. Anyway, most of us share the same concerns, so rest assured that we also worry to avoid similar problems in writing and rendering of article pages. Meanwhile, over 80% of articles do not show any conversions, which can be viewed as "very wrong" for users who do understand amounts in only kilometres or miles. Every time you edit an article to update facts or fix grammar, look to also convert amounts that others might not understand. -Wikid77 (talk) 23:04, 9 October 2011 (UTC)

I think you missed my point. If a process takes any time to do (distinct from having negative speed, where it would take less time than not doing it all), it usually takes more time to repeat the operation than do it once and store the result.

Arthur says it is easier from the editor's point of view to use {{convert}}. Which is largely true, but why does it have to be embedded in the article? How about a converter tool available in the editor? Or at elast a link to such a tool? Or if you want to get real fancy, a function where you can highlight a conversion, click on a "check" (verify) button, and then (at the editor's discretion) a "replace" button? I can think of several alternatives, all of which are more efficient in speed, storage, and editor convenience than converting repeatedly. _ J. Johnson (JJ) (talk) 19:35, 10 October 2011 (UTC)

You can check with the developers, but I believe the result is stored; only reset when this template or a used subtemplate is edited. Hence there's only a small marginal cost, as opposed to the effort required to maintain two or more units. — Arthur Rubin (talk) 20:09, 10 October 2011 (UTC)

Taking any time is a bad metric. The real question is whether it takes significant time - ie does it adversely affect the reader or the server. Wikid77 has already said that it takes negligible time, so removing the use of convert for efficiency reasons is a gain that nobody will even notice.

As for your suggestion to embed the final result (ie not dynamic), this is indistinguishable from a manual conversion by an editor. If I see a manual conversion I can not automatically assume that it is correct because editors often make mistakes. As mentioned above, some editors will change the first figure but not change the second. Or they make a mistake in the conversion formula. Or they simple make a typo. Whereas 'convert' can be trusted because once the formula is worked out correctly it will continue to work correctly. And editors only have to change a single number, leaving 'convert' to correctly adjust the remaining number(s).

Also, source references are sometimes in one unit (eg km) and sometimes in the other unit (eg miles). If we find and error like '50 miles (90 km)' in the article then we don't know if the source was 50 miles or 90 km unless we go through the tedious process of following the source. By using 'convert', we only need the single value from the source and then we choose which unit is displayed first by insert '|disp=flip' or not. This is also handy when it is decided to swap the order, instead of doing tedious and error prone manual swapping of the unit order.

In short, 'convert' has no significant impact on timing and has a lot of advantages.  Stepho  talk  03:15, 11 October 2011 (UTC)

• Years of discussions have supported Convert: I was a computer-lab tutor as an undergrad, and you would be surprised the number of college sophomores who cannot use a computer to solve a partial differential equation within 3 minutes (just kidding). Bear in mind how the case of converting km/miles is just one example, among hundreds of different conversions. We had a highly intelligent developer who thought that Convert could be replaced by a built-in internal parser function to spit out "161" as kilometers for 100 miles (or hundreds of other units), until he realized that complex formatting of the results was also wanted by editors, such as numbers spelled out as words:

• {{convert/spell|161|km|mi}} → Template:Convert/spell

Then, there are people who want to convert huge numbers of kilometres into astronomical units, not just miles, and so the variations become almost unlimited, but Convert handles some very extreme cases, such as gaps instead of commas:

• {{convert |651,000,000|km|AU}}       → 651,000,000 kilometres (4.35 AU)
• {{convert/spell|651,000,000|km|AU}} → Template:Convert/spell
• {{convert/gaps |651,000,000|km|AU}} → Template:Convert/gaps
• {{convert/spell |7.35|km|in}} → Template:Convert/spell

Consequently, over the years, when hundreds of issues have been considered, we have recommended to continue using Convert, and avoid any attempts to create built-in functions, or converter tools, which typically focus on only a tiny subset of the issues which have been raised over the past several years. For experimenting with converter tools, then users could try using Google Search conversions, such as "51 km in mi" to give "51 kilometers = 31.6899308 mi" but then much discussion can occur when people want to type precisely "31.6899308 miles" as the result in an article. Hence, considering all the viewpoints, over the years, the decision has been to continue using Convert, for overall convenience. -Wikid77 (talk) 05:47, 11 October 2011 (UTC)

Density

I notice there is a section on population denisty but I couldn't see if the convert template worked for the density of materials

I saw triton (on the main page) and it has this chunk density (2.061 g/cm³), which I tried to convert to {{convert|2.061|g/cm3|lb/in3)}

I'm not sure I applied the template correctly but if not can you explain how to get that in the documentation, and if I did get it correct then it appears not to be supported. I'll watchlist this page for a while Cheers EdwardLane (talk) 21:34, 8 October 2011 (UTC)

Is "{{convert|2.061|g/cm3|lb/in3)}" what you actually typed or was using a round bracket instead of a curly one. Otherwise it's fine & would give you "2.061 grams per cubic centimetre (0.0745 lb/cu in)". JIMp _talk·cont 23:07, 8 October 2011 (UTC)

Dare I say 'doh' - thanks Jimp, the preview of tha page didn't flag up the erroneus bracket EdwardLane (talk) 15:32, 9 October 2011 (UTC)

Gill, US quart, US pint, US peck

Lower case 'us' in template:

• 1 gill (120 ml; 4.2 imp fl oz)
• 1 US pint (0.47 L; 0.83 imp pt)
• 1 US dry pint (550 ml)
• 1 US quart (950 ml)
• 1 US dry quart (1,100 ml)
• 1 US peck (8.8 L; 1.9 imp gal)

Upper case 'US' in template:

• 1 gill (120 ml; 4.2 imp fl oz)
• 1 US pint (0.47 L; 0.83 imp pt)
• 1 US dry pint (550 ml)
• 1 US quart (950 ml)
• 1 US dry quart (1,100 ml)
• 1 US peck (8.8 L; 1.9 imp gal)

Dotted upper case 'U.S.' in template:

• 1 gill (120 ml; 4.2 imp fl oz)
• 1 U.S. pint (0.47 L; 0.83 imp pt)
• 1 U.S. dry pint (550 ml)
• 1 U.S. quart (0.95 L; 0.83 imp qt)
• 1 U.S. dry quart (1,100 ml)
• 1 U.S. peck (8.8 L; 1.9 imp gal)

Full spelling in template:

• 1 US quart (950 ml; 33 imp fl oz)
• 1 US dry quart (1,100 ml)

Wouldn't it be more efficient to use redirects rather than one template for each code option? Anyway, please can they all be set to single default output. Lightmouse (talk) 15:00, 10 October 2011 (UTC)

• Those are 3 different styles of display, where unit-codes (such as "usqt") with the lower-case "us" will allow changing the spelling by "sp=us":

• {{convert|1|usqt|sp=us}} → 1 U.S. quart (950 ml)

• {{convert|1|usqt|sp=en}} → 1 US quart (950 ml)

• {{convert|1|USqt|sp=us}} → 1 U.S. quart (950 ml)

• {{convert|1|U.S.qt|sp=en}} → 1 U.S. quart (0.95 L; 0.83 imp qt)

Note how the uppercase unit-codes (with "US" or "U.S.") always force the spelling to match the unit-code and ignore "sp=xx". For that reason, the 3 styles ("us" or "US" or "U.S.") were developed as fully separate templates which do not use redirection. However, all of the upper-case "US" unit-codes could be redirected to the lower-case "us" unit-codes, because the default results use the same capital letters, in showing "1 US". On the other hand, the lower-case "us" unit-codes could be kept separate to list 2 default outputs for each amount. As always, this is part of the 20,000 issues to consider in modifying Convert, and we should prioritize which among the 20,000 issues to change first. -Wikid77 (talk) 09:01, 11 October 2011 (UTC)

Aha. Thanks for explaining the 'force spelling' issue. Where you say:

• "all of the upper-case "US" unit-codes could be redirected to the lower-case "us" unit-codes

that seems like a good idea. I know you guys are spinning lots of plates and I appreciate it. I hope Jimp will be along shortly to comment on this section too. Lightmouse (talk) 11:10, 11 October 2011 (UTC)