Template talk:Convert/Archive July 2008

Range of values

Is there a trick or equivalent template for presenting ranges of values, as in 2-20 mm? --EncycloPetey (talk) 23:18, 25 June 2008 (UTC)

Yes,

• {{convert|2|-|20|mm}} will give "2–20 millimetres (0.079–0.787 in)"
• {{convert|2|to(-)|20|mm}} will give "2 to 20 millimetres (0.079–0.787 in)"
• {{convert|2|to|20|mm}} will give "2 to 20 millimetres (0.079 to 0.787 in)"
• {{convert|2|x|20|mm}} will give "2 by 20 millimetres (0.079 in × 0.787 in)"
• {{convert|2|+/-|20|mm}} will give "2 ± 20 millimetres (0.079 ± 0.787 in)"
• {{convert|2|and|20|mm}} will give "2 and 20 millimetres (0.079 and 0.787 in)"

... but it's still under construction so won't work for all units. JIMp _talk·cont 23:58, 25 June 2008 (UTC)

Thank you. I have started using it. The second one contains 'inches' within parentheses, is that a bug? Lightmouse (talk) 22:38, 29 June 2008 (UTC)

Yep, that would be a bug. Well spotted ... JIMp _talk·cont 23:20, 29 June 2008 (UTC)

fixed JIMp _talk·cont 08:05, 3 July 2008 (UTC)

Thank you. You are a star. Lightmouse (talk) 08:39, 3 July 2008 (UTC)

Numeric format.

{{editprotected}} Under some circumstances this template is returning values in "e" notation. e.g. "{{convert|1|mg|oz|lk=on}}" yields "{{convert/mg|1|{{#ifeq:{{#expr:oz*0}}|0|0}}|oz||||r={{#ifeq:{{{sp}}}|us|er|re}}|d=LonAoffDbSoff|s=}}". This is not an acceptable numeric notation in print. It should be "1 milligram (3.5 × 10^-5  oz)". The problem seems to be coming from this template's use of {{Rnd}} (via transcluded subtemplates). Either Rnd needs to be fixed to use scientific notation, or this template should be fixed not to use it.--Srleffler (talk) 03:51, 4 July 2008 (UTC)

There's no edit that can be done on this protected page to fix the problem. {{Rnd}} was designed to aviod such errors but if it's broken something must be done. JIMp _talk·cont 04:39, 4 July 2008 (UTC)

I've found a solution. I'm just waiting for unprotection of {{rnd}} & {{rnd/+}}. JIMp _talk·cont 06:05, 4 July 2008 (UTC) ... and waiting ... JIMp _talk·cont 06:41, 4 July 2008 (UTC)

Okay, thanks to Huntster's help, it's fixed as you can see. JIMp _talk·cont 08:11, 4 July 2008 (UTC)

Reference

There's no way to add a reference after the first number, is there? --NE2 09:39, 30 June 2008 (UTC)

No, you can't add refs with templates. JIMp _talk·cont 15:31, 30 June 2008 (UTC)

I'm talking about something like 5 mi (8 km), where the actual reference is a parameter of the template. --NE2 08:41, 4 July 2008 (UTC)

Yeah, I thought that's what you were after. I'd tried it once some time ago (on Wiktionary but same thing). It didn't work then. I've just given it another try in the sandbox. It failed again. JIMp _talk·cont 09:00, 4 July 2008 (UTC)

It works on template:mikm; see for intstance SR 99 on List of state highways in Washington. --NE2 09:10, 4 July 2008 (UTC)

I see, the parameter is set to <ref>cite</ref> not just cite. That'll work ... well you can see it in action. Okay it's on the to-do list but it'll take a while since this involves hundreds of subtemplates ... one of the draw backs with this design. JIMp _talk·cont 00:02, 7 July 2008 (UTC)

Template code: kn versus knot

Some editors are converting kn to knot within the template code. See other edits around the same time. Lightmouse (talk) 21:55, 6 July 2008 (UTC)

They are probably having the same reaction I had when the bot run changed the code from "knot" to the less-intuitive "kn". Since "knot" is not "kt" (which had a definitive reason to be changed), and "knot" works, and is non-ambiguous, why is this even worth mentioning on this talk page? — Bellhalla (talk) 01:59, 7 July 2008 (UTC)

Temperature increase

How can I use {{Convert}} to display temperature increases, not absolute temperatures, like … temperature increased 0.74 °C (1.33 °F)? If I use {{Convert|0.74|°C|°F|abbr=on}} it produces 0.74 °C (33.33 °F). ––Bender235 (talk) 12:25, 7 July 2008 (UTC)

Use C-change or F-change. {{convert|0.74|C-change|2}} gives "0.74 °C (1.33 °F)". JIMp _talk·cont 15:15, 7 July 2008 (UTC)

Help

In the article Walden Galleria, I've used some convert templates. I've tried messing around with the code, but the square meters are still showing up as "1.486449×10⁵" instead of a nice round number. How do I get this to show up in something else than scientific notation? Ten Pound Hammer and his otters • ^{(Broken clamshells•Otter chirps)} 15:36, 4 July 2008 (UTC)

I'll have a look. JIMp _talk·cont 15:59, 4 July 2008 (UTC)

I changed the rounding from a precision of one (i.e. the nearest tenth of a square metre) to two significant figures. The scientific notation is a product of the recent update of {{rnd}}. That template was edited to get rid of E notation. The E notation was replaced with scientific notation. The range for which {{#expr:}} is sure not to give E notation seems to be 10⁵ > x > 10⁻⁴. {{Rnd}} was thus made to have scientific notation kick in outside this range. It should get rid of some of those unsightly strings of zeros you sometimes see. JIMp _talk·cont 16:29, 4 July 2008 (UTC)

I find myself comfortable with 150,000 as well as 1.5 × 10^-5 m². I am quite prepared to accept that the format shown in that article is the one we have to use but is the '150,000' format something we should discuss? Lightmouse (talk) 16:40, 4 July 2008 (UTC)

We probably should. JIMp _talk·cont 16:46, 4 July 2008 (UTC)

I must say, I have a feeling this will generate significant resistance. Not very many people will understand what scientific notation is, much less how to interpret it. — Huntster (t • @ • c) 22:57, 4 July 2008 (UTC)

This is true but the balance must be struck somewhere, 100,000 may be too low but we surely don't want great strungsstrings of zeros. JIMp _talk·cont 21:47, 5 July 2008 (UTC)

I agree with the principle. Lightmouse (talk) 10:04, 6 July 2008 (UTC)

With the current {{rnd}}, we get

• {{convert|1|ly|km}} → "1 light-year (9.5×10¹² km)"

Surely this is better than

• {{convert|1|ly|km}} → "1 light-year (9,500,000,000,000 km)"

How about "1 astronomical unit (1.5×10⁸ km)" vs "1 astronomical unit (150,000,000 km)" for {{convert|1|AU|km}} or "1 tonne (1.0×10⁶ g)" vs "1 tonne (1,000,000 km)" for {{convert|1|t|g}}? Of course "1 hectare (10,000 m)" would usually be better than "1 hectare (1.0×10⁴ m²)" vs for {{convert|1|ha|m2}}. Where shall we have the scientific notation kick in? JIMp _talk·cont 17:38, 6 July 2008 (UTC)

Well, I'm not going to ask for additional complexity to be coded into the template, though I do wish there was a way to expressly not use scientific notation...I personally can't stand it, and have no problem with a line of zeroes (to me, comma groupings are much easier to interpret). Either way, it is a minor issue, so I'm not going to be vocal. — Huntster (t • @ • c) 18:01, 6 July 2008 (UTC)

Beauty is in the eye of the beholder, isn't it? As for me, what I can't stand are great strings of zeros. A maximim of four seem just about right to me ... anything above nine would get my eyes rolling. Last Friday's choice of one hundred thousand as the cut-off point was more of a technical decision than an æsthetic one. I'd originally had one million in mind ... still to low? We could bump it up further, it'll mean more complexity in the {{rnd}} code but it may be worth it if this dislike for scientific notation is wide-spread. Make it optional ... now were're talking complexity. Of course, were it optional then we could conform to the editor's taste ... but it's the reader we're altimately trying to satisfy ... isn' it? I'm writing as if scientific notation will be inevitable at some point ... of course, nothing's inevitable (except taxes, death and trouble) but the higher we go avoiding scientific notation the more complex {{rnd}} will have to be ... but eventually we'll want scientific notation, the balance must tip somewhere. To take an extreme example, isn't "1 teratonne of TNT (2.6×10⁵⁵ feV)" better than the version with 4½ dozen zeros? JIMp _talk·cont 00:30, 7 July 2008 (UTC)

Jimp, you summed it up correctly: we are working for the benefit of readers. Deep within the process of selecting each day's featured article is a criterion that discusses a typical reader being a 12-year-old working on a school project. Personally, I'm not so sure a typical 12-year-old would understand scientific notation at all. Perhaps there could be a scientific parameter ("sci=yes") added so that scientific notation can be invoked at a lower threshold. A typical 12-year-old would understand (if not necessarily fully comprehend the scale) of a statement saying, for example, the "sun is 93,000,000 miles away" much better than "the sun is 9.3 × 10⁷ miles away". Your example of "1 teratonne of TNT (2.6×10⁵⁵ feV)" would be a perfect case for the use of a scietific parameter. — Bellhalla (talk) 02:10, 7 July 2008 (UTC)

I mentioned this because an article I'm trying to get to WP:FAC now has inappropriate, in my opinion, use of scientific notation. In the last paragraph of SS Kroonland is a cited statement that claimed the ship had sailed "1,635,468 nautical miles" which is now rendering as "1,635,468 nautical miles (3.028887×10⁶ km)". Note that there were never any "great strings of zeros" before the change. — Bellhalla (talk) 02:17, 7 July 2008 (UTC)

Is there any way that the A.bbX10^n or A.bbExx notations could be wikilinked to an explanation of exponential notation and/or a conversion to the equivalent zero-ful figure? The example of the sun at 93,000,000 or 93 million miles away is particularly compelling here, at the same time there are many other places where the long notation would be unhelpful. Tooltips of course can't be used, because of accessibility concerns, but is there any other way of providing an explanatory link?

Also, e/c'd with Belhalla's latest - 1,635,468 naut mi is an impossibly precise figure anyway for the distance a ship has sailed (did it ever get blown sideways and have to sail back?), and any precise conversion of that distance is subject to the same uncertainty, however, point taken about the strangeness of using exponent notation for the kilometres. Franamax (talk) 02:28, 7 July 2008 (UTC)

I thought the figure impossibly precise myself, which is why I listed it in the article as a claim. — Bellhalla (talk) 02:41, 7 July 2008 (UTC)

Yes, a parameter to turn on or turn off scientific notation would be optimal but I'm not sure it'd be worth the inrease in template-limiting factors to say nothing of the huge amount of editing it'd take to get such a thing working. Such large numbers are not all that common, right? How about we just bump the limit up to say a thousand million? JIMp _talk·cont 03:39, 7 July 2008 (UTC)

If it is producing "(3.028887×10⁶ km)" then that is not as good as "(3,028,887 km)". I like the purity of the scientific notation solution but I am not sure if I can handle it in all the current cases. Lightmouse (talk) 23:40, 8 July 2008 (UTC)

It's good for the very large and very small ... what I'm asking is how large is large and how small is small ... or, more specifically, how's 1,000,000,000 > x ≥ 0.0001 grap ya? JIMp _talk·cont 01:32, 9 July 2008 (UTC)

That sounds like a reasonable range of values. — Bellhalla (talk) 01:40, 9 July 2008 (UTC)

Sounds much better. I appreciate all the hard work you put in with this template. Thanks. Lightmouse (talk) 22:29, 9 July 2008 (UTC)

Unexpected Expression error: Unrecognised word "span"

I have been adding {{convert}} to articles for some time now with no problems. However yesterday I added three {{convert|00.0|m|ftin|abbr}} statements to then infobox on British Rail Class 60 (Length, Width, Height), and this morning I have discovered that the first of the three now has an output error: 21.34 m ({{convert/AndExpression error: Unrecognised word "span"|Expression error: Unrecognised word "span"|ft|-7560×10−1|in }}) The second and third work without a problem.

I am at a complete loss to understand what has gone wrong - I have checked my typing - its the first call to {{convert}} in the infobox, both as written as as displayed. Can anyone tell me what has gone wrong? TIA Iain Bell (talk) 11:41, 4 July 2008 (UTC) 00.0 metres (0 in)

I see a similar error on the {{Rnd}} page. The third example of the template gives an error on that page, but the same wikicode works fine on the documentation page itself. Rnd is called by convert, and was modified yesterday (per my request above). Perhaps there is a subtle bug in the new code.--Srleffler (talk) 14:23, 4 July 2008 (UTC)

The glitch you see at {{rnd}} is nothing to worry about, it should go away when someone opens {{rnd}} & then hits [Save page] ... but that'd take an admin. The other problem is not so trivial ... well, actually there are two & one is somewhat trivial. Just putting abbr in without the =on (or =off) like that is going to confuse {{convert}} into thinking you want to round to abbr decimal places and that won't work since abbr is no number. The other problem is serious, it seems the template can't handle converting zero and ftin. I'll have a look at that. JIMp _talk·cont 15:59, 4 July 2008 (UTC)

Should we not push for a revert to the last working version and then make any changes from there. Looks like we do need to escalate this as a number of articles are being edited to avoid the message flagging up as the issue has been around for a good couple of days.Londo06 10:10, 6 July 2008 (UTC)

It should be working now, just put the =on after the abbr

{{convert|00.0|m|ftin|abbr=on}} → "00.0 m (0 in)"

JIMp _talk·cont 17:00, 6 July 2008 (UTC)

Still getting the error message appearing in a number of articles.Londo06 20:52, 6 July 2008 (UTC)

You wouldn't mind pointing them out, would you? JIMp _talk·cont 23:45, 6 July 2008 (UTC)

Well, British Rail Class 60 is still giving the error — 21.34 m (70 ft 0 in) — the abbr=on parameter was omitted in error from my original post, not the article. I also forgot to mention that {{convert}} is a very useful template, an I would like to thank those wikipedians who have helped in its creation and maintenance. Iain Bell (talk) 11:09, 7 July 2008 (UTC)

Anthony Tupou is an example of the message being flashed up on a number of articles.Londo06 11:50, 7 July 2008 (UTC)

How's it looking now? JIMp _talk·cont 15:19, 7 July 2008 (UTC)

That appears to have resolved the issue. Many thanks.Londo06 15:34, 7 July 2008 (UTC)

Is there another problem with this? I'm seeing an eror such as 183 cm (−-7,272.0472440945×10-2 in) displayed in both Anthony Tupou and Ryan O'Hara. •Florrie•leave a note• 14:05, 10 July 2008 (UTC)

What changed?

I've noticed that the distance conversion templates have changed into scientific notation of late. When and why did this happen? I want it to say 100,000 miles (161,000 km) not 100,000 miles (161,000 km). Roguegeek (talk) 23:16, 8 July 2008 (UTC)

{{Rnd}} was updated to eliminate E notation. The E notation was replaced with scientific notation. As it worked out there were instances where the old version of {{rnd}} did not give E notation but the new version does give scientific notation.

The update was more or less a band-aid solution which replaced the completely unacceptable with the less than completely desireable. Last night I found myself bussy cutting out another band-aid but I've decided to take a different approach altogether.

{{Rnd}} is up for a complete overhaul ... JIMp _talk·cont 23:47, 8 July 2008 (UTC)

So, uhh, this is something that's temporary? Something that will be fixed soon? There are a lot of articles out there that look very non-human readable now. How/when would this be resolved? Roguegeek (talk) 23:55, 8 July 2008 (UTC)

Soon, I'd like to say. Soon being within twenty-four hours. I think it'll be doable in such time unless I run into strife which is no as uncommon as I'd like it to be. What I've got in mind, as mentioned above, is raising the upper bound for regular (i.e. non-scientific) notation from the current 100,000 to 1,000,000,000. Conversions involving numbers over one thousand million are not going to be all that common and where they do occur, scientific notation will probably no be inappropriate. JIMp _talk·cont 01:29, 9 July 2008 (UTC)

{{Rnd}} has been updated. JIMp _talk·cont 08:29, 10 July 2008 (UTC)

Excellent. Thanks. roguegeek (talk·cont) 21:05, 10 July 2008 (UTC)

Meters -> feet & inches?

There is a way to convert feet and inches into meters (eg 5 feet 3 inches (1.60 m)) but is there a way to do it the other way? ie convert meters into feet and inches? Right I only know how to convert meters into feet (eg. 1.6 metres (5.2 ft)) or meters into inches (eg. 1.6 metres (63 in)), but not 1.6 meters (5 ft 3 in). Thanks, Renata (talk) 18:25, 10 July 2008 (UTC)

• {{m to ft in|1.6}}→1.6 m (5 ft 3 in).—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 18:36, 10 July 2008 (UTC)
  • you can do that in {{convert}} like this:
    • {{convert|7|m|ftin}} which gives this: 7 metres (23 ft 0 in)
    • and the other way as {{convert|32|ft|5|in|m}} which gives this: 32 feet 5 inches (9.88 m) — Bellhalla (talk) 19:08, 10 July 2008 (UTC)
  • Whoa! What's up with that result? The first conversion is displaying as "(−-278.230551181×10² in)" — Bellhalla (talk) 19:10, 10 July 2008 (UTC)

Sorry, I'd neglected to update {{convert/rand}} to account for the overhaul of {{rnd}}. It's fixed now ... I hope. JIMp _talk·cont 00:41, 11 July 2008 (UTC)

ftin and stlb broken?

Using {{convert}} from m→ftin (perhaps others, too?) is giving some strange results right now. Any clue as to what's happening? — Bellhalla (talk) 19:16, 10 July 2008 (UTC)

Template:Convert/stlb is not working either. It probably has something to do with some recent changes to the subtemplates of Rnd. —MJCdetroit ^(yak) 20:29, 10 July 2008 (UTC)

I think I've fixed it. JIMp _talk·cont 00:51, 11 July 2008 (UTC)

m→ ftin broken

Code such as {{convert|212.96|m|ftin}} is currently displaying 212.96 m (−-16,760.2519685×100 in). See GTS Finnjet infobox. —Sladen (talk) 20:58, 10 July 2008 (UTC)

Fixed, sorry about that. 212.96 m (698 ft 8 in) JIMp _talk·cont 00:43, 11 July 2008 (UTC)

Range conversions

Yeah, I added the docs for it, now you're getting questions. Too bad, light must not be hidden under barrels! (Nor under tuns or hectolitres :)

I'll repeat my offer to add a column to the unit tables to show whether the range function is implemented. I've looked at the structure and yes I do realize how big an undertaking that is. I'd end up producing an index for the entire Template/Convert/* space, if that would be any help.

And on the subject of docs, I notice now that my examples of the "by" and "x" functionality seem to produce identical results for metre->foot. Shouldn't they differ in the primary range? Franamax (talk) 01:19, 14 July 2008 (UTC)

The problem with adding that column would be that eventually the column should be removed: one day all units should be covered (though conversions from feet & inches, stone & pounds or pounds & ounces will probably never be since this range stuff is using the room opened up for them). Another problem would be that we'd have people picking through that long list trying to find the pattern. Why not just explain what the pattern is in the first place ... oh, yeah, that'd be my job?

Okay, in a nutshell:

• no (imperial or US) gallon-based units are covered,
• no fuel consumption units are covered;
• no units involving e3, e6, e9, etc. are covered;
• no temperature units are covered and,
• as mentioned above, conversions from feet & inches, stone & pounds or pounds & ounces may never be covered

I'm not saying not to add the column, I'm just pointing out why it might not be the best option.

As for by vs x ... the good thing about keeping your light under the barrel (let's make it a nice round two-hectolitre Somali water barrel) is that you can sort the colours out before shining it around. I hadn't really got past thinking of having x as short for by but perhaps it could be useful to have them do different things. JIMp _talk·cont 03:03, 14 July 2008 (UTC)

Yaahh, having a brilliant idea often gets you questions about why precisely your idea is just not brilliant enough - comes with the territory :)

From the info you've provided, I'll try to add an exception list to the docs, rather than an inclusion list. Way simpler and you can remove the exceptions if/when you slay them.

And I wonder if there's a way to list the incoming links by parameter content? Seems to me you've produced a useful function with rapid takeup - that's a good thing, right? It certainly helps the 'cyclo and it's not causing me many extra problems :) Franamax (talk) 03:24, 14 July 2008 (UTC)

ft -> m/cm broken

code such as {{convert|6|ft|cm}} currently produces 180 cm instead of 183 cm. As if a foot was 30 cm instead of 30.48 cm. Ditto for the conversion of feet to meters. --Disconnect 6 (talk) 17:27, 14 July 2008 (UTC)

That was intentional: conversions should retain a comparable precision. There are two possible solutions: {{convert|6|ft|cm|0}} or {{convert|6|ft|cm|sigfig=3}}. JIMp _talk·cont 17:40, 14 July 2008 (UTC)

Ok, I see. Thanks for answering. --Disconnect 6 (talk) 19:41, 14 July 2008 (UTC)

Error

Can someone fix the template which affects the rugby related articles and that means nearly a 100 articles are affected by this

• Joe Rokocoko
• Sitiveni Sivivatu
• Francois Pienaar
• Richie McCaw
• Chris Jack
• Ali Williams etc, please can you fix it soon, I believe something related to the weight temp is broken... ? ...--Cometstyles 00:21, 15 July 2008 (UTC)

Just a slight hiccup, all should be well now. JIMp _talk·cont 00:43, 15 July 2008 (UTC)

Rounding Error?

Noticed this on Cadel Evans:

Code: {{convert|64|kg|lb st|abbr=on|lk=on}}
Output: {{convert/kg|64|{{#ifeq:{{#expr:lb st*0}}|0|0}}|lb st||||r={{#ifeq:{{{sp}}}|us|er|re}}|d=LonAonDbSoff|s=}}

lb = 0.45359237 kg (see Pound (mass))
64 / 0.45359237 = 141.09584779832165166270323286082 lbs

No idea how to fix this in the template. Cheers - ARC Gritt^TALK 21:20, 14 July 2008 (UTC)

See the above answer: It's based on the number of significant figures provided in the number to be converted. — Bellhalla (talk) 21:59, 14 July 2008 (UTC)

Whatever way you look at it, 10.1 st cannot also be 140 lb, it's just a mismatch. The minimum it would have to be for it to be 10.1 st and not 10.0 st is 140.69999999, which rounds to 141 lb. - ARC Gritt^TALK 09:38, 15 July 2008 (UTC)

What is being converted from your example is 64 kg, not 140 lb. From my desktop widget, 64 kg translates into 10.07 stone, which with rounding becomes 10.1 st.

One way to avoid such a seeming mismatch is to convert only to one unit like {{convert|64|kg|lb}} or {{convert|64|kg|st}}, which would provide "64 kilograms (141 lb)" and "64 kilograms (10.1 st)", respectively. — Bellhalla (talk) 10:49, 15 July 2008 (UTC)

You could also convert to pounds and stone & pounds like this.

{{convert|64|kg|lb stlb}} → "64 kilograms (141 lb; 10 st 1 lb)"

You'd usually talk in terms of stone & pounds rather than decimal stone, right? JIMp _talk·cont 11:23, 15 July 2008 (UTC)

More for the wizard - reverse values

I have an article that is using mixed SI and Imperial (or whatever it's called nowadays) units. I want to unify the systems using {[tl|convert}}, lets say I'm making SI the primary throughout. Now, I have "50 mph" in the article and I want to show it as "80 km/h (50 mph)" - is there a way I can use 50 as the original_value and flag a reverse conversion? That would give me a really easy way to adapt the article without getting out my calculator and looking up the conversion. Cheers! Franamax (talk) 07:02, 3 July 2008 (UTC)

I believe what you are wanting is described here, so no, it is not currently possible. What article is it you are working on? Shouldn't be too hard to unify the system, excepting quoted figures and such. — Huntster (t • @ • c) 07:12, 3 July 2008 (UTC)

It will be possible one day. JIMp _talk·cont 07:38, 3 July 2008 (UTC)

Thanks. I have great faith. I was thinking it would be an easy reciprocal function with some divide-by-zero checking, on reflection it may just be a wee bit more complicated :) The article that spurred it is now clicked away, I think it was Nuclear weapon design. I can easily enough use preview, -convert- the Imperial to SI, then use that value for original_source. Eventually Jimp will produce the magic solution - I'm thinking a leading flag, "src=sec" or something, that eliminates the confusion up front and lets us respect the input of the original author. All in good time.

On another note, I don't think the docs have been updated for the "range" functionality. Is it far enough along that I can have a shot at including it? Franamax (talk) 08:01, 3 July 2008 (UTC)

Have a shot; I'll probably add some warnings about what's not ready yet ... yeah, the doc lag on the template is a little shameful but ... JIMp _talk·cont 08:05, 3 July 2008 (UTC)

I personally hate doing documentation, I'd much rather code. Keep performing the miracles, the rest of us can write the gospels ;) I did give it a try.

As far as what is currently working, would it be helpful to add a column to the List of units part of the docs? I can easily enough run through the possibilities.

And on the subject of updating docs, do I see a "e9USgal" parameter that seems to be undoc'd? If you can give me a clue where to look, I can also have a try at gathering up the latest goodies. Franamax (talk) 21:19, 3 July 2008 (UTC)

This is an option that I too would like to see realized. I work on articles about snakes for which all modern scientific literature uses metric units of measure. However, WP:MOS requires US-related articles to use United States customary units for the primary units of measure. Yes, I share the view that this may mislead the reader into thinking that the primary units were the original measurement, but that's what they seem to want. At least with this solution in place we'll still be able to see what the original was by looking at the raw text (or maybe by using a mouse-over pop-up?). Cheers, --Jwinius (talk) 17:37, 17 July 2008 (UTC)

That "requirement" is ... well let's just say I'm not too keen on that one, at least not as a blanket rule like it seems to be. However, in this particular case, I think you'd have a good argument to retain the original units. An article on an American snake is tied to the US, sure, but it's also tied to biology. Which is the stronger connexion? If it so happens that the snake can be found in Canada ... I think you've got a case where the rule either doesn't or at least shouldn't apply. Perhaps take it to WT:MOSNUM and suggest the guideline be clarified/adjusted. It also states:

Articles on scientific topics where there is consensus among the contributors not to convert the metric units, in which case the first occurrence of each unit should be linked.

But, yes, the feature is a bit of a must. JIMp _talk·cont 02:51, 18 July 2008 (UTC)

Dual conversion °F/°C broken?

For some reason {{convert|68|-|77|°F|°C|abbr=on|lk=on}} doesn't produce 68–77 °F (20–25 °C), but 68–77 °F (20–25 °C). Why is that? ––Bender235 (talk) 20:01, 11 July 2008 (UTC)

It's not broken, it's just the the dual function for temperatures is not finished yet. JIMp _talk·cont 15:07, 12 July 2008 (UTC)

Is it about to be finished in near future? ––Bender235 (talk) 12:05, 14 July 2008 (UTC)

I'll see what I can do. JIMp _talk·cont 17:41, 14 July 2008 (UTC)

• Still broken. ► RATEL ◄ 04:22, 21 July 2008 (UTC)

Subpage protection

Recently, there have been several cases of vandalism to subpages of this template (see e.g. Special:Contributions/Cakeeatingmewtwo). {{Convert}} itself is already protected as a high-risk template, as are many of its subpages — but not all. I'd like to propose that all the subpages (including those that don't exist yet) be (semi?)protected by adding the following line to MediaWiki:Titleblacklist:

Template:Convert\/.*  < noedit | errmsg=titleblacklist-custom-highrisktemplate >

possibly with the "autoconfirmed" option to reduce the protection level to semiprotection only. The custom error message, MediaWiki:Titleblacklist-custom-highrisktemplate, would explain why these pages are protected and how to request admin assistance for editing them (e.g. via {{editprotected}}).

I do realize that this would hinder legitimate development work on this template and its subpages; however, the per-page protections so far applied already do that anyway, and it's a fact that, as this template becomes more and more widely used, it also forms an increasing vandalism risk. Before going ahead with this, I'd like to hear others' opinions on how they feel about this, and whether the protection level should be full or only semiprotection. —Ilmari Karonen (talk) 01:13, 21 July 2008 (UTC)

It's funny that you posted this because today (or yesterday) User:MZMcBride has been going through and unprotecting many of converts subtemplates. His reasons for unprotecting templates are found here and here. How do we want to handle this? —MJCdetroit ^(yak) 01:11, 22 July 2008 (UTC)

This looks like a completely invalid reason for unprotecting, since the status of those subtemplates directly affect the operation and appearance of the primary template, and are that much more difficult to track down when vandalised. I'm all for adding this entire template and subtemplate group to the blacklist under semi-protection, so Jimp and others are not restricted from working on things. — Huntster (t • @ • c) 00:33, 23 July 2008 (UTC)

I've full protected every subpage with 50 or more transclusions (with the exception of a few that are only used on other subpages user talk pages etc). Hut 8.5 12:04, 24 July 2008 (UTC)

Well, the point of this was not to protect only some of the subtemplates, but all of them. They all have an equal chance of affecting the main template display. They all have an equal chance of being hit by vandals.

nowrap

I don't know if this has been brought up, or if it already exists, but can a nowrap parameter be added? --Elliskev 17:21, 22 July 2008 (UTC)

Way back in the first archive ... there really is no need, though, since you can put the whole template within {{nowrap}}, like this {{nowrap|{{convert|5|mi}}}}. JIMp _talk·cont 17:57, 22 July 2008 (UTC)

Aha! I tried, but forgot the pipe character. Thanks! --Elliskev 18:02, 22 July 2008 (UTC)

Wrapping is a good thing. I note that this {{nowrap method has been used on Midwest Regional Rail Initiative. It makes the article less accessible by preventing wrapping that is necessary. Please do not prevent lines wrapping unless there is a very good reason. Lightmouse (talk) 12:14, 24 July 2008 (UTC)

Lightmouse is right. Wrapping is a good thing (in the right places). JIMp _talk·cont 15:06, 25 July 2008 (UTC)

I've removed the nowrap from Midwest Regional Rail Initiative. However, I really don't see where accessibilty enters into it. And, I don't see how it qualifies as a good thing. I thought it looked better with as

55 to 80 miles per hour (89 to 129 km/h)

than

55 to 80 miles per hour (89 to

129 km/h)

Since there was an objection, I'll go with the latter. --Elliskev 15:47, 25 July 2008 (UTC)

to command

Can someone switch the WP:DASH for the to command to the ndash. I.e., {{convert|800|to|900|ft|m}} should use "–" instead of "-".--TonyTheTiger (t/c/bio/WP:CHICAGO/WP:LOTM) 08:10, 25 July 2008 (UTC)

I'm not quite sure what you mean, to gives to - & to(-) give en dashes. JIMp _talk·cont 11:57, 25 July 2008 (UTC)

See WP:DASH. There are MOS reasons for using the hyphen, ndash and mdash at different times. You are using hyphen where ndash should be used in the to command.--TonyTheTiger (t/c/bio/WP:CHICAGO/WP:LOTM) 14:54, 25 July 2008 (UTC)

I like to think I'm reasonably familiar with the guidelines on the use of dashes. I cannot see where the template goes against them. Note that they apply to the text as seen on the page not the code used as input to a template. JIMp _talk·cont 15:04, 25 July 2008 (UTC)

I am in the middle of a FAC at Wikipedia:Featured article candidates/BP Pedestrian Bridge and they are telling me that the to command should use ndashes.--TonyTheTiger (t/c/bio/WP:CHICAGO/WP:LOTM) 15:46, 25 July 2008 (UTC)

How I read it is that they are suggesting you use {{convert|800|-|900|ft|m}} rather than {{convert|800|to|900|ft|m}}.

{{Convert|800|to|900|ft|m}} gives "800-to-900-foot (240 to 270 m)" using hyphens (correctly though perhaps not very attractively).

{{Convert|800|-|900|ft|m}} gives "800–900-foot (240–270 m)" as suggested.

The template uses the right dash in the right place. It's en dash vs to not en dash vs hyphen. JIMp _talk·cont 16:44, 25 July 2008 (UTC)

convert spell out the unit in full?

How do I make convert spell out the unit in full? For example

{{convert|20000|USgal|l|lk=on}} produces:

20,000 US gallons (76,000 L)

But I wish to see the "l" expanded to "litre". -84user (talk) 21:20, 22 July 2008 (UTC)

The "Unit conversions" section of MOS:NUM says to spell out the main unit and abbreviate the units within parentheses, so I believe that what you're looking for is not setup as an option in {{convert}}. If you have a compelling reason to go against the MOS, I think you'd just have to do the conversion manually. — Bellhalla (talk) 04:10, 23 July 2008 (UTC)

Note that wp:context advises against linking plain english and common units of measurement. It suggests that the litre is a common unit. Furthermore, where a conversion is provided, the most commonly quoted reason for a link (access to a conversion factor) is not needed. Lightmouse (talk) 19:30, 23 July 2008 (UTC)

I suspect the underlying issue here is that "l", in most sans-serif fonts (as used on Wikipedia by default) appears as just a vertical bar. It's not obvious at a first glance, especially if you're not used to the abbreviation, that the "l" in "(76,000 l)" is a unit abbreviation rather than just stray punctuation. —Ilmari Karonen (talk) 12:45, 26 July 2008 (UTC)

Why not use "L"? —Werson (talk) 16:33, 26 July 2008 (UTC)

Uppercase "L" rather than lowercase "l" is the preferred abbreviation for "litre" in most English-speaking countries for that exact reason: In many fonts you can't tell the difference between the lowercase "l", the numeral "1", and the figure "|". The litre is a secondary SI unit - its use is permitted but not encouraged by the standard. It is actually a cubic decimetre.RockyMtnGuy (talk) 17:04, 26 July 2008 (UTC)

I have three pedantic points:

• the litre is not a 'secondary SI unit'. It is a 'Non-SI unit accepted for use with SI'. See the official SI website
• the correct term for SI units is 'symbol' not 'abbreviation'. This is because they are language independent just as 'Hg' is a language independent symbol for mercury.
• we can use experience from any country, not just English speaking ones. This is because symbols and fonts are independent of language.

As I say, those are pedantic points. Feel free to ignore this contribution. Lightmouse (talk) 22:25, 26 July 2008 (UTC)

Well, the international bureaucrats have never been afraid to call a spade a "manual digging implement". However, if we can't persuade people to use dm³, we should take note that, although both are acceptable, standards authorities in most English-speaking countries prefer uppercase "L" to lowercase "l" because it is less error-prone. At least it avoids the international English spelling dispute over "litre" vs. "liter". RockyMtnGuy (talk) 05:19, 27 July 2008 (UTC)

I am keen to read more of what you say. However, this issue is also being discussed at Wikipedia_talk:Manual_of_Style_(dates_and_numbers)#Litre:_l_vs_L. It would be better to have one debate rather than two. Please can we end the discussion here and merge into the one there? Lightmouse (talk) 09:37, 27 July 2008 (UTC)

If you want to use an uppercase L, you can use L in the template: {{convert|20000|USgal|L|lk=on}} 20,000 US gallons (76,000 L) --Random832 (contribs) 20:57, 30 July 2008 (UTC)

Please do not use 'lk=on' in this case. Note that wp:context advises against linking plain english and common units of measurement. It suggests that the litre is a common unit. Furthermore, where a conversion is provided, the most commonly quoted reason for a link (access to a conversion factor) does not apply. Lightmouse (talk) 09:06, 31 July 2008 (UTC)