Template talk:Convert

From Wikipedia, the free encyclopedia

Archives

2007 January–October November December 2008 January February March April May

Contents 1 Kilo-, Mega-Parsec 2 Stone (weight) 3 Parenthesese, right and wrong 4 Alternate primary units 5 Large Masses 6 intrusive space before inverse units 7 "Between" question 8 Bot to convert cum to m3 within the template 9 Per conversion, source unit value one 10 Your bot is damaging articles 11 US Dollar inflation

[edit] Kilo-, Mega-Parsec

Could you please add kiloparsec (kpc), megaparsec (Mpc) and maybe gigaparsec (Gpc) for distances to galaxies and stars? And something similar for lightyears as well. Because things like 57,000,000 parsecs (190,000,000 ly) don't look well. —Bender235 (talk) 10:52, 22 May 2008 (UTC)

Done. JIMp _talk·cont 14:09, 23 May 2008 (UTC)

Thanks. Now I might add this to Template:Convert/list of units/length. —Bender235 (talk) 15:09, 23 May 2008 (UTC)

[edit] Stone (weight)

Please change Stone (weight) to Stone (mass). --Zimbabweed (talk) 21:23, 22 May 2008 (UTC)

Done. JIMp _talk·cont 14:09, 23 May 2008 (UTC)

[edit] Parenthesese, right and wrong

A few users have complained that conversions are wrong because they do not agree with the precision. If a unit is in parentheses or brackets, it is merely an interpretation. I propose that we should get that documented somewhere. I would not like us to be forced to use 'approximately', 'c', 'ca', or '~' in each conversion and I think it is frustrating to get complaints that conversions are wrong. What do others think? Lightmouse (talk) 11:40, 26 May 2008 (UTC)

Yes, politely document the fact that it is they who are wrong. Do we want that here, at WP:MOSNUM or both? Coincidentally the use of "~" has just come up at WT:MOSNUM. JIMp _talk·cont 19:57, 26 May 2008 (UTC)

If we add something here, we could point out that WP:MOSNUM says

Converted values should use a level of precision similar to that of the source value; for example, the Moon is 380,000 kilometres (240,000 mi) from Earth, not ... (236,121 mi).

JIMp _talk·cont 20:02, 26 May 2008 (UTC)

As you have seen, we have had complaints about excessive precision e.g. 'about 100 yards away' should be converted to 'about 100 metres away' rather than 'about 91 metres away'. Then we have had complaints about inadequate precision in specifications. As you say, we should point them at that text but I also think that we should have a safety net that says the conversion *regardless of precision* is not to be relied upon. Or something to that effect. The first person to add the conversion template should not be criticised just because the precision in parentheses is not exactly how another (and possibly anti-conversion) editor demands it should be. Lightmouse (talk) 20:10, 26 May 2008 (UTC)

No, if you don't like it, change it or remove it, as long as you've got decent reason. A safety net would be good but let's not have the wording "not to be relied upon", it's not to be taken as exact but that doesn't make it unreliable. JIMp _talk·cont 20:24, 26 May 2008 (UTC)

I agree with you. However, I just saw a growing mass of people unhappy with conversions just because they did not happen to agree with the precision. Some of them are calling for a ban on conversions. Some of them are suggesting that conversions are only permitted if the precision happens to be what they think is the right level (I have seen millimetre precision being used for things like marathon distance). Some of them are demanding that extra caveats are put in the parentheses (e.g. '~'). Perhaps you are right, we just need more Wikipedia editors to learn that precision is part-art and part-science and the template can always be updated easier than a manual conversion. Lightmouse (talk) 20:35, 26 May 2008 (UTC)

This is a difficult one. What seems just so plain obvious to you & me is escaping these editors. You don't want to end up sounding as if you think you know better than they do but ... there must be a way. JIMp _talk·cont 23:37, 26 May 2008 (UTC)

[edit] Alternate primary units

Hello,

I have a request that a template argument be added here so that you can designate the alternate units to be primary. The place I would like to use this is in astronomy articles. Most literature is in parsecs but most of the wiki articles use light-years as the primary unit. Therefore, I would like to convert from the literature's parsecs to laymen oriented light-years, but show light-years (laymen oriented) as the primary unit something like this:

Today's usage:

{{convert | 27 | Mpc | Mly | abbr = on | lk = on }}

Becomes:

27 Mpc (88 Mly)

Requested usage:

{{convert | 27 | Mpc | Mly | abbr = on | lk = on | primary = Mly }}

Becomes:

88 Mly (27 Mpc)

Thanks.

WilliamKF (talk) 20:56, 27 May 2008 (UTC)

This has come up before. The feature is coming ... sometime. There is, of course, the problem that by putting the conversion first you potentially mislead the reader into thinking that this was the original measurement. This problem whilst (in my view) serious is not difficult to overcome. Another advantage of this feature would be to maintain consistency when the sources use differing systems, somewhat desireable in prose but necessary in tables. So, it's coming but, yeah, so is Christmas. JIMp _talk·cont 04:58, 28 May 2008 (UTC)

[edit] Large Masses

Is there a unit for million pounds or billion pounds (e.g. for use with mining and ores)? If not, I would like to suggest new units defined Mlb for millions of lbs and Blb for billions of lbs. Also, could you please define kt = kilotonne and ?? = megatonne.

Today's usage:

{{convert|80000|t|lb}}

{{convert|180000000|lb|t}}

Becomes

80,000 tonnes (180,000,000 lb)

180,000,000 pounds (82,000 t)

Requested usage:

{{convert|80000|t|Mlb}}

{{convert|180|Mlb|t}}

{{convert|80000|t|Blb}}

{{convert|180|Blb|t}}

Becomes

80,000 tonnes (180 million lb)

180 million pounds (80,000 t)

80,000,000 tonnes (180 billion lb)

180 billion pounds (80,000,000 t)

Kgrr (talk) 05:03, 29 May 2008 (UTC)

It's going to take a bit of a door-to-door sales pitch to get editors to finally switch from kt to kn for knot ... or perhaps I should just go the sledgehammer approach and give 'em a big red message for a couple of weeks. The symbol for megatonne is "Mt" and, unlike kt, Mt is empty. I have to say that I'd prefer Glb (i.e. G for "giga-") for consistancy's sake. Also note that if a number is spelt out, then so should the unit be. Thus we shouldn't have "180 billion lb". Instead what I'll do is have it written out in engineering notation (i.e. 180×10⁹ lb) when the unit is abbreviated like we've got with the large numbers of cubic metres & cubic feet. JIMp _talk·cont 05:32, 29 May 2008 (UTC)

• Getting users to switch from 'kt' to 'kn': Coincidentally, a few days ago I requested bot approval to convert existing templates from 'kt' to 'kn'. New ones will appear but the bot could be run again later. No user action will be required for that. Some users will see their own edits converted and notice the change. Others may not. Documentation will need to be updated to warn of the end of knot as 'kt'. After it has gone for a couple of months, it could be switched back on as kilotonne. Lightmouse (talk) 08:06, 29 May 2008 (UTC)

• Now that we are using k, M, G, and T within the template, I think it is also best to recommend km2 over sqkm within the template. This will make it more wysiwyg, easier to explain, and more extendable. For example, kg/cm2 is better than kg/sqcm. My bot proposal is to address that too.

I would welcome support for the bot proposal at the link I gave. Lightmouse (talk) 08:06, 29 May 2008 (UTC)

Great! I've been thinking of a different solution but they don't conflict. Seeing as most of these kts appear in a certain ship infobox, I've been thinking about rewriting that particular template. It's protected but once I've got the new version up and running it'll surely be welcomed. But now I've got to thinking about a metatemplate to make the update & updates of other info boxes a damn-sight easier. {{Convert}} will no longer have to be transcluded on the the page (within the info boxes) directly. I'll keep you updated (here). JIMp _talk·cont 08:46, 29 May 2008 (UTC)

Would you be kind enough to leave a note on the bot request page indicating your support? If you do support it, of course. Lightmouse (talk) 19:46, 29 May 2008 (UTC)

Mlb for million pounds and Glb for billion pounds are rather non-traditional. I would suggest e6lb (10⁶lb) for million pounds and e9lb (10⁹lb) for billion pounds (assuming you use American billions and not European billions). There are limits to how far you can go band-aiding these old traditional units for the 21st century. They really should use kilotonnes (kt) and megatonnes (Mt) since nobody but the USA officially uses pounds any more. Since kt has been been preempted for kilotonne by international standards organizations, US, Canadian and other marine authorities prefer kn. RockyMtnGuy (talk) 22:56, 29 May 2008 (UTC)

Then let it be e3lb, e6lb, etc. That was my second choice. It's probably clearer that way since attatching SI prefixes to non-metric units is not the commonly done thing & you're bound to run into strife somewhere with ambiguity I s'pose. We could extend this to other things e.g. e3mi for a thousand miles, e12km for a billion kilometres but call it a trillion since the original (i.e. European) definition is falling out of use in English. JIMp _talk·cont 00:08, 30 May 2008 (UTC)

Jimp, that's certainly a solution that sounds very workable. Could you please let me know when the new units are available? Kgrr (talk) 13:54, 3 June 2008 (UTC)

[edit] intrusive space before inverse units

In the templates for population density, such as Convert//sqkm (and likely other inverse-only templates), the usual non-breaking space is intrusive:

{{convert|100|/sqkm}}

yields

100 per square kilometre (260 /sq mi)

and

{{convert|100|/sqkm|abbr=on}}

yields

100 /km² (260 /sq mi)

Can this be easily remedied, or is it a deep assumption of the Convert template that there should always be a non-breaking space between the number and the unit?

In addition to the templates I mentioned above, this problem would affect the (needed but not-yet-coded) conversions of units of inverse time (RPM, Hz, s⁻¹, "daily").

Stephan Leeds (talk) 13:04, 29 May 2008 (UTC)

It can be fixed but it'll take a little time. JIMp _talk·cont 16:33, 29 May 2008 (UTC)

[edit] "Between" question

Greetings to the template masters! Is there a syntax for the convert template to handle the "between" or "from" case, in this instance "between 60 and 170 kg (132 - 375 lb)", alternatively "from 60 to 170 kg (132 - 375 lb)"? Thanks! Franamax (talk) 01:12, 30 May 2008 (UTC)

I've been holding out on it since it's only half done but ...

{{convert|60|and|170|kg}} gives "60 and 170 kilograms (130 and 370 lb)"

{{convert|60|to|170|kg}} gives "60 to 170 kilograms (130 to 370 lb)"

The long anticipated range functionality. JIMp _talk·cont 01:36, 30 May 2008 (UTC)

Took it out for a test drive - sweet. Nice work. It would be nice to have the option of a dash (or em-dash or whatever) instead of the "and" in the secondary, since the repetitive word is not strictly necessary. But hey, thanks for the enhancement! Franamax (talk) 01:51, 30 May 2008 (UTC)

Ahh, looking at the diffs here, you're already on that. Carry on MacDuff, and damned be he who cries "halt, enough" :) Franamax (talk) 02:01, 30 May 2008 (UTC)

Initially I had thought of using to wherever the unit is spelt out and an en-dash (not an em-dash per MoS) wherever the abbreviations/symbols were used, however, we'd have run into strife with negative temperatures: minus sign n en-dash minus sign m degrees Celsiheit looks pretty bad. That's why the repetition of the conjunctive word was made put in place. There is the optiojn of doing things as originally planned (to and en-dash), as you've noticed. To get this you use to(-) instead of plain to. There's something wrong with it though ... probably just a redirect pointing the wrong way. It won't be too hard to extend that option to the "and" case. It's early days for this functionality so things can be adjusted, e.g. we could have to do what to(-) now does and to get two tos have another code. JIMp _talk·cont 03:39, 30 May 2008 (UTC)

Jimp, might "by" (50 by 100 ft...) also be included? I've been coming across several of those instances lately. — Huntster (t • @ • c) 05:40, 1 June 2008 (UTC)

It is, plain en-dashes and plus minus signs too.

{{convert|60|-|170|ft}} gives "60–170 feet (18–52 m)"

{{convert|60|x|170|ft}} gives "60 by 170 feet (18 m × 52 m)"

{{convert|600|+/-|17|ft}} gives "600 ± 17 feet (180 m ± 5.2 m)"

Note that those dashes in the code are hyphens. JIMp _talk·cont 16:45, 1 June 2008 (UTC)

Brilliant as ever Jimp, thanks :) — Huntster (t • @ • c) 21:47, 1 June 2008 (UTC)

There should not be a unit on the first parameter in the converted range. Namely it is currently showing up as "60 by 170 feet (18 m × 52 m)" when it should be "60 by 170 feet (18 × 52 m)". -- KelleyCook (talk) 14:42, 3 June 2008 (UTC)

Not according to Wikipedia:Manual of Style (dates and numbers)#Unit symbols

In spatial values each number should be followed by a unit ("1 m × 3 m × 6 m", not "1 × 3 × 6 m³" or "1 × 3 × 6 m").

JIMp _talk·cont 20:43, 3 June 2008 (UTC)

As I understand it, each value needs to stand alone. You can get:

• asymmetrical units, such as "the cable is 5 mm by 100 m". However, I think that it is ok to drop the first unit if it is identical to the second. I cannot see any possibility of misinterpretation by a reasonable reader.
• ambiguous values, such as "production rose from 3 to 7 billion barrels", "the mountain range (3 to 7,000 m) could be seen". You need domain knowledge to disambiguate. That is a bad thing.

I would be interested to see any official text about the units. I took a look at the official SI website but could not find anything. Lightmouse (talk) 06:23, 5 June 2008 (UTC)

[edit] Bot to convert cum to m3 within the template

I have trial approval to run a bot. One of its task will be to modify template code. This will have no effect on the visible page but will make the edit mode more wysiwyg, easier to explain, and more extendable. For example, cucm will be replaced by cm3.

Jimp, can you give me a list of the relevant subtemplates that deal with squares and cubes that you would like me to tackle? Lightmouse (talk) 22:06, 4 June 2008 (UTC)

[edit] Per conversion, source unit value one

I've used the template in the following way in the Blackburn article:

"...land purchased from Joseph Fielden, lord of the manor, for £50 per {{convert|1|acre|ha|lk=on}} in 1855."

This renders as "1 acre (0.40 ha)", but I would prefer "acre (0.40 ha)", with the "1" not present. Is this possible with the template? And if it isn't, should it be? Beejaypii (talk) 16:19, 5 June 2008 (UTC)

What you really need is '£x per lb' (£y/kg). Lightmouse (talk) 16:53, 5 June 2008 (UTC)

Hmmm, I think '£x per acre' (£y/ha) would be more appropriate in the case I've described above. Anyway, can I assume that what I'm trying to achieve is not possible with the template and I therefore won't be able to use it on this occasion? Beejaypii (talk) 12:07, 6 June 2008 (UTC)

Yep, it's "£x per pound (£y/kg)" or "£x/lb (£y/kg)". Coincidentally, the thought crossed my mind a couple of weeks ago & I've begun dreaming up a solution. It can't be done yet. It won't be doable anytime this month. It's not impossible but it'll take some time to impliment. Stick around though because it will be doable sometime ... at least for the more common currency per unit combinations. JIMp _talk·cont 17:17, 6 June 2008 (UTC)

Ok, thanks for the responses. I'll keep this on my watchlist and await further developments. Beejaypii (talk) 00:14, 7 June 2008 (UTC)

[edit] Your bot is damaging articles

Moved from User talk:Lightmouse: begin
Your bot is substituting kn for knot. This is about as helpful as substituting 'B' for 'A'. Please desist.--Toddy1 (talk) 04:17, 6 June 2008 (UTC)

Moved from User talk:Lightmouse: end

Toddy1, you may be able to look elsewhere on this page for details of this. Jimp, can you please reassure Toddy1 that this is what is wanted. Lightmouse (talk) 08:31, 6 June 2008 (UTC)

Lightmouse, please stop your bot's run converting "knot" to "kn" in template {{convert}}. If "knot" works in the template, I can see no compelling reason to change it. What your edits are doing is clogging my watchlist with insignificant changes, and changing an easily identifiable unit—from the perspective of editors—to a more obscure abbreviation. — Bellhalla (talk) 12:37, 6 June 2008 (UTC)

Thanks for your comments. Please read the discussion above between myself and Jimp. Lightmouse (talk) 12:49, 6 June 2008 (UTC)

All I see is subbing "kn" for "kt" for the unit knot. Where is the discussion—and consensus, I might add—for this change? This affects a huge number of WP:SHIPS articles, and clogging, I suspect, many a watchlist for no net gain. — Bellhalla (talk) 13:03, 6 June 2008 (UTC)

Please search for kt on this page and on wp:mosnum. Trying to help. Lightmouse (talk) 13:07, 6 June 2008 (UTC)

Again, I will say: all I see is discussion for subbing "kn" for "kt". I saw, read, and understood the reasoning behind changing from "kt" to "kn", and wholeheartedly agree with making a change from an ambiguous abbreviation to a non-ambiguous abbreviation. What I don't see, and what I have been commenting about is the change of "knot" (note the spelled out word) to the abbreviation of "kn". I will again point out that I see no discussion or consensus to make that specific change. Because "knot" works in the template, and does help editors know that the unit is, in fact, the correct, non-ambiguous unit, I see zero compelling evidence that this change is beneficial.

Also, please don't edit my comments by removing indentation. That's pretty bad form. — Bellhalla (talk) 13:23, 6 June 2008 (UTC)

I too feel that the bot really isn't doing anything helpful. And, as Bellhalla states, I logged on this morning to see practically every ship article in my watchlist (literally, every ship here and then some) pinged with a bot edit. Granted, it's easy to just hit the "hide bot edits" button to clean it out, but then there's the issue of the non-Lightbot edits I might want to see. Again, it's unneeded disruption of many watchlists, for no real reason. It's far better to have "knot" in an infobox than "kn". Parsecboy (talk) 13:45, 6 June 2008 (UTC)

I see where Bellhalla is coming from in this...there was no reason to replace "knot" with "kn" when "knot" also works and is *not* going to eventually be replaced with something else, as "kt" will be. If this is what was occurring, then I agree that it was a very unnecessary action and would suggest not doing this in the future. — Huntster (t • @ • c) 14:04, 6 June 2008 (UTC)

I understand that you are unhappy. There are inconsistencies in the convert template and there are discussions on this page about this issue. The edits are a good faith attempt to improve things. Multiple indents make comments less accessible on a small screen so I moved some indents so that I can read what you write. I have stopped editing knots for the time being. We can see what other people say. Trying to help. Lightmouse (talk) 14:06, 6 June 2008 (UTC)

From what I reviewed of Lightbot's edits, offhand I see nothing besides the "knot"->"kn" issue that would be a problem, and that seems to be the only concern here (I agree, "kt" does need to be transferred to "kn" for clarity and consistency). On a separate note, regarding the indentation thing, I too believe this should not be done, since indentations are used to denote conversation threading. If you want to start a de-indented line, that's fine, but please do not refactor the positioning of other editors comments. — Huntster (t • @ • c) 14:15, 6 June 2008 (UTC)

Thanks for the reply. With regard to indents, this might mean that I will be unable to see some responses using my small device. It is somewhat frustrating for me. Try reading a wikipedia talk page with multiple indents on a 2 cm screen and you will see what I mean. Lightmouse (talk) 14:25, 6 June 2008 (UTC)

I completely understand your concern, but it is a matter of etiquette not to modify other's comments. The best you can hope for is, in my opinion, that you will set a trend or standard at some point and others will begin following suit. To be honest, the screen size issue is the biggest reason why I outright refuse to use internet-enabled phones *grin* — Huntster (t • @ • c) 14:40, 6 June 2008 (UTC)

Thanks for the reply. I try to be polite and regard etiquette as important. Modifying the text of a comment is indeed bad. I was merely moving it left by a few millimetres. It had not occured to me that people would be offended by that. Some people are not, but it seems some are. I will bear that in mind. Small screen devices are great for enabling internet access at times of enforced idleness such as 2 hours in an airport or on a train. They are unlikely to achieve the productivity of large static devices but it does mean that I can read and possibly respond to something 10 hours earlier than I could otherwise. As you can see, I am sold on the concept and look forward to internet enabled spectacles that will give the large virtual screen. Thanks for the feedback. Lightmouse (talk) 14:50, 6 June 2008 (UTC)

"kt" → "kn" is required (and doesn't involve a huge number of articles—I've been keeping my eyes on the "kt"s—the same eye just counted them, there are seven articles left. as for "knot", there are 49 articles). Clogging up watchlists for a while is a bad thing. Streamlining {{convert}} is a good thing. Where do we find the balance? Maybe the bot's had another possitive effect: perhaps it's drawn attention to the fact that "kt" is to be reassigned. It would have been reassigned months ago if only I'd got around to properly advertising the fact. Can we call the iron hot now?If my memory serves me correctly, the knot is the only unit for which there exists a well known abbreviation but with the option to spell it out in full in {{convert}}'s code. Remember that this option is made use of in a whole 49 articles. That's 49 out of 3419 articles which use the template to convert to or from knots. Granted there may be some advantage in having the unit spelt out in full in the article code but there are only 49 left ... I'm not sure how many articles there were before Lightbot but I don't recall that there were ever that many. Shall we let Lightbot finish them off? JIMp _talk·cont 18:04, 6 June 2008 (UTC)

Jimp, unless the intention is to delete the redirect at {{Convert/knot}}, the "knot"-to-"kn" conversions are a case of trying to "fix" a redirect that is not broken. See the WP:R#NOTBROKEN guideline, specifically item 5 "Someone finds them useful". As far as being 'just 49' articles, I had at least as many more on my watchlist that had previously been converted. I will again reiterate that I completely understand and concur with the "kt" to "kn" conversions and am in no way disputing or commenting on that aspect. — Bellhalla (talk) 13:07, 7 June 2008 (UTC)

If knot is deemed useful enough to keep, then let it be kept. If not, then let it be deleted. The argument for deletion: streamlining. The argument against: more readable code. A point worth noting: no other units (or few) have the spell-out-in-full option ... why should this one ... but then, why not? Another point: there are only 49 articles using this code ... but how much of this is due to Lightbot as opposed to a preference of editors to use kn? I'm not opposed to keeping knot if we want to keep it. If not, though, let it be deleted. JIMp _talk·cont 04:29, 9 June 2008 (UTC)

Lightmouse, quick question: why was Lightbot only replacing metric squares and cubes, and not "sqft -> ft2"? Wouldn't it be more logical and intuitive for both units to be formatted similarly? (Sorry if this has already been hashed.) — Huntster (t • @ • c) 22:41, 6 June 2008 (UTC)

I asked for guidance at Template_talk:Convert#Bot_to_convert_cum_to_m3_within_the_template. Feel free to make suggestions in that section. Lightmouse (talk) 00:01, 7 June 2008 (UTC)

Huntster, when this template was created, things with numbers in them like m3, km2 were avoided in the code itself. I think it was to avoid situations where the numbers were next to each other; i.e. km2|2, but I can't remember exactly. However, the resulting symbols were always displayed correctly no matter how the code was input, e.g. km², m², m³. Lightmouse is just trying to make the code wysiwyg, therefore following that logic only the metric should be changed. regards, —MJCdetroit ^(yak) 00:50, 8 June 2008 (UTC)

Yeah, I remember the reason that was set up (the sqm, sqkm thing...been watching this template since it was made, hehe), but I wasn't thinking about how the output for metric differed from Imperial/U.S. Apologies Lightmouse :) — Huntster (t • @ • c) 01:09, 8 June 2008 (UTC)

WP:MOSNUM currently says

For areas and volumes, squared and cubed US customary or imperial length units may instead be rendered with sq and cu between the number and the unit symbol (write 15 sq mi and 3 cu ft, not 15 mi sq and 3 ft cu).

Thus is "mi²", "ft³", etc. now an option? And if so, should mi2, ft3, etc. give this instead of "sq mi", "cu ft", etc.? Or is this some non-policy that slipped through in the latest MOSNUM tempest? JIMp _talk·cont 04:38, 9 June 2008 (UTC)

[edit] US Dollar inflation

Could someone build in a function to convert an amount of US Dollar from a given year to current value (or value from another given year)? Template:US Inflation produces a factor if feeded with a year, like {{US Inflation|year=1950}} produces 8.95145631, which means $100 (1950) equal $895.14 (2008).

Is it possible to enhance {{Convert}} with a function like this: {{Convert|100|USD 1950|USD 2008}}? ––Bender235 (talk) 13:09, 7 June 2008 (UTC)

This already exists. I've done such a template a few weeks ago: {{Inflation}}. It also has inflation data for UK and DE, and adding new countries is pretty easy too. -- alexgieg (talk) 23:14, 7 June 2008 (UTC)

Wow. Thanks. —Bender235 (talk) 08:21, 8 June 2008 (UTC)

It could have been done but since another template already exists why not use that? JIMp _talk·cont 23:33, 8 June 2008 (UTC)