Wikipedia

Template talk:Convert/Archive June 2016

< Template talk:Convert
Latest comment: 8 years ago by Wikid77 in topic shouldn't abbr=on the default value?


British pounds (£) to US dollars ($)

Latest comment: 8 years ago2 comments2 people in discussion

Does anyone know how to convert Pound Sterling (GBP) to United States Dollar (USD) using this function? I cannot found documentation for it. Thanks Mercy11 (talk) 05:05, 4 June 2016 (UTC)

Not with this function. You want Template:To USD. Hawkeye7 (talk) 06:13, 4 June 2016 (UTC)

Obscure units: the league – some problems here?

Latest comment: 8 years ago7 comments5 people in discussion

Why is is that the league is taken to be three statute miles, rather than three nautical miles? For example: 3 leagues (14 km), while 9 nmi (17 km) – you'd expect leagues to use nautical miles, surely, since the vast majority of the time they're encountered, it's in an (old) naval context. Moreover, there seems to be a glitch here: {{convert|3|league|km|abbr=on}} gives a singular unit: 3 leagues (14 km) Archon 2488 (talk) 22:33, 2 June 2016 (UTC)

This is partly explained at League (unit). The league was originally an hour's walk, and therefore a land measurement. Nautical use came later. There actually was a nautical league at one time but no one uses it today. Which brings up an interesting point, old sources should be checked to make sure we know which league we're talking about. I just ran across this today, at Diamond Rock; I added a conversion from leagues but didn't check the source to make sure they were talking about a modern statute league. Kendall-K1 (talk) 22:59, 2 June 2016 (UTC)
The numbers:
{{convert|3|league|km}} → 3 leagues (14 km) -- OP by Archon 2488
{{convert|9|nmi|km}} → 9 nautical miles (17 km) -- OP by Archon 2488
{{convert|3|league|km}} → 3 leagues (14 km)
{{convert|3|league|km|abbr=on}} → 3 leagues (14 km) -- OP by Archon 2488 (re the plural: league does not abbr)
{{convert|1.000|league|km mi nmi|sigfig=4}} → 1.000 league (4.828 km; 3.000 mi; 2.607 nmi)
-DePiep (talk)
Plural: yes, but other units with no abbr such as 100 acres (40 ha) do not show this problem with abbr=on.
The Diamond Rock article was the very one that made me notice this: at sea, you would assume it's nautical leagues, right? Archon 2488 (talk) 23:30, 2 June 2016 (UTC)
In 1803? I don't know. Here's a source from 1845 that says "Great confusion often arises from the different measurements alloted to the League in different countries," and gives the English Sea League as 3000 Geometrical paces or 3 English miles.[1] But I thought a geometrical pace was five feet so that's no help. The cited source at Diamond Rock doesn't say what kind of leagues. Maybe we do need a "sea league" unit for the conversion template. Kendall-K1 (talk) 00:17, 3 June 2016 (UTC)
{{convert|3|bar|psi}} → 3 bars (44 psi)
{{convert|3|bar|psi|abbr=on}} → 3 bar (44 psi)
I'd expect an abbreviated unit not to be rendered as a plural, even when the unit's abbreviation is the same as the unit's name - I suspect 'acres' is the exception, not the rule. --RexxS (talk) 00:45, 3 June 2016 (UTC)
Yes, that's right. A tilde can be used to specify that a unit has no symbol, and its name should always be used (with plural when needed). The documentation is here. The league unit was probably never noticed as needing the tilde. It would be good if someone would check the page at that documentation link and post a list here of any other units which need a tilde. Please don't bother editing that page because I update it from a list I have. The fix in the meantime is to not use abbr=on. Johnuniq (talk) 01:02, 3 June 2016 (UTC)
We're getting into some deep water here, I feel. Martinevans123 (talk) 11:09, 6 June 2016 (UTC)

Module version 14

Latest comment: 8 years ago7 comments4 people in discussion

Some changes to the convert modules are in the sandbox, and I intend switching the main modules to use the sandbox soon.

The changes are:

  • Units Fixed Moroboshi's minor corrections (from itwiki): "shaku" link = Shaku (unit); "hp-electric" link = Horsepower#Electrical horsepower; Beverage can#Capacity link changed to Beverage can#Standard sizes for three units like "Cal/12USozserve"; inserted "large" into name for "Cal/h".
  • Units Fixed JFG's mi/d unit name correction: "mi/d" name changed to "miles per day".
  • Categories The current two error tracking categories are replaced with one (Category:Convert errors) as it is easier to track problems on one category page. Discussion here.
  • Input number and significant figures An input value such as 4000 is assumed to have one significant figure, while 4001 has four. Convert has always accepted 4000. as having four significant figures. The new version is the same but displays "4000" without the dot. Discussion here. Examples:
    • {{convert|4000|m}} → 4,000 metres (13,000 ft) (same in old and new versions)
    • {{convert|4000.|m}} → 4,000 metres (13,123 ft) (this is the output from the new version; the old version shows "4,000.")
  • Messages If an edit is saved with convert errors, the messages shown are easy to miss. To help editors notice problems, convert will now show hard-to-miss messages when an edit is previewed. A new test=preview parameter allows a prominent error message to be seen in a saved page, and test=nopreview will preview a real message as it would appear if the edit were saved. Discussion here. For this change, convert's messages now use $1, $2, ... as parameter place holders, instead of %s.
  • Wikidata Two new modules process new parameters input=x and qid=x and test=wikidata. Use of these parameters is not supported except as documented for accessing Wikidata information from an infobox. In other words, they should not be used in articles, but may be used in the wikitext for an infobox.
    • Use {{convert|test=wikidata}} to list the known Wikidata units from Module:Convert/wikidata/data and to check the syntax in that module. The units are listed at the module talk page.
    • Similarly, {{convert/sandbox|test=wikidata}} lists Wikidata units from Module:Convert/wikidata/data/sandbox and checks syntax. See the module talk page.
    • An infobox can use wikitext such as {{convert|input={{{diameter|P2386}}}}}. That uses the diameter parameter, if given, or the Wikidata diameter property P2386. If an input value and a known unit can be extracted from input, a result is shown. Otherwise, any input text is displayed. No output occurs if the input is blank or is an undefined property identifier. No error message is shown.
    • Additional parameters can be included, for example, {{convert|input={{{diameter|P2386}}}|ft|abbr=off|sp=us}}. The effect of input=x is that a value and unit are inserted as the first two unnamed parameters, if possible.
    • Some units are recognized as being valid, but only the input is displayed because no useful conversion is possible. For example, a property used in a particular article may translate to "12 millivolts"—that text would be displayed (or "12 mV" if abbr=on) and no conversion would be performed.
    • If a property such as input=P2386 is given, it is also possible to specify an item identifier, such as qid=Q1513315. Specifying qid is an expensive operation. Normally, no qid would be given and the item associated with the current page would be used. Item Q1513315 is for South Pole Telescope and {{convert|input=P2386}} could be used at that page to access its P2386 property. If it were ever necessary to access that property on another page, {{convert|input=P2386|qid=Q1513315}} would be needed.
  • Module:Convert/wikidata/sandbox is a new module to access Wikidata for convert. It is invoked only if input=x or test=wikidata are used.
  • Module:Convert/wikidata/data/sandbox is a new module to cache Wikidata information with units for convert. It is loaded if needed by Module:Convert/wikidata/sandbox. The data module is used to translate any input=x parameter to a unit code recognized by convert. It also serves to prevent an amplification attack which might result if a single mistaken change to a property at Wikidata were to break a unit used in many articles.

Infobox examples

  • {{convert/sandbox|input=12 kg}} → 12 kilograms (26 lb) ("kg" is a convert unit defined in convert/data)
  • {{convert/sandbox|input=12 kilograms}} → 12 kilograms (26 lb) ("kilograms" is defined in wikidata/data as an alias for "kg")
  • {{convert/sandbox|input=P2386|qid=Q1513315}} → 10.0, 1 metre (32.8, 3.3 ft) (value and unit from property P2386 at item Q1513315)
  • {{convert/sandbox|input=P2386|qid=Q1513315|abbr=on}} → 10.0, 1 m (32.8, 3.3 ft) (same convert but with an extra parameter)
  • {{convert/sandbox|input=two widgets}} → two widgets (unknown input is output as given)
  • {{convert/sandbox|input=P666}} → (a not-found property gives no output)
  • {{convert/sandbox|input= }} → (blank input gives no output)

Johnuniq (talk) 07:46, 28 May 2016 (UTC)

Notifications:

  • The unit fixes supplied by Moroboshi and JFG are included above.
  • Editors investigating the use of Wikidata in infoboxes include RexxS, MSGJ and Mike Peel. Please review the Wikidata features above.

Johnuniq (talk) 07:46, 28 May 2016 (UTC)

A flippin' mess

Latest comment: 8 years ago19 comments8 people in discussion

Been editing an article on hydrofoils in which speed are given in mph, km/h & knots. Ideally, we'd want to make knots the main unit but order=flip is no help when you're converting to multiple units. {{convert|10|km/h|kn mph|abbr=on|order=flip}} currently gives "5.4 kn; 6.2 mph (10 km/h)". What we'd really want is "5.4 kn (10 km/h or 6.2 mph)" ... (note the "or" instead of the semicolon, this semicolon has just got to go, it was a bad ungrammatical idea half a decade ago and still is ... but that's another issue).

For the sake of versatility, we'd also want the capacity to place the input at any position in the brackets (pretty much essential if we're creating a table in which various units are used in sources ... though it's cells here not brackets). I'd suggest that the parameter order be allowed to take integers from 0 up to specify the position of the input value in the output. order=0 would be the default with the input value as the main unit. order=1 would put the input in the first position in brackets, order=2 would put it in the second position, etc. As for order=flip, that could be equivalent to order=1 or it could put the input value last (it shouldn't matter which). Jimp 07:30, 6 June 2016 (UTC)

I think displaying three units is too much. I would just display knots and km/h. Kendall-K1 (talk) 10:57, 6 June 2016 (UTC)
Many nautical-based articles use three values for distance, e.g. EgyptAir Flight 804: 280 km (170 mi; 150 nmi). Is this always too many? Martinevans123 (talk) 11:12, 6 June 2016 (UTC)
It seems too many for me. If we use more than just the standard unit plus one US unit, it starts getting cluttered. I would use standard units plus either statute on land or nautical at sea or in the air. But that's a style issue and off topic for this discussion. The question is about a technical fix to provide something we can't do now. I probably shouldn't have de-railed the discussion. Kendall-K1 (talk) 12:52, 6 June 2016 (UTC)
I have noticed this problem before. Could we not have an option such as "order=flip1" (or something more intuitive, that's just the first thing that came to my mind) which makes the "first" converted unit display as the primary quantity? Or perhaps change the behaviour of "order=flip" when multiple outputs are specified so that only the first is taken to be the primary?
The hack is just to do the conversion manually and reorder things appropriately. Archon 2488 (talk) 14:18, 6 June 2016 (UTC)
There are some fields where 3 different units are common. For automobile articles we often get figures from references in PS, hp or kW. PS was common in European and Asian countries in the same way that hp was common in most English speaking countries.  Stepho  talk  17:45, 6 June 2016 (UTC)

Sorry but I don't have any ideas and will just note some previous discussions. This has been raised before with no solution (example: Feb 2015 archive). There was also a discussion which I can't find about wanting a way to use a value from a source (say 10,000 PS) but not show that unit in the result. An example of the second point follows with a workaround that is unattractive due to the semicolon issue Jimp mentioned:

  • {{convert|10,000|PS|ihp kW|disp=out|0}} → 9,863 ihp; 7,355 kW

This workaround is too ugly and has a rounding problem:

  • {{convert|{{convert|10,000|PS|ihp|0|disp=number}} |ihp|kW|abbr=on}} → 9,863 ihp (7,355 kW)

The rounding problem is that there is no good way of applying the implied precision of the 10,000 input to the result.

  • {{convert|10,000|PS|ihp|disp=number}} → 9,900
  • {{convert|10,000|PS|ihp|0|disp=number}} → 9,863

I'm caught up in some date complexities. At some future quiet time I'll do more thinking about a new syntax that might cleanly handle this. Johnuniq (talk) 00:04, 7 June 2016 (UTC)

Thanks @Johnuniq:. Of course, this is just one of the issues with the template which needs attention and we're all pressed for time. Perhaps we could create a to do list or something. Anyhow, for clarity, this is what I have in mind (using several pressure units to illustrate the idea, not that we'd generally need as many as this).
  • {{convert|100|kPa|Torr atm psi inHg|order=0}} → "101 kilopascals (760 Torr, 1.00 atm, 14.6 psi or 30 inHg)"
This would be the default, i.e. equivalent to {{convert|100|kPa|Torr atm psi inHg}}
  • {{convert|760|Torr|kPa atm psi inHg|order=1}} → "101 kilopascals (760 Torr, 1.00 atm, 14.7 psi or 30 inHg)"
This would be the regular flip function, i.e. equivalent to {{convert|760|Torr|kPa atm psi inHg|order=flip}}
  • {{convert|1.00|atm|kPa Torr psi inHg|order=2}} → "101 kilopascals (760 Torr, 1.00 atm, 14.7 psi or 30 inHg)"
Standard atmospheres (the input) put in position 2 (the main unit being in position 0)
  • {{convert|14.7|psi|kPa Torr atm inHg|order=3}} → "101 kilopascals (760 Torr, 1.00 atm, 14.7 psi or 30 inHg)"
  • {{convert|30|inHg|kPa Torr atm psi|order=4}} → "100 kilopascals (760 Torr, 1.0 atm, 15 psi or 30 inHg)"
Obviously, we wouldn't actually use order=0 but, conceptually, this is what it would mean. As for whether order=flip should put the input in position 1 (as in the example above) or last (as suggested as an alternative possibility above), either way would work but having order=flip equivalent to order=1 would probably be simpler to code (I assume, though, I'm not that familiar with Lua) and simpler to use (fewer ways to do the same thing typically lessens confusion). Indeed, making order=flip redundant to a more systematic method and deprecating it, might make things much more straight forward.
I wouldn't be terribly opposed to order=flip1, order=flip2, etc. instead but it seems a bit of an overkill. Users would likely get used to either and, generally, the shorter is preferable as long as it makes sense. I'd say that order=1, order=2, etc. would make enough sense since "order" gives the hint well enough as to what's going on. Sure, we've got used to "flip" but the template is probably going to last for a few more decades (assuming pollies start taking the environment seriously) and, in time, we'll accustomise to a new regime. order=flip could then be phased out in favour of the more systematic alternative. (We've got to get cracking on the phasing out of deprecated options ... somehow, just the other day I found a sing=on.)
I'm suggesting a numbering starting from 0. To start from 1 would work just as well, I suppose, but somehow I reckon that the separation of main and secondary units makes better sense (also, since order=0 would actually not be used, it's probably easier).
@Kendall-K1:, thanks for your input. Yeah, of course, you're not aiming to derail the convo and, for the most part, you're right, converting to more than one unit is too much, but there do exist cases where it is quite appropriate to do so. The case of speed of watercraft is a good example. Some of us are familiar with knots, some are not, of those who are unfamiliar, most would prefer either kilometres or miles per hour with the other being gobbledy gook. Anyhow, as you note, this is not really a discussion to be had here (bring it up at WT:MOSNUM if you like but ... ah, SNOWBALL).
Jimp 06:42, 7 June 2016 (UTC)
My recap: In the OP, Jimp points to two issues: the control of output ordering, and the presentation of the 2nd, 3rd, ... output value (i.e., the unwanted/incorrect semicolon and -- when order is altered -- strange grouping in brackets). Johnuniq added two more issues: other output manipulation (e.g. omitting the input value) and rounding in that situation. All could use some redesign indeed (preferable to patchwork; long-term getting rid of inherited habits). I'm sure Johnuniq oversees their intricacies and independencies, and the analysis + proposals by Jimp are sophisticated as usual. -DePiep (talk) 07:23, 7 June 2016 (UTC)

I put the order=N proposal at the top of my to do list. It occurs to me that order=0 might mean to not show the input as required for the PS example above. It sounds achievable but I won't know what is involved until I get a chance to study the consequences. Johnuniq (talk) 11:13, 8 June 2016 (UTC)

Well, now I want to weigh in. In response to Johnuniq saying here: "... order=0 might mean to not show the input". My claim: do not go this route (adding unrelated meaning to a parameter, just because the option is unused). In the logic we need, |order= has a single and unconfusing meaning (by logic and for the Editor alike). That meaning is not: "Leave out parts". All options for order=... should be related to -- well, the order of the 'values' (=those number+unit text things, per SI naming convention btw). If one needs an other option topic, use an other parameter.
Good examples of using a single param for a single topic are |adj= and |abbr=, more or less.
OTOH, in the topic "show parts of output only" is served badly today. Seeing the doc, obviously a new parameter |part= is needed that does all this stuff -- and does nothing else. Currently, the 'show parts only' uses various shared parameters, which is bad (disp, abbr).
This for the long-term design of parameters required. -DePiep (talk) 19:35, 8 June 2016 (UTC)
I second DePiep's argument. order=N should only ever put the input in the Nth position. We've got enough unrelated meanings in parameters already, let's not make things worse. Jimp 08:54, 13 June 2016 (UTC)

For multi-value flip, use nested Converts

Use a nested Convert to get the flipped number by "disp=number" as input to the final layout:

  • {{convert| {{convert|disp=number|100|kPa|Torr|0}} |Torr |kPa atm psi inHg}} to give:
    750 torrs (100 kPa; 0.99 atm; 14.5 psi; 30 inHg)
The nested Converts turn 100 kPa into 760 Torr, as input to the final Convert of 4 values including flipped output "100 kPa". There are many unusual cases where Convert does not provide direct options, but Convert has been expanded to allow nested use, as within the related wp:wrapper templates. -Wikid77 (talk) 22:57, 10 June 2016 (UTC)
Yes, it can be done like this but it's cumbersome to code meaning that the code is not clear, not streamlined and not obvious to users and it's liable to rounding errors. We should aim at subsuming "wrapper templates" into the main function. Jimp 03:30, 11 June 2016 (UTC)
The main function Convert has become a gargantuan monolith, with numerous problems now ingrained for years which had been fixed (years ago) by the various Convert wp:wrapper templates. Re-read the prior 3 years of users requesting conversion features, no longer provided, which had been available in 2013 with wrappers of Template:Convert/old. With the latest improvements to the MediaWiki software, many markup templates now run over 2x faster, and some are 4x faster than their Lua script forks can run. -Wikid77 (talk) 11:20, 11 June 2016 (UTC)
Not a monolith, but a versatile single point of entry that allows numerous options, much more easily reached by editors, and felxibility in extensions. In the past 3 years the number of pages using {convert} has doubled to 800k. -DePiep (talk) 12:16, 11 June 2016 (UTC)
I recently extracted all converts in articles from the June 2016 dump. For the lovers of statistics, there were:
  • 1,672,224 converts in 437,974 articles in November 2013
  • 1,773,340 converts in 461,854 articles in May 2014
  • 1,962,818 converts in 502,473 articles in April 2015
  • 2,325,616 converts in 556,024 articles in June 2016
That only counts uses of {{convert}}, and does not include the thousands of cases where infoboxes and other templates call convert. Passing the 2,325,616 converts from June 2016 through uniq gives 692,027 different converts. In other words, 70% of all converts are duplicates! Johnuniq (talk) 04:45, 12 June 2016 (UTC)

We should be concentrating on this template rather than creating confusing workarounds which end up barely used, hard to fathom and often contravene the MOS. Jimp 08:40, 13 June 2016 (UTC)

They are not "hard to fathom" and any problems with wp:MOS can be fixed without deleting templates. As for barely used, recall that some editors have been systematically deleting instances from hundreds of pages to give the false illusion as "unused" and then months later people ask for the features to be provided again. -Wikid77 (talk) 02:06, 15 June 2016 (UTC)

Big red error message

Latest comment: 8 years ago5 comments3 people in discussion

The recent update to convert (1 June 2016) included a tricky feature to show a hard-to-miss error message when previewing an edit with a problem. As has always been the case, the module shows an easy-to-miss message in a saved page. Those following convert might like to see this WP:VPT section where it is revealed that the tricky preview feature is a resource hog. Apparently, devs would like the preview of an edit to exactly match what the saved edit would look like. At any rate, there is a suggestion that the templates which use this feature should be changed to not use the feature and to always show a big red error message. It is pointed out that Category:Convert errors is usually empty so the fact a couple of articles have an ugly message for a while should not be a big deal. I've become fond of convert's messages, but would be happy with Big Red if that solves a problem. Johnuniq (talk) 02:02, 17 June 2016 (UTC)

Thanks for reporting the REVISIONID problems. Certainly, let's fix Module:Convert to remove glaring red-error messages from Convert if it has angered the wp:developers. Perhaps a more efficient check for preview mode can be found. As for Convert errors, many users regardless just save garbled edits quickly, and so the later cleanup by wp:wikignomes becomes the best overall tactic, as they can also correct cites or grammar while updating {convert}'s on a page. Years ago, Convert had various orange-error messages, but the long-term results confirmed some users save edits quickly without proofreading Convert messages, whether large or small. Hence, superscript advisories "[convert: fix unit]" plus "Category:Convert errors" will be sufficient and effective in correcting those errors. -Wikid77 (talk) 05:07/05:12, 17 June 2016 (UTC)
I agree that some editors quickly add converts then move to the next article without much checking of what happened, so a small error message might be best. That was the original motivation for such messages. However, the reason for wanting big red messages, at least in preview, is that there are many careful editors who simply miss seeing that one of the twenty converts they added to a long article had a simple typo. The aim of the big red messages was to help people who are trying to get things right—it's very easy to miss a superscript blue message in the middle of a big article. This is one of those cases where there is no good solution (apart from getting a technical fix in the underlying software). Johnuniq (talk) 05:39, 17 June 2016 (UTC)
Is there any reason why we shouldn't just use CSS to determine whether we are in Preview or Saved mode? This is a demo of some text that displays as large red text in preview, but small blue text when saved. The CSS definitions for your common.css to try it out are:
.cvt_err {
	color: blue;
	font-size: 85%;
}
#wikiPreview span.cvt_err {
	color: red;
	font-size: 115%;
}
Obviously, you can vary the CSS to give whatever effect you want and it would need those sort of definitions to be in MediaWiki:Common.css when finalised. The {convert} module would just need to wrap its error message in whatever you wanted to call the class (I'd recommend something specific to convert, for later trouble-shooting). Is there a problem I'm missing with all that? --RexxS (talk) 14:56, 17 June 2016 (UTC)
I infer from a recent comment at VPT that convert does not have to change because it only accesses REVISIONID if an error occurs. Using CSS would be good if nothing else were available, but the preview and saved messages are different in other ways. An example I used at VPT is how "the statue is {{convert|12|m|junk}} high" looks in preview and in a saved article:
the statue is 12 metres (Error in convert: Unit name "junk" is not known (help)) high
the statue is 12 metres ([convert: unknown unit]) high
Johnuniq (talk) 00:44, 18 June 2016 (UTC)

Astrophysical conversions

Latest comment: 8 years ago24 comments7 people in discussion

In a number of astrophysics articles, values are given in solar masses (M☉) and solar radius (R☉). The conversion to conventional units such as km, au, kg are done by hand and not always without controversy (see this edit). I believe this could be short-circuited if we added M☉ = 1.989×1033 g and R☉ = 9.9598×1010 cm to the Template:convert data. Note: Units here described in cgs as most astrophysics texts use them, but would presumably be defined in the table as SI units.

Alternatively, if there is a way to specify the conversion factor in the convert template (I don't see any such option), the odd units could be provided directly in the article (documenting the value used), or added to a {{value}} template for even more explicit specification.

Looking in the archives of this talk page, I see these two units were listed as potential units back in 2009, but I don't see that ever being rediscussed. So the questions:

  • Is this worth pursuing? M☉ and R☉ are used in many of the star articles, as they are standard reference units used in astronomy publications. The preface to K.R. Lang's Astrophysical Formulae lists 23 values as being so fundamental they won't be described in the text, will only be listed in the preface. M☉ and R☉ are 2 of those 23 values (along with quantities like c, amu, R and h), so the choice of including them here wouldn't be entirely arbitrary.
  • If it's worth pursuing, is this the correct forum?

Thanks, Tarl N. (talk) 20:15, 11 June 2016 (UTC)

Isn't R☉ = 6.957×1010 cm (according to Solar radius) ? -- WOSlinker (talk) 21:26, 11 June 2016 (UTC)
You are absolutely correct. I typoe'd the leading digit (6 vs. 9). 6.9598(7)e10 cm per K.R. Lang 2nd Ed. 6.955e10 cm per K.R. Lang 3rd Ed. If we were to add the value, I'd use the one determined by SOHO, 696,342 km. Tarl N. (talk) 23:25, 11 June 2016 (UTC) Correct that, I'm behind the times. IAU has defined it specifically: Resolution B3 defined the nominal solar radius (symbol R☉) to be equal to exactly 695,700 km. Tarl N. (talk) 23:32, 11 June 2016 (UTC)
As always, please provide actual examples of articles that could use this conversion. The number of theoretical conversions is inacceptably high. -DePiep (talk) 22:40, 11 June 2016 (UTC)
Examples of where this could be used: R136a1, UY Scuti, WOH G64, Westerlund 1-26, V354 Cephei, VY Canis Majoris#Properties, and NML Cygni#Characteristics. Tarl N. (talk) 23:25, 11 June 2016 (UTC)

Searching the master list of units for "solar" shows there is a solar mass but no solar radius.

  • {{convert|1|solar mass|kg lb}} → 1 solar mass (2.0×1030 kg; 4.4×1030 lb)
  • {{convert|1|solar mass|kg lb|abbr=on}} → 1 M☉ (2.0×1030 kg; 4.4×1030 lb)
  • {{convert|1|solar mass|kg lb|0|abbr=on}} → 1 M☉ (1.9885499999999×1030 kg; 4.3840023146773×1030 lb)

DePiep is correct that examples are needed but the reply shows that it is likely the unit would be useful, so I added solar radius.

  • {{convert|1|solar radius|km mi}} → 1 solar radius (700,000 km; 430,000 mi)
  • {{convert|1|solar radius|km mi|abbr=on}} → 1 R☉ (700,000 km; 430,000 mi)
  • {{convert|1|solar radius|km mi|0|abbr=on}} → 1 R☉ (695,700 km; 432,288 mi)

The solar mass unit does not have an italic "M", and I copied that for the new solar radius. Solar mass is only used in two articles: Stellar evolution#Protostar and Baryonic dark matter. If it should be italics, please reply. Inserting two apostrophes around "R" at Module:Convert/extra would be easy, but fixing solar mass will have to wait until the next convert update, although a temporary fix could be made. Johnuniq (talk) 02:43, 12 June 2016 (UTC)

Cool! Thanks. Don't bother changing the Solar Mass, if it's been present so long, it deserves to be left alone. It was Solar Radius I was looking for. Tarl N. (talk) 05:31, 12 June 2016 (UTC)
And, articles above updated. As I run into other articles converting solar radiuses (radii? Probably WP:ENGVAR), I'll fix them as well. Tarl N. (talk) 06:19, 12 June 2016 (UTC)
@Tarl N.: Good, but we like to get units correct! It's obvious from your posts here that you think M and R should be in italics, so I'm asking if that is like WP:ENGVAR, and some people use R while others use R. We need someone familiar with the topic to say what it should be. Johnuniq (talk) 06:50, 12 June 2016 (UTC)
I hope that the IAU does not define unit variants by ENGVAR. As described below, it looks like there is a mixup in formatting & defining between quantity and unit. Our whole galaxy is affected! -DePiep (talk) 12:03, 12 June 2016 (UTC)

About italics: quantity or unit?

The BIPM and its SI brochure has defined this general rule: "The value of a quantity is generally expressed as the product of a number and a unit". So, the quantity 'speed' of a particle may be written as: v = 25 m/s, and v = 90 km/h. By SI: the "value" of the quantity speed is "25 × m/s", not "25". BTW, {{Convert}} does not use 'value' this SI way in documentation & talks (more often, we see 'measurement' or a verbose description).

Then, terms 'solar mass' and 'solar radius' are quantities, and therefor SI prescribes italics: "Symbols for quantities are generally single letters set in an italic font, although they may be qualified by further information in subscripts or superscripts or in brackets." Brochure 5-3. Also, 5-3-2 explicitly says: qualifiers (subscripts) should be added to the quantity, not the unit. That would be R☉ and M☉ then: the capital in italics.


But. What happens here is that the quantity is treated as a unit (R☉ = 1 R☉ ???). That is wrong by SI, and causing confusion. Compare A. "The solar mass is 1.989×1033 g" (SM = 1.989×1033 × g) vs. B. "The distance is 3 × [one] solar mass" (d = 3 × solar mass). In A, 'solar mass' is the quantity, in B it is: the unit (derived from basic the SI unit kg, OK).

What we need is, for solar mass alone (and solar distance again): quantity name and its symbol; and unit name and its symbol. Of these four {{Convert}} should only have: unit name + unit symbol (with conversion factor). Not: quantity (just as {convert} does not use 'speed' or v, right?). This should be sourced by the defining body, I guess some international astronomic institute. Of course, all this only if that institute wants to adhere to SI. (Didn't a similar issue rise wrt AU here, a year ago?). -DePiep (talk) 11:18, 12 June 2016 (UTC)

Same with solar luminosity: "The solar luminosity, L☉, is a unit of radiative (power emitted in the form of photons) conventionally used by astronomers to measure the luminosity of stars." (a unit to measure? Or a unit to describe a measurement? Or: a quantity that describes the luminosity relative to the sun's luminosity, which may be described by a suitable unit of choice?). Anyway, as a unit, it may not have the subscript sun symbol. The quantity should have it. See link 5-3-2 above. -DePiep (talk) 11:35, 12 June 2016 (UTC)
As a matter of practical reality, it's usually italicized. The example I gave earlier (Astrophysical Formulae, K.R. Lang, Springer-Verlag, ISBN 978-3540612674) uses the non-italicized form in the 3rd Edition inside cover (where it defines the quantity), but uses the italicized version in the text. However, the text uses are all in the context of equations, where everything except units (cm, kg ) and functions (ln, exp) are italicized. Yes, in the context where kg is non-italic, R☉ is still italicized. All the other cases I can find (various astronomy texts) seem to also always use it in italicized mode. Tarl N. (talk) 19:35, 12 June 2016 (UTC)
It's not you, it is the IAU. We need definitions. As you can smell, I got distracted in my research (looking for RS's and examples). In short, by SI:
IF "R" is the quantity ("the distance"), write italics R and add subscripts to qualify. Write R☉. In this, {convert} is not involved (as with 'speed', or v).
IF "R" is the unit ("x km"): good luck, IAU fails. Isn't there any scientist in IAU, knowing the diff between quantity and unit? For {convert} and Johnuniq: as a unit for {convert} to handle, use any freedom you have to make the unit symbol in upright (roman): R☉. To show: "The distance is 7.5 R☉". -DePiep (talk) 21:03, 12 June 2016 (UTC)
I think I understand the distinction between a quantity and a unit, but I imagine the principles of WP:COMMONNAME apply so convert should show whatever is commonly used. A wikiproject might clarify that although Tarl N's response makes it clear that italics is standard procedure. Johnuniq (talk) 23:41, 12 June 2016 (UTC)
Sure, we should go with Tarl N & the source mentioned for unit. And we should sigh, for IAU's ignorance. (to compare, read: chemical institute IUPAC about names for new elements [2] !). This issue will soar for many more years. But {convert} can do these units. please do not add ENGVAR options. -DePiep (talk) 23:54, 12 June 2016 (UTC)
Agreed. Also, to reduce some confusion, my ENGVAR mention wasn't about the roman/italic presentation, but about radiuses vs radii. Both are acceptable plurals, but it seems British writings use the formal Latin plural more often than the anglicized one. Tarl N. (talk) 00:10, 13 June 2016 (UTC)
OK, solar radius is now italics. If wanted, I can do a temporary fix for solar mass, otherwise it will be fixed in several weeks when the next convert update occurs. Johnuniq (talk) 00:57, 13 June 2016 (UTC)
Maybe these are considered quantities and that's why they're italic. The speed of light, c, can be used like a unit, e.g. "0.99 c", but the "c" is still italic. The discussion belongs at WT:MOSNUM. Jimp 08:48, 13 June 2016 (UTC)
... or at an IAU congress [3] [http://www.iau.org/publications/proceedings_rules/units/. -DePiep (talk) 13:39, 13 June 2016 (UTC)

Constants as italic unit symbols

As a mathematician, I would note the expression, "0.99 c" implies multiplication by 0.99, and hence an amount preceeding the solar radius/mass constants "R☉" or "M☉" would not affect the italic font. That settles the issue as leaving constants in italic font when used as unit symbols, because the lead-in numeral can be viewed as the multiplier of the constant, as typical mathematical notation. -Wikid77 (talk) 02:30, 15 June 2016 (UTC)

Yes. For the measurement of a quantity SI explicitly states that it is an algebraic formula, we can perform maths with it. Just as x = y × z, we can handle v = 10 km/h. This also holds for some star  X, when we write: distance from sun = 1.2·1023 × R☉. Looks OK too when one defines the unit (or 'constant'): R☉ = 9.9598×1010 cm. The trouble is, the unit has the same symbol as the quantity (the lefthand side of the equasion). So we end up writing for star X: R☉ = 1.2·1034 × R☉. Now this is mathematically wrong.
What we need is that IUA defines the unit-symbol and the quantity-symbol. They can not be the same. -DePiep (talk) 09:36, 17 June 2016 (UTC)
"R☉ = 1.2·1034 × R☉. Now this is mathematically wrong."
As it should be. R☉ = 1 × R☉ is the only thing that makes sense. Likewise if you insist on a distinction between the variable and the unit because R☉ = 1 R☉ by definition. Just like c = 1 c. Headbomb {talk / contribs / physics / books} 22:19, 19 June 2016 (UTC)
You are missing the concept of quantity (by SI), but alas that does not matter in {convert} environment. -DePiep (talk) 01:53, 21 June 2016 (UTC)

Solar radiuses?

Latest comment: 8 years ago17 comments6 people in discussion
Copied from Module talk:Convert#Solar radiuses?. Johnuniq (talk) 00:38, 22 June 2016 (UTC)

Really? "solar radii" is almost universally used as the plural in any context where this is used as a unit. Also, is there any support for using this with the symbol? Using the words repeatedly can get a bit cumbersome. Lithopsian (talk) 21:08, 21 June 2016 (UTC)

@Lithopsian, Tarl N..
This is a recently added unit (see Astrophysical conversions above). We can immediately make the unit name whatever a discussion from the relevant wikiproject wants. I think I have seen MOS discussions suggesting that a plural like "octopuses" is generally preferred over "octopi", althought WP:ENGVAR would be involved. At any rate, I have no concern about what name is wanted.
When you say cumbersome, are you referring to writing the unit code ("solar radius") in the convert wikitext? Or, do you mean what is displayed to readers? If the former, if a wikiproject discussion can pick a suitable short name, that can be added as an alias. However, I would advise that it is probably better to write "solar radius" which is universally understood, rather than make up an obscure abbreviation, and it's too clumsy to write "R☉".
There is a discussion above regarding use of {{cvt}} where the consensus says that if you have a small number of converts to do, it is better to use convert for consistency, but if many abbr=on cases are required, cvt is a good alternative. Examples:
  • {{convert|2.5|solar radius}} → 2.5 solar radii (1,700,000 km)
  • {{convert|2.5|solar radius|abbr=on}} → 2.5 R☉ (1,700,000 km)
  • {{cvt|2.5|solar radius}} → 2.5 R☉ (1,700,000 km)
Johnuniq (talk) 00:38, 22 June 2016 (UTC)
I've used the template with abbr=on to get the symbol, but a lot of cases the existing text spells it out as solar radiuses (or radii). And I checked, according the dictionary, radiuses and radii are both acceptable plurals. Tarl N. (talk) 02:12, 22 June 2016 (UTC)
Ah. Seeing some of the reverts you did, I see what the issue is. The editor used radius repeatedly in the sentence. He probably should have said "has an estimated size of {{convert}} solar radiuses" or "has an estimated radius of {{convert}} R☉. Tarl N. (talk) 02:17, 22 June 2016 (UTC)
Going back as far as my oldest dictionary, a 3-volume "Webster's Third New International Dictionary", Merriam-Webster, I see: radius n, pl ra·dii also radiuses. A more modern dictionary I checked earlier listed them as both acceptable. Tarl N. (talk) 02:24, 22 June 2016 (UTC)
Thanks for the explanation on getting the unit symbol to show. On first use, I would generally use the words. Then with repeated used in the same article, indicate the symbol with the first use and then just use the symbol. Either plural form is quite long and not very accessible, so using it five times in a paragraph is "cumbersome". Having said that, I sometimes just use the symbol. The context is generally clear (eg. "the radius of star A is 100 R☉" and the symbol has already been introduced in the starbox, complete with wikilink.
In strict grammar terms, either plural form is correct, but in astronomical use solar radiuses is hardly ever seen. For example, see the IAU resolution defining the various units: [4]. Lithopsian (talk) 11:03, 22 June 2016 (UTC)
Understood, but please start a discussion at the wikiproject with a link to here. When someone over there agrees, we can change the plural. Another option would be to have radii by default, but show radiuses if sp=us is used. I have no idea if that is needed or whether it would be a legitimate US spelling, but the option is available if needed. Johnuniq (talk) 12:00, 22 June 2016 (UTC)

Octopuses vs octopi is completely different to radiuses vs radii. To use octopi is to show a degree of ignorance: this is just plain wrong. It's from the Greek not the Latin. The plural is octopodes ... unless you want to avoid seeming like a pedant, in which case, just use octopuses. Radii, on the other hand, is correct. This is from the Latin. Whereas octopodes may seem a bit pedantic, radii is pretty familiar to anyone with a decent high-school education. Note that the reason that so many erroneously use octopi is that the Latin ~us → ~i pluralisation is so familiar. It'd be unlikely for the etymologically correct Latin plural to surprise anyone here. The Anglicised form is more likely to be jarring (especially considering that articles which use the unit are more likely to be aimed at readers with a bit of education). I don't know why we need wait for the go-ahead from the Astroproject. Why not fix it now and change it later iff consensus is to do so? WP purports to be a serious encyclopædia after all. Anyhow, I've brought it up at WikiProject Astronomy. Excuse my scathingness but it seems a no-brainer to me. Jimp 03:03, 26 June 2016 (UTC)

It's radii, not radiuses. I've never seen radiuses used in any half-decent write up, and absolutely not in anything scientific or technical related, at any level from high school textbooks to technical instrumentation documentation to peer-reviewed papers. Headbomb {talk / contribs / physics / books} 19:25, 27 June 2016 (UTC)
Astronomy measurement issues appear quite often on this page. Why does the IAU not solve these? -DePiep (talk)
Pretty sure the IAU doesn't feel the need to issue edicts governing the use of proper English/Latin. Headbomb {talk / contribs / physics / books} 20:55, 27 June 2016 (UTC)
IAU should define the units and quantities they use properly. Both in symbol and in name. Talk:Convert then can link to a source. -DePiep (talk) 21:15, 27 June 2016 (UTC)
And they did. Headbomb {talk / contribs / physics / books} 21:21, 27 June 2016 (UTC)
... you're supposed to add the killing link here. -DePiep (talk) 21:24, 27 June 2016 (UTC)
The IAU resolution doesn't contain a statement to the effect of "the plural of radius is ...", but it does give the plurals of both mass and radius in the first paragraph, and then repeatedly throughout the document. Lithopsian (talk) 21:24, 27 June 2016 (UTC)

I think we can close the debate. It's pretty clear that the consensus is for radii. The template has been adjusted accordingly. Jimp 23:47, 27 June 2016 (UTC)

Thanks all, radii is good. Johnuniq (talk) 00:02, 28 June 2016 (UTC)

Precision not working

Latest comment: 8 years ago6 comments3 people in discussion

@Wikid77: pointed out a problem with this template: {{convert|105|-|106|F|C}} produces 105–106 °F (41–41 °C). You can argue the philosophy of that one way or the other, but certainly I'd expect {{convert|105|-|106|F|C|precision=1}} to produce something other than 105–106 °F (41–41 °C)*, which is what comes out. By comparison, the more arcane format of {{convert|105|-|106|F|C|1}} produces 105–106 °F (40.6–41.1 °C) properly.

I might be able to track down this bug (this module could use a lot more comments among the code...) but first I should really ask what the intended behavior here really is. Wnt (talk) 10:05, 30 June 2016 (UTC)

There is no precision parameter so precision=1 is ignored. I agree that using 1 as a numbered parameter is arcane but that is the way convert has worked for many years (since long before the module arrived in December 2013). Convert is used two million times in articles and lots of those have the plain 1 syntax, and there are probably well over 100 editors who are very familiar with basic convert syntax, including how to specify the precision. The point of that is that there is no realistic possibility of changing the situation now. In fact, adding precision=1 would just invite confusion and arguments over whose syntax preference should take priority in an article, and that's why I've never done it.
Re {{convert|105|-|106|F|C}}: There is a backstory to that. I took a long time (15 months) to develop the convert modules and in the last few months before it was ready I mentioned its progress several times on this talk page. I was particularly interested when people reported problems or minor inconsistencies in the old templates because I used the reported cases as tests for the module. To soften people up, I often mentioned that the module did not have the reported problem. The {{convert|105|-|106|F|C}} example was produced as a counter-example to show a defect in the module. I doubt if the problem arises much in practice because people usually are not interested in reporting a range as narrow as 105 to 106 degrees. However, it is a defect and fixing it is in my to do list, although with a low priority because no one has reported an actual problem. I don't think it warrants much concern. Johnuniq (talk) 10:45, 30 June 2016 (UTC)
@Johnuniq: Well, if there's no precision parameter, you should change this, because that's where I got the idea. Personally, I find the 105-106 example to be more of an illustration of the pitfalls of the significant figures idea, since it is not really more accurate than 94-95. My gut feeling actually is that a leading "1" in a number is not a significant figure at all, but alas, that's not what the popular usage is. Wnt (talk) 11:56, 30 June 2016 (UTC)
Come to think of it, because the documentation has said this a long time, I'd suggest making the "precision" parameter do something - if you don't want to implement it, just have it add an invisible category so some gnomes can track down any places people have attempted to make use of it. Wnt (talk) 11:59, 30 June 2016 (UTC)
Oooh. I should pay more attention to the docs. I downloaded the article dump from 2016-06-01 and have a list of all converts in articles at that time. It shows there were 175 converts using that broken syntax. There were 131 in November 2013 (the module started in December 2013). That sounds like a lot, but there are many hundreds of broken parameters in converts in articles, which is why the module does not enable parameter checking (warnings) by default. The reason for the large number of problems is that the original templates evolved over a long period and template syntax meant it was not feasible to check parameters. Thanks for pointing that out! I'll fix the docs in the next couple of days.
I configured {{cvt}} to enable warnings, and it shows a message (it's a big ugly red message when previewing the edit):
  • {{convert|105|-|106|F|C|precision=1}} → 105–106 °F (41–41 °C)*
  • {{cvt|105|-|106|F|C|precision=1}} → 105–106 °F (41–41 °C)[convert: invalid option]
Johnuniq (talk) 12:40, 30 June 2016 (UTC)
Removed the |precision= suggestion from the doc. It is by unnamed parameter. -DePiep (talk) 13:10, 30 June 2016 (UTC)

shouldn't abbr=on the default value?

Latest comment: 8 years ago72 comments13 people in discussion
For 6 years, the abbreviated {convert} has been {{cvt}} as "abbr=on". -Wikid77 (talk) 16:06, 19 May 2016 (UTC)
{{cvt}} is not consistent with {{convert}}. -DePiep (talk) 22:23, 24 May 2016 (UTC)

I have used the convert script frequently. I have observed that the default value is the long format is the default setting for the original value (e.g. 510 grams (1.12 lb)). At least here in Germany, nobody would write 510 grams, instead 510 g. Similar for length. So my question / proposal: Should abbr=on the default setting? At least for wights and lengths it would be the better solution from my point of view. --GodeNehler (talk) 06:23, 15 May 2016 (UTC)

I don't know the history, but I think there is a belief that many US readers may not grasp "g" but would recognize "gram". Also, young readers or people from various other places may be confused if the default were abbr=on. However, convert is just following WP:UNIT and the place to propose a change would be at its talk. I agree that repeating units like grams or kilometres is unhelpful. Johnuniq (talk) 07:21, 15 May 2016 (UTC)
Thank you Johnuniq for the link to the article WP:UNIT, I was not aware of it. It gives a nice background. For me, as german, it is really unusual to use the term kilogram as unit, we are always using kg. Same applies for meter and kilometer as unit. So conclusion for me: leave the Template:convert like it is; but I have to use the flag abbr=on more often. Thank you for your quick support. --GodeNehler (talk) 08:05, 15 May 2016 (UTC)
It would be nice if the template could somehow do abbr=off for the first use of a unit, then abbr=on thereafter. But I imagine this would be impossible. Kendall-K1 (talk) 02:06, 16 May 2016 (UTC)
Yes, unfortunately there is no way for a template like convert to find out what else is on a page. There is a theoretical way for a module to read all the wikitext on a page, but that would not be a viable procedure. Apparently it is part of MediaWiki's design that an isolated piece of wikitext should be able to evaluated without any need to know the context of where the wikitext is used. Johnuniq (talk) 03:22, 16 May 2016 (UTC)
I agree with GodeNehler, and am very tired of always having to type abbr=on. I feel that making the abbreviated version the default doesn't necessarily have to be in opposition to WP:UNIT, we could still use abbr=off for the first entry on a page. I would be happy to join such a conversation in the relevant place, if it's worth starting.  Mr.choppers | ✎  13:26, 16 May 2016 (UTC)
I don't understand why this is an issue. When I add conversions, it's usually from some obscure unit like "miles" to standard units, and in that case I want the obscure unit spelled out and the standard one abbreviated, which seems to be the default. Are you converting from standard to US? Why? Kendall-K1 (talk) 14:03, 16 May 2016 (UTC)
Many US readers (and they are the largest group of English speakers) don't appear to understand metric units. So it's just being helpful. Peter coxhead (talk) 15:55, 16 May 2016 (UTC)
Kendall-K1: I am writing e.g. articles about cameras and lenses. There the size and wight is written down. And the size are usually mentioned in metric system and American one (inches, feet, lb, oz...) for size of the lens / camera and closest focus distance. I am not sure if that is necessary at all, to mention non Metric units. I am from good old Europe (Germany), so I am not that sure if metric values are enough. But also other authors are using both units. Therefore I am using conversion, but it is crazy for my to see 1.9 kilogram instead of 1.9 kg as starting value, if I am writing about wight, also the first time. Thats the reason why I stated this request. The other question after reading WP:UNIT: What are well known values and what are not? Is feet, inches, meter and gram well known? At least for me yes. I have read also about stones (a wight of roughly 6 kg) during this research, which was total new to me. So well know has to be defined. Is metric well known? What read from Peter coxhead, not. --GodeNehler (talk) 16:03, 16 May 2016 (UTC)
When I work on scuba diving articles, I usually find that the units used throughout are either metres and bar (which you get on UK gauges), or feet and pounds-per-square-inch (which you get on US gauges). Most of the readers will use one habitually, but won't grasp the significance of the other units when reading an article. It's a kindness to go through the article and supply the 'translations' for depth and pressure to enable both sets of readers to understand easily what is written. It's worth noting that no scuba equipment that I've ever seen measures pressure in kiloPascals. Anyway, I won't consider this template complete until it can convert from "Cheese quarterpounder" to "Royale with cheese" https://www.youtube.com/watch?v=6Pkq_eBHXJ4&t=41s --RexxS (talk) 16:17, 16 May 2016 (UTC)
I usually only add conversions for articles with a strong US connection, but I can see how this would be helpful in other cases too. Would it make sense to display by default full names for non-SI units, and abbreviations for SI? Kendall-K1 (talk) 16:23, 16 May 2016 (UTC)
For me, this solution would be fine. --GodeNehler (talk) 16:52, 16 May 2016 (UTC)
For scuba-diving-related articles, the full name/abbreviation isn't important. A US diver will recognise 50 m as easily as 50 metres, but they won't have a sense of how scary deep it is unless you tell them it's 160 feet down. --RexxS (talk) 18:34, 16 May 2016 (UTC)
I write almost exclusively about cars, and hp/PS/kW are frequently in use. And no one ever spells those words out, unless it is to add particular emphasis.  Mr.choppers | ✎  00:52, 17 May 2016 (UTC)

Most articles probably should have the first "km" spelled out as "kilometre/kilometer", and subsequent occurrences simply shown as "km". There is no way to automate that, but per the above and as an experiment, I have updated the sandbox to default to abbr=on for SI units. Examples:

  • {{convert/sandbox|24|km}} → 24 kilometres (15 mi)
  • {{convert/sandbox|24|km|abbr=on}} → 24 km (15 mi)
  • {{convert/sandbox|24|km|abbr=off}} → 24 kilometres (15 miles)
  • {{convert/sandbox|24|km|abbr=in}} → 24 km (15 miles)
  • {{convert/sandbox|24|km|abbr=out}} → 24 kilometres (15 mi)
  • {{convert/sandbox|15|mi}} → 15 miles (24 km)
  • {{convert/sandbox|15|mi|abbr=on}} → 15 mi (24 km)
  • {{convert/sandbox|15|mi|abbr=off}} → 15 miles (24 kilometres)

We should not make a decision without involving MOS so if this is wanted, would someone please raise it for a discussion at MOS. Also, it would be good if people could look at typical articles and think about how this would work.

Another possibility would be to have a different template which is the same as convert except that it defaults to abbr=on. Perhaps "converta" or "convertabbr".

For reference, the SI units supported by convert are as follows. Convert does not support units like volt because there is nothing useful to convert them to. The Hz unit is weird, but was thoroughly discussed! The %s is where prefixes like "kilo" go, if not at the beginning. 

unit_code unit_type                  link                    symbol         name1           name1_us
Gy        Absorbed radiation dose    Gray (unit)             Gy             gray            --
rad       Absorbed radiation dose    Rad (unit)              rad            rad             --
a         Area                       Hectare#Are             a              are             --
m2        Area                       Square metre            m<sup>2</sup>  square %smetre  square %smeter
coulomb   Charge                     Coulomb                 C              coulomb         --
J         Energy                     Joule                   J              joule           --
eVpar     Energy per chemical amount Electronvolt            eV             electronvolt    --
Sv        Equivalent radiation dose  Sievert                 Sv             sievert         --
rem       Equivalent radiation dose  Roentgen equivalent man rem            rem             --
N         Force                      Newton (unit)           N              newton          --
m         Length                     Metre                   m              metre           meter
Hz        Length                     Hertz                   Hz             hertz           --
G         Magnetic field strength    Gauss (unit)            G              gauss           --
T         Magnetic field strength    Tesla (unit)            T              tesla           --
Oe        Magnetizing field          Oersted                 Oe             oersted         --
g         Mass                       Gram                    g              gram            --
W         Power                      Watt                    W              watt            --
Pa        Pressure                   Pascal (unit)           Pa             pascal          --
Bq        Radioactivity              Becquerel               Bq             becquerel       --
Ci        Radioactivity              Curie                   Ci             curie           --
K         Temperature                Kelvin                  K              kelvin          --
s         Time                       Second                  s              second          --
L         Volume                     Litre                   L              litre           liter
l         Volume                     Litre                   l              litre           liter
m3        Volume                     Cubic metre             m<sup>3</sup>  cubic %smetre   cubic %smeter

Johnuniq (talk) 01:07, 17 May 2016 (UTC)

For 6 years, short {convert} has been {{cvt}} as "abbr=on". -Wikid77 (talk) 16:06, 19 May 2016 (UTC)
  • I heartily approve your solution with default abbreviations for SI units. {{cvt}} does the job, we learn something every day… — JFG talk 12:59, 18 May 2016 (UTC)
    JFG. What group of people would this help? We already have enough people incorrectly using |abbr=on instead of |adj=on in prose when the MOS recommends against abbreviation (except in some cases such as, eg. tables). —Sladen (talk) 13:08, 18 May 2016 (UTC)
For example, people laboriously filling in specs in infoboxes... It would be interesting to see how often {{convert}} is called with abbr=on today vs abbr=off or no such option. Can some tool measure this in article space? If it's an overwhelming majority then we should proceed with the simplification, and a bot can fix the pages that need a syntax change. — JFG talk 13:20, 18 May 2016 (UTC)
Johnuniq, this is proposed change in behaviour which will lead to MOS non-compliance in tens-and-thousands of articles if deployed. If you want to have third state with variable behaviour please consider chosing a different option such as |abbr=auto or |abbr=onlysi, in preference to redefining the existing well-understood behaviour. —Sladen (talk) 13:13, 18 May 2016 (UTC)
  • This seems very bizarre to me. I would consider it just as strange to not see a measure spelled out as others here seem to find it strange to not see it abbreviated, but this is entirely secondary. My concern is about altering the default behaviour of a template that has existed for many years in this form, as changing the default will alter the formatting of a vast number of articles, and that just isn't cool. At the same time, though, I also admit that I'm not a fan of creating a different template like "converta", even if it's just a wrapper. I worry that it will eventually lead to some kind of divergence, but what do I know. — Huntster (t @ c) 15:34, 18 May 2016 (UTC)
That is why {{cvt}} now directly invokes the Lua script Module:Convert, to support all the same options with the exact same error-processing messages, and prevent any future divergence from {convert} features. -Wikid77 (talk) 16:29, 30 June 2016 (UTC)
  • Per my reply to the OP ("convert is just following WP:UNIT and the place to propose a change would be at its talk"), no change to convert will occur unless MOS agrees. I have not seen any mention at WT:DATE or WT:MOS so the current state is that the sandbox patch I mentioned above will be removed soon.

    I have seen many articles that are littered with things like "X is 5.4 kilometres (3.4 mi) from Y" and the "kilometres" quickly gets tedious for the reader, while adding abbr=on for every convert after the first is tedious for the editor. However, I agree that many readers would baulk at many SI symbols and am happy with the current state where the input unit defaults to use the name. Johnuniq (talk) 02:05, 19 May 2016 (UTC)

    Yes, it's probably overkill to impose abbreviations on all SI units. Maybe switching to default abbreviation for the most-widely recognized and widely-used unit pairs? km/mi, m/ft, cm/in, kg/lb would cover a lot. Again, is there a tool which could give us some usage stats of {{convert}} in articles broken down by units and options used? This would inform any discussion and potential decision at WP:UNIT. — JFG talk 08:42, 19 May 2016 (UTC)
    I extracted all convert templates from an enwiki all-articles dump in April 2015. It's old, but should be typical. I put some information in my sandbox (permalink). That shows 45% of converts use abbr, with almost all of those being abbr=on. The current Alps has 73 converts with abbr=on and 5 with no abbr. It is possible that some tweak for the common pairs like km/mi would be helpful, but as has been pointed out above, convert has been the way it is for years and changing that behavior would be a very big step. Johnuniq (talk) 11:52, 19 May 2016 (UTC)
Quite useful stats, thanks! Confirms that the top 10 converted units are as expected. Those stats are in article test only; how about usage in infoboxes? (I would assume that units are predominantly abbreviated there). Anyway, that's just curiosity, {{cvt}} is the way to go for quicker and more legible infobox editing – thanks GodeNehler for documenting it at {{convert}}. — JFG talk 01:54, 22 May 2016 (UTC)

Using {{cvt}} to have preset 'abbr=on'

For 6 years, {cvt} has been 'abbr=on': The abbreviated {convert} has been {{cvt}} as "abbr=on" since December 2010. Because the template name, "cvt" is an abbreviation for "convert" then the usage has been doubly effective, as used in numerous conversions per page, over the past 6 years, but removed from hundreds of pages by some editors. -Wikid77 (talk) 16:06, 19 May 2016 (UTC)

Shouldn't this be documented at the Template:convert page? Or other question: how can I know that {cvt} exist? I have now seen that Template:cvt exist, but how to know?--GodeNehler (talk) 17:32, 19 May 2016 (UTC)
Wow, never heard of this before, I'll start using it asap; that will be very handy in cluttered infoboxes. And yes, some prominent documentation at {{convert}} would be welcome. — JFG talk 01:47, 20 May 2016 (UTC)
{{cvt}} does not pass-through all other parameters consistently. It should do. -DePiep (talk) 22:23, 24 May 2016 (UTC)

If people really want {{cvt}} it could be replaced with an edit I just made to {{convert/sandboxlua2}} as a demonstration. It always sets abbr=on. I chose "on always" because people should be encouraged to use the familiar {{convert}} when wanting some variation, rather than confusing the issue with some articles using convert and some cvt. The template abbr options are documented here. Examples:

  • {{convert/sandboxlua2|12.3|km}} → 12.3 km (7.6 mi)
  • {{convert/sandboxlua2|1.2|x|2.4|m}} → 1.2 m × 2.4 m (3 ft 11 in × 7 ft 10 in)
  • {{convert/sandboxlua2|2|ft|6|in}} → 2 ft 6 in (0.76 m)

I included warnings=1 because if {{cvt}} is going to be used, it may as well be used correctly. Search Help:Convert messages for "if warnings have been enabled" to see conditions which will trigger a warning. Examples:

  • {{convert/sandboxlua2|21455|acre|ha|2.5}} → 21,455 acres (8,683 ha)[convert: invalid precision]
  • {{convert/sandboxlua2|12.31|m|ftin|frac=on}} → 12.31 m (40 ft 5 in)[convert: invalid fraction]
  • {{convert/sandboxlua2|123|m|ft|sort=on}} → 123 m (404 ft)[convert: invalid option]
  • {{convert/sandboxlua2|123|m|ft|sp=}} → 123 m (404 ft) (an empty parameter such as sp= does not give a warning)

Johnuniq (talk) 23:18, 24 May 2016 (UTC)

Johnuniq, if you see no other objections than the 'support/discourage {{cvt}} usage' you point to, I suggest to conclude that this {{cvt}} change is OK for going live (and better than current parsed code). I'd leave it up to you for the exact code switchover action, possibly related to the main update you planned for {{convert}}. -DePiep (talk) 11:49, 31 May 2016 (UTC)
I'm conflicted about extra templates for two reasons. First, they make maintenance a bit harder—I'm thinking mainly of, for example, fixing all the converts that may be used in a particular article which would be a bit more effort if some use "convert" and some use "cvt". Second, it's a bit weird for casual editors who are familiar with "convert" to be confronted with "cvt"—that would raise a bunch of questions for most editors. However, I don't object to cvt and people can try it if wanted. If it is used, it should be changed to directly invoke the module, as above. That could be done now if you want to try it (and check a couple of places where it is used to see it really does work!). Or later. Johnuniq (talk) 12:29, 31 May 2016 (UTC)
Currently, {cvt} for 6 years has allowed option "abbr=in" or such, rather than force "abbr=on" always. I have added option "spell=" which works when null. Long term, a {cvt} template which invokes the Module:Convert directly would be nice, but needs to allow "abbr=in" or such. -Wikid77 (talk) 22:35, 1 June 2016 (UTC)
As an alternative to abbr=on always, it would be possible to use abbr=on default. However, doing that worries me because it may encourage people who work with convert a lot to start using cvt instead, and that would just cause unnecessary confusion for other editors. I like shortcuts when they have a significant saving (say {{pb}} instead of the ugly {{paragraph break}}), but there is no practical difference between {{cvt}} and {{convert}} except the former nicely shows that it is for abbr=on. If people want to use cvt, let's make convert redirect to it. Otherwise, I'm inclined to think cvt should be reserved strictly for the cases when abbr=on is wanted. If people want abbr=in they can use convert. Johnuniq (talk) 02:02, 2 June 2016 (UTC)
The one and main reason to allow {{cvt}} is to simplify the default abbr setting because, per style guide, after a wordly unit introduction abbr is used for the rest of the article: way way more often. Apart from that default setting, {{cvt}} should follow {{Convert}} exactly, from documentation into behaviour (if not, that would be a burden for editors). There is no similar need for any other convert-parameter AFAIK. And when, in any future, {{cvt}} would hinder or block development, a bot action etc. can adjust usages. All in all, I see no obstacles for our editors. -DePiep (talk) 09:24, 2 June 2016 (UTC)

Here are some simulated examples using fixed wikitext for the output. We agree that the purpose of cvt is to do the following (abbr=on):

  • {{cvt|12|km}} → 12 km (7.5 mi)

The question concerns whether cvt should allow the following:

  • {{cvt|12|km|abbr=off}} → 12 kilometres (7.5 miles)
  • {{cvt|12|km|abbr=in}} → 12 km (7.5 miles)
  • {{cvt|12|km|abbr=out}} → 12 kilometres (7.5 mi)

My point is that if cvt allows the above, some editors will use cvt almost all the time because cvt could do anything that convert can do—the only difference would be that cvt defaults to abbr=on and convert defaults to abbr=out. My concern is that casual users of convert will then be unnecessarily confused—should they use cvt or convert? what is the difference? which is better?

My preference would be that we either change the default abbr in convert so cvt is not needed, or that cfg be configured so abbr=on always applies, so people have to use convert when a different abbr is needed. I don't feel strongly about it, but I think it may be better to have a discussion in a new section regarding a fairly important change in behavior. Johnuniq (talk) 10:01, 2 June 2016 (UTC)

I'm not sure what else is to be discussed, John, and for archival purposes I'd say that one section is preferable. Anyway, I agree that {cvt} would be a useful alias for {convert|abbr=on} in infoboxes and tables, but I see no reason whatsoever for having a template duplicating all of {convert}'s options for |abbr= with only the difference in default value for |abbr= to distinguish between them. Editors could get used to using {cvt} as a shorthand for {convert|abbr=on} (the mnemonic makes sense), but extending its use beyond that is a recipe for confusion. --RexxS (talk) 12:16, 2 June 2016 (UTC)
RexxS describes my point: we only need the {convert|abbr=on} variant; the rest looks like time waste. This too: ;-) Johnuniq, your note to make |abbr=on to be the default in {{convert}} would be great - back in 2005. But today, we simply can not change the default behaviour in a 750K-transc template. Maybe in the longer future a superbot can handle such a change.
Also. I do not get the need for |abbr=on always route. The situation clearly requires a second Lua module to fixate a parameter (ie, we can not call [module:convert] with preset abbr=on in some calling template -- we must have a 2nd Lua module doing this). This together would be the {convert/sandboxlua2} demo code (in {{cvt}}), nearly the the code John so reluctantly & greatly provided :-). -DePiep (talk) 22:40, 2 June 2016 (UTC)
There is no need for another module or any change to the current module. See the {{convert/sandboxlua2|21455|acre|ha|2.5}} example above and look at the wikitext in {{convert/sandboxlua2}}, and see its documentation. Johnuniq (talk) 00:46, 3 June 2016 (UTC)
Not sure if this has already been mentioned, but one potential fix for this problem would be to run a bot that changes all the converts that have abbr=on over to cvts, and vice versa. That way people will learn to automatically do the right thing when they copy markup and make changes, or the bot will fix it for them.GliderMaven (talk) 23:29, 8 June 2016 (UTC)
  •   Done: {{cvt}} now uses module:convert as demo'ed by Johnuniq. Documentation adjusted (to rely on {convert}/doc mainly). Don't see any need for the bot-action GliderMaven mentions. -DePiep (talk) 08:14, 9 June 2016 (UTC)
    Thanks. I agree that no bot action is needed, and in fact I would encourage people to stick to {convert} for general use (even with abbr=on), and only use {cvt} when needing several abbr=on. That would generate less confusion for other editors. Johnuniq (talk) 10:31, 9 June 2016 (UTC)
Thanks for you ;-). This {cvt} diversion is acceptable because its usage is potentially very huge (more abbr than names in an article). And confusion problem is minor: /doc is the same, systematically. So, IMO, this can stand a TfD. -DePiep (talk) 00:00, 10 June 2016 (UTC)

Template:Cvt abbr=in broken by Lua version

This section moved here as subtopic, to maintain talkpage flow in this topic.
-DePiep (talk) 06:51, 22 June 2016 (UTC)

When Template:Cvt was changed to use #invoke of Lua Module:Convert, then the option "abbr=in" was broken, as an ignored option. For 3 updates, I had fixed {cvt} to handle the option "abbr=in" but it has been re-broken 3 times.

{{convert|3|mi|km|abbr=in}} gives: 3 mi (4.8 kilometres).
{{cvt|3|mi|km|abbr=in}}      gives: 3 mi (4.8 km).
{{cvt|3|mi|km|abbr=nope}}  gives: 3 mi (4.8 km)[convert: invalid option].

Because the Lua script interface ignores the parameter "abbr=in" then the user receives no warning about the option and has no indication for rejected parameter settings. Consider option "abbr=values" as below:

{{convert|6|mi|km|abbr=values}} gives: 6 (9.7).
{{cvt|6|mi|km|abbr=values}}      gives: 6 (9.7).

The arbitrary omission, or refusal, of option "abbr=in" has no basis in reality, and so if there are no further objections, then I will refix {cvt} to handle option "abbr=in" after 48 hours of consideration. Thanks. -Wikid77 (talk) 03:02, 15 June 2016 (UTC)

There was a cvt discussion above but I agree that starting again in a new section is more likely to attract attention. On a technical matter, the module has some tricks for dealing with abbr—the options are documented here. That means there is no need for a wrapper template to do anything other than invoke the module with the wanted option. The question to be decided is what {{cvt}} should do. That involves the issue of what templates should be encouraged in articles. I do not think people should base editing decisions on the number of characters saved in the wikitext. Consider these equivalent alternatives:
  • {{convert|12.3|km|abbr=on}} → 12.3 km (7.6 mi)
  • {{cvt|12.3|km}} → 12.3 km (7.6 mi)
Both are fine, but the first is extremely familiar to people interested in these matters, while the second would raise questions in many minds—what is cvt? which of convert and cvt "should" be used? If an article has a few converts, I recommend using the obvious and longer version with convert. It's only when an article has a dozen abbr=on converts that it makes sense to use cvt.
However, the reason this is being discussed is because of a recently reverted edit at {{cvt}}. The proposed edit allows people to always use cvt because the following would be equivalent:
  • {{convert|12.3|km}}
  • {{cvt|12.3|km|abbr=out}}
The first question to be decided is whether cvt should always use abbr=on, or whether that should merely be the default which could be overridden, for example with abbr=out. That would allow convert to be replaced with cvt. Any views on that? Johnuniq (talk) 03:57, 15 June 2016 (UTC)
  • First question is why reject abbr=in after 6 years: There is no logical reason to reject option "abbr=in" which has been allowed since 2010. In fact, because Template:Cvt alters the standard abbreviation, then further abbreviation options should be expected as an extended view about abbreviating unit names. We have noticed first-time users of a template mainly prefer the default options, and that is why {convert} defaults to "abbr=out" as matching the wp:MOS style for unit names; however many editors have forced {convert|abbr=on} for all conversions on a page, and hence limiting {cvt} options will not ensure compliance with MOS, but especially rejecting {cvt|abbr=out} would prevent matching the wp:MOS style where users wanted {cvt} as the template for all entries in a list or table. As for length of wikitext, for dyslexic users the name {convert}" could become "{covnert}" while "cvt" provides fewer misspellings (or clearer tables). By comparison "&nbsp" is often "&nsbp" and long cite parameter "accessdate=" (10 letters) is the most-misspelled option in wp:CS1 templates, while users have requested a shorter name (such as "acdate="). Also "accessdate" is most likely to omit bar "|" and so length of wikitext has proven crucial for usage. Plus years of intense study led to creation of {cvt} back in 2010, and now option "abbr=" should be fully restored. -Wikid77 (talk) 12:47, 15 June 2016 (UTC)
"First question ...": the answer lies in that for the last four years of these you have been ignoring each and every reason wrt the improvement of {convert}. The development has been explained to you dozens of times, and still you claim 'no logic'. So this time I won't add another one, especially since you did not think of making it an open, inviting question. -DePiep (talk) 20:02, 15 June 2016 (UTC)
  • We should be using one template to provide one function. That is the simplest way to avoid confusion and to flatten the learning curve for beginners. We have a perfectly good {convert} template that does all the jobs required by making use of different parameters. If there is a commonly used alternative to a default parameter value (as there is in the case of |abbr=on), then the argument can be made for a shorthand alias, that experienced editors may wish to make use of, and I believe {cvt} can perform that function with relatively few problems. I object strenuously to attempts to turn {cvt} into a virtual duplicate of {convert}, because that is simply a recipe for confusion, and there is no need for it. The template {cvt} should never implement any of the |abbr= options, because we already have {convert} to do that job. --RexxS (talk) 15:10, 15 June 2016 (UTC)
There is no "attempts to turn {cvt} into a virtual duplicate of {convert}", it always was. And yes, one function <==> one template is the best principle, but there are exceptions (you already point to one; however, I'd expect a true shorthand only to be acceptable off-content space). One exception is at hand here, as argued in the earlier section here. This thread is opened to the topic: given the actual {cvt} setup, which {{para|abbr} options should be enforced/disallowed/fixed? -DePiep (talk) 20:02, 15 June 2016 (UTC)
@DePiep: At present, {cvt} does not implement |abbr= because it is being used solely (and properly) as an alias for {convert|abbr=on}. So no, you're wrong to claim "it always was" a virtual duplicate of {convert}, as it's patently obvious that it's not at present, and has not been so for some time. This whole thread is the attempt to turn it into an unnecessary duplicate and I'm objecting to it. Do you have any thoughts on the question? P.S. the section you referred to is #Using cvt to have preset abbr=on. --RexxS (talk) 20:40, 15 June 2016 (UTC)
{cvt} did and does implement an |abbr= setting, so there is no "turning into" change. {cvt} always did (aim to to) implement the other options of (convert), even and especially before {convert} was Lua-fied in 2013. As for the "this whole thread" - yes, and that's not a secret. But it is not about turning {cvt} into a redirect. -DePiep (talk) 21:11, 15 June 2016 (UTC)
It depends what version of {{cvt}} is being talking about. Two possibilities are relevant (documentation here):
  1. {{#invoke:convert|convert|abbr=on always}}
  2. {{#invoke:convert|convert|abbr=on default}}
At the moment cvt is #1 which means that any abbr setting entered by an editor is ignored. That is what I think should happen, and is what RexxS is talking about. Using #1, an editor knows that "cvt" means "convert with abbr=on", and cvt is an excellent mnemonic for that.
If #2 were used, an editor could use cvt with any abbr setting, and that would allow them to always use cvt and ignore convert. RexxS has explained the problem with that—confusion. Johnuniq (talk) 01:39, 16 June 2016 (UTC)
Here I've put up testcases for all |abbr= options. Johnuniq, am I right that the options =~, =values do act unexpected in {cvt}? -DePiep (talk) 20:15, 21 June 2016 (UTC)
Perhaps I'm missing something, but I don't see them as unexpected. There are several miscellaneous abbr settings and they work exactly the same way in convert and cvt except for those which select whether to use a unit symbol or name (abbr=out/in/on/off). With the current settings in {{cvt}}, units always use the symbol (that is, they are abbreviated). The reason abbr=foo shows an error in cvt is that I put warnings=1 in its template, but I have not done that for convert because there are still too many converts with broken options. Johnuniq (talk) 00:22, 22 June 2016 (UTC)
I get it, it is even more sophisticated. -DePiep (talk) 06:44, 22 June 2016 (UTC)

Cvt with abbr=values is working but not abbr=in: As shown above, {{cvt|6|mi|km|abbr=values}} gives: 6 (9.7), but {{cvt|6|mi|km|abbr=in}} gives: 6 mi (9.7 km) with output "km" not "kilometres". I think any "abbr=" should work again as it has for 6 years, so set {cvt} as "abbr=on default". Remember in a table, users might want all "{cvt}" with any options. Thanks. -Wikid77 (talk) 23:03, 16 June 2016 (UTC)

This is a bug report, right? IMO, nu firealarm needed. I'm sure Johnuniq is looking after this.
re "as it has for 6 years" - that is not an argument, Wikid. It ignores the evolution of {convert}, and would block any improvement. We need consistent template behavior, end of story. I think the question now is: should option 1 or 2 be applied? I myself have no strong opinion. Maybe Rexxs can expand on the interpretation Johnq made? To me, RexxSs' opening line can mean something different. -DePiep (talk) 08:46, 17 June 2016 (UTC)
Apologies for my lack of clarity. My intention was to explain why I support the position where {convert} should be the sole template that is used to provide all convert functions (in almost all cases). First of all, I think the value of having a single, well-known name for the template outweighs considerations of saving space in the wiki-text, so I'm not persuaded by arguments about making a shorter alternative name available for such circumstances. However, in my experience, the option |abbr=on represents a sizeable proportion of the uses, and therefore I'm wiling to entertain the view that we should have an alias which was shorthand for {convert|abbr=on}. For that purpose {cvt} is a very apt mnemonic, as Johnuniq says.
I did believe that was the current situation, where {cvt} always works as if the |abbr= parameter were set to "on", but it seems that |abbr=values is accepted, even though {{cvt|10|mi|km|abbr=off}} -> 10 mi (16 km) ignores the |abbr=off as I expected it to - and in the same way it ignores other values for abbr. My preference would be for {cvt} to ignore all supplied values for abbr and set them to "on". Does that make my view any clearer? --RexxS (talk) 13:54, 17 June 2016 (UTC)

Well, an error message would be needed to remind users if we intend for {cvt} to ignore all supplied values for abbr, plus there should be a logical reason to ignore "abbr=in" as used for 6 years, beyond wp:IDONTLIKEIT, such as problems in evidence seen over the prior 6 years but I haven't found any complaints such as, "Oh no, {cvt} allowed 'abbr=in' and there were immediately riots in the streets" (not). Hence, there has been no major reason to reject "abbr=in" and so I will restore the option in {cvt}. Thanks for all the comnents during the past 7 days. -Wikid77 (talk) 10:55, 21 June 2016 (UTC)

The problems caused to inexperienced editors of having two different templates performing almost identical functions have been made clear to you. Just because those editors don't beat down your door complaining doesn't mean that the problem doesn't exist. As you have brought forward no good reason to turn {cvt} into a duplicate of {convert} other than ILIKEITTHATWAY, I'll be reverting your disruptive edits that don't have any consensus here. --RexxS (talk) 11:29, 21 June 2016 (UTC)
My conclusions.
  1. This subsecions header ('Cvt broken') is incorrect: it is a feature not a bug.
  2. Johnuniq has clearly described the options involved @ 01:39, and the option currently implemented (|abbr=on always).
  3. In a previous thread, RexxS clearly explained their preference for this option [5] (I missed this one earlier on, because threads on topic were separated). IMO, in that thread, consensus was established.
  4. Apart from this single explicit feature, for any editor template {cvt} should look, feel and behave exactly as {convert}. For example, documentation should be the same. I note that an other arrangement (any dilation between the two templates) could create an argument for {cvt} TfDeletion.
  5. I have found no strong arguments against the current setup. I support it. -DePiep (talk) 07:16, 22 June 2016 (UTC)

Questionable edits by an editor

IMO (I am involved): Over at Template:Cvt/doc, Wikid77 pushes [6] and re-pushes [7] a soapboxing. It does not help the doc-reading editor, and it is a prolonguement of the arguments we can read on this page (where they belong).
What to do? This behaviour is taking so much energy, time and time again, from other editors. Could it be considered (imo, again) vandalism, and eligible for a topic ban? -DePiep (talk) 21:35, 28 June 2016 (UTC)
@DePiep, I don't think your continual removal of doc-text sections could be considered "vandalism" but is taking so much energy, time and time again, and it is a severe type of wp:Blanking, and you need to discuss proposed removal of doc-text first, especially in a template used for 6 years, as otherwise you are effectively edit-warring to force your style of doc-text with little explanation of template operation, purpose or background. Beware turning a list of template parameters into a long tutorial of usage, rather than a concise summary of parameters as shown in many other templates. -Wikid77 (talk) 08:07, 29 June 2016 (UTC)
I got no dog in this fight, but Wikid77 (talk · contribs) should knock it off with the soapboxing. This is a documentation page, not a space for essays about some anti-cvt cabal. The documentation page should exclusively be used to document the template's purpose and how to use it, and nothing else. I've reverted the rant, and Wikid77 should be aware than continued disruption like that will very likely end up at ANI or some other drama board. Part of Wikid77's edit may be salvageable in the sense that some of this might warrant being on the documentation (and this can be debated on the template's talk page to established consensus on what the doc should say about cvt's purpose), but the spiel about people systematically removing {{cvt}} to 'thwart' its use and 'frustrate' users is grossly inappropriate. Headbomb {talk / contribs / physics / books} 22:01, 28 June 2016 (UTC)
@Headbomb: You've got to be kidding; that Template:Cvt was created in 2010, and just look at the usage history, of widespread use and then intense removal. The template has been and still is being systematically removed from pages. Check the edit-logs, and meanwhile, I strongly suggest you knock off the insulting, judgmental crap about "essays about some anti-cvt cabal" (WTF?). Are such remarks seriously the way you respond to long-term editors of my caliber, as in what the hell is wrong with you by taking that tone of voice. Please get the facts soon, and then I expect a public apology here and soon. Thanks in advance. -Wikid77 (talk) 00:13, 29 June 2016 (UTC)
Check your ego at the door. You wrote, and I quote, "some people have been systematically removing the use of {cvt} to thwart its use and frustrate the users who want conversions to be less-wordy in pages". THAT is, to use your words, "judgemental crap", accusing people who cleanup articles of less-than-noble intentions (see WP:BADFAITH), and as "Most Plusquamperfect Looshpah Laureate" myself, I give absolutely zero special shits about 'long term editors of your caliber'. You are no more special than DePiep, myself, or IP 134.2.34.324, and bound to follow WP:CIVIL and WP:GOODFAITH just like everyone else, and as 'a long term editor of your caliber', you ought to know that tendentious editing is very, very, not welcomed around these parts.
Now, discuss the issues on the talk page and gain consensus before re-adding this on the doc, or face a block for edit-warring. Headbomb {talk / contribs / physics / books} 01:25, 29 June 2016 (UTC)

Is cvt preferred over convert?

Latest comment: 8 years ago16 comments8 people in discussion

I was not aware that "{cvt} should be in use more than 2x the number of {convert} template calls". Frietjes (talk) 00:52, 29 June 2016 (UTC)

This has been discussed above, in Template talk:Convert#Questionable edits by an editor. Kendall-K1 (talk) 02:16, 29 June 2016 (UTC) [fixed broken header-link. -Wikid77 (talk) 16:47, 30 June 2016 (UTC)]
I don't consider DePiep's edits to be vandalism, those are just removing features or doc-page explanations without consensus. -Wikid77 (talk)
  • In fact, an analysis of parameter usage for Template:Convert will clearly show extensive usage of option "abbr=on" which is automatically set by using the shorter Template:Cvt, hence {cvt} should be used to shorten abbreviated conversions (roughly 2x more), and so {cvt} was changed to directly invoke the Lua script Module:Convert just as fast as {convert} (with same error-checking), but the Lua #invoke broke options "abbr=in" or "abbr=out" and my various attempts to fix the broken "abbr=" feature were reverted as the beginnings of an edit-war to force nonconsensus limits to {cvt}'s prior full use of "abbr=" options during the past 6 years. Anyway, {cvt} should quickly become used 2x as much as {convert} due to numerous short infobox conversions.-Wikid77 (talk) 07:03, 29 June 2016 (UTC)
That makes no sense. The code used to invoke a behaviour is irrelevant to the outcome, so no, Cvt should not "quickly" become used twice as often. If people want to use Cvt as a shortcut in new conversion instances, that shouldn't be an issue. I personally think it is pointless, and I disagree with forking templates to perform the exact same function, but until there is broad consensus to go one way or another there should be no forced use of one template over the other, nor should there be any replacement of one over the other. (I do wonder if some kind of RfD should be raised to settle this issue.) I will say, however, that you Wikid77 appear to be deeply and overly invested in Cvt, to the point of falling into ownership issues regarding protecting the expansion of its use. — Huntster (t @ c) 08:20, 29 June 2016 (UTC)

Welcome, Huntster, to the discussion of 6 years of using {cvt}. If I seem "overly invested" in Cvt, then please understand that I created {cvt} 6 years ago, and people were quite surprised that it had existed, which answered their recent requests for a {convert} default as "abbr=on" which they wanted several times per page, now just as 6 years prior. This was all explained previously in May under thread "#shouldn't abbr=on the default value?" with such enthusiastic support for {cvt}, that those users even updated Template:Convert/doc to mention {cvt} several times in the doc-text. As I have been handling these issues for the past 6 years, then perhaps that clarifies why I seem "deeply" into Cvt: I created it 6 years ago, and many have just recently been enthusiastic about using it now. They also wondered why they had not seen {cvt} in all those pages where it would have been so very useful for years, and hence I have been busy here to catch up for a broad 6 years of this (how much broader consensus is needed?).
Also note, {cvt} is just one alternative to {convert}, as there is also template {{height}} with slightly different options for using Convert for height of a person, or template {{Hands}} for horse/pony measurements with automatic fractions of equine standards, and template {{inflation}} to handle money as a separate conversion, plus {{INR}} to convert the Indian rupee for inflation (etc.). Anyway, I appreciate the interest after all these years, so any other questions about these issues, while I am here? -Wikid77 (talk) 13:58, 29 June 2016 (UTC)

You'll have much better luck if you can dial back the attitude and be more concise. We have what I would consider two issues. One is that cvt is currently broken because of what seems to be a bug in the module; is that correct? The other is that you think everyone should use cvt instead of convert, and you're pushing that agenda on the doc page, which seems unacceptable to me. Policies and guidelines are arrived at by the usual consensus process. Kendall-K1 (talk) 14:50, 29 June 2016 (UTC)
@Kendall-K1: the concise answers are, Yes, then No. Yes, {cvt} option "abbr=in" was broken purposely (not a bug) in Lua module, and people can use {convert} but the {cvt}'s in infoboxes would average 2x more (unless some editors systematically remove {cvt} as during prior years). WP:MOS would allow {cvt} everywhere in tables. -Wikid77 (talk) 19:45, 29 June 2016 (UTC)
See also the discussion at Template talk:Cvt. Peter coxhead (talk) 16:00, 29 June 2016 (UTC)
@Wikid77: The question you haven't answered is why we would want a template that duplicates another template? The answer, which you seem unable to grasp, is that by default we don't. The reason is simple: people learn new techniques more quickly when presented with consistent examples. In the case of {convert}, that's what editors should be seeing. Where a specialised conversion like {{hands|14.2}} (-> 14.2 hands (58 inches, 147 cm)) has existed in the past to fill a niche, then it may still be with us for historical reasons (374 transclusions), but for consistency we should be using {{convert|14.2|hands}} (-> 14.2 hands (58 inches; 147 cm)). In the case of {cvt}, you might have thought it was a good idea 6 years ago to use it interchangeably with {convert} to save a few characters, but this is 2016, not 2010, and your lonely position has been rejected in the discussions above. The only place for {cvt | ...} is as shorthand for {convert |abbr=on | ...}, which is common enough in tables, etc. for it to be worth keeping. The current version of {{cvt}} performs that function and there is no need to change it. --RexxS (talk) 16:11, 29 June 2016 (UTC)

No. In a word, to answer the question posted, no, {{cvt}} is not preferred over {{convert}} nor should it be, or, to put it more clearly, it is preferred by someone in some circumstances but generally no. I'm reminded of the good old days ... or shall I say not-so-good old days ... when there were a plethora of little templates each having their little scope, doing their little jobs (one for centimetres to inches, one for pounds to kilograms, etc.). This was about ten years or so ago when {{convert}} was a wee bairn. The new {{convert}} promised to simplify things but, as it used a #switch, it was limited with respect to how many units it could deal with. In those days, we had proposals for a {{convertW}} for weights and a {{convertV}} for volumes. This would have allowed some consolidation but it would still have been limited and lead to several disparate templates. Luckily, we found a way to rewrite {{convert}} such that these forks were not necessary. The project was so successful that all those little templates were absorbed into {{convert}} ... all but one, viz {{height}}, which it would have gone the way of its cousin, {{weight}}, but for the fact that {{convert}} didn't do fractions until recently (maybe too late ... no, not too late to kill {{height}} ... yes, it should die ... {{hands}}, {{INRConvert}} and {{bbl to t}} are totally different).

Yet, it might seem that now we face the prospect of {{convert}}'s splintering back up again. For what, so that someone might save a few keystrokes? Is that supposed to make things simpler? Let's look at it from the perspective of an editor who happens not to be in the know, i.e. almost everyone. Newbies, they're going to look at it and wonder what the fork {{cvt}} is. No, it doesn't make the code simpler. {{Cvt}} will be an arcane mystery to just about everyone. Fewer keystrokes is not the great boon that the proponent of {{cvt}} would have us think. Sorry, but it's just not. It was suggested that "In reality, {cvt} should be in use more than 2x the number of {convert} template calls, but some people have been systematically removing the use of {cvt} which effectively thwarts its use by users who want conversions to be less-wordy in pages. Over the past 5 years, {cvt} has been used hundreds of times and should be used in more than 500,000 articles.". Wordiness is not the problem. If abbr=off is in fact better, change {{convert}}, don't fork it. It should be systematically removed, knock it off with AWB or a bot. {{Cvt}} is unhelpful. It makes the code so much less transparent. Though {{convert| ... |abbr=on}} is more wordy, it's easier for the average editor to comprehend and therefore simpler in spite of its greater wordiness.

Half a million, {{cvt}} is used less than three score half dozen times. The great enthusiasm for {{cvt}} by all the swarms of supporters it a total overstatement, you'll be lucky to find a handful of people who even know that {{cvt}} even exists much less who'd think to use it. The number of keystrokes saved by {{cvt}} is miniscule in comparison to the number wasted arguing about it. WP:T3 says "Templates that are substantial duplications of another template, or hardcoded instances of another template where the same functionality could be provided by that other template, may be deleted after being tagged for seven days.". {{Cvt}} is exactly this. It aught speedily to go. Wikid, you've made a lot of great contributions but this ain't one of them. Brevity isn't necessarily better. Transparency trumps brevity. Why have two templates when one will do?

PS By the way, {{cvt}} it totally useless in most tables, where you just want numbers (without units) in separate columns. This is what disp=table is for.

PPS abbr=off, abbr=out, abbr=on and abbr=on are not broken. Jimp 17:57, 29 June 2016 (UTC)

Use of {cvt} is great in tables, as {cvt|disp=table} or {cvt|abbr=values} still works to put km/miles in same column as "16 (10)". However, option "abbr=off" formerly worked, but broken on 9 June 2016, as {cvt|16|km|abbr=off} gives: 16 km (9.9 mi), to force "km" by Lua setting. -Wikid77 (talk) 19:45, 29 June 2016 (UTC)
Right, I see. {{Cvt|...|abbr=off}} is broken. {{Convert|...|abbr=off}} is fine. So, if {{cvt}} is broken, all the more reason to delete it.
abbr=values is a misuse of abbr, this should be done by disp, just one of the many misuses of parameters.
{{Cvt|...|disp=table}} and {{cvt|...|abbr=values}} do the exact some thing as {{convert|...|disp=table}} and {{convert|...|abbr=values}}. That is what I call totally useless.
I'm sorry, Wikid, but it truly baffles me as to why you don't see that having two almost identical templates floating around makes the source code that much more difficult to understand for the typical user that it just isn't worth the very few keystrokes saved. Jimp 00:38, 30 June 2016 (UTC)
It's not just Wikid77 that wants {{cvt}}; I find it very useful too. Template code clutters up wikitext, making it harder to see the important information that editors need to work on – in this case the numbers. It's easier to read {{cvt|7|cm}} than {{convert|7|cm|abbr=on}} as well as to type it. Peter coxhead (talk) 08:59, 30 June 2016 (UTC)
re Jimp "Right, I see. {{Cvt|...|abbr=off}} is broken." -- No, that is a feature by design and by consensus. Please stop repeating that misinformation. The feature was explained, discussed, and concluded as consensus here. (And of course, if it were it 'broken' (quod non), that is no reason for TfD, it is a reason to fix it).
Given the consensus for the {{cvt}} setup & behaviour, you can try to build consensus for a different feature. However, I have not read a single, coherent proposal on this page. And jumping on the Wikid disruption bandwagen (raising controverse in each an every way & opportunity) to force a change, any change, without consensus or with misconstrued arguments is not a proper procedure. -DePiep (talk) 09:43, 30 June 2016 (UTC)
@DePiep: sorry but Jimp is correct about {cvt} with "abbr=off" being broken (not a "feature"), and there was NO consensus to keep similar option "abbr=in" ignored because even a 3-2 !vote does not make consensus, plus consensus is based on logical principles, and prohibiting "abbr=off" because wp:IDONTLIKEIT does not override the long-term consensus of 6 years for "{cvt|abbr=off|..}" working as expected. Please try to find a logical reason for {cvt} to prohibit "abbr=in" (as actual cases which cause extreme problems by allowing "abbr=in" as a {cvt} option). Instead, I have noted the situation of a wikitable containing all {cvt} where a few cases could include "abbr=in". Fortunately, we have 6 years of past experience using {cvt}, and there have been no complaints of extreme problems caused by {cvt} allowing "abbr=in" during those 6 years. -Wikid77 (talk) 15:30, 30 June 2016 (UTC)

Cvt is 5x-7x shorter and easy to remember

The major benefit for using {cvt} is the ease of entry, even in wp:VisualEditor (VE), by automatic setting of "abbr=on" as no need to enter an option "|abbr=" in the wikitext or VE. As a length of text, note how "cvt" is 5x times shorter than "convert|abbr=on" (15 characters) but even better than 7x faster for entry on mobile devices with multi-mode keyboards where the bar "|" and equals-sign "=" are keyed by re-switching between A-Z letter-mode keyboard (~20 keystrokes). Meanwhile, the original {convert} provides automatic match to the recommended style in wp:MOS, where the first mention of a measurement unit should be as full unit name ("kilograms"), rather than as unit symbol ("kg"), unless lists of units in a table.

The general principle of using shortcut names in computer technology is the concept of "macro programming" where the simplest form is to assign function keys on a keyboard to enter a string of text for one keystroke. However, decades of research has shown that users can easily remember shortcut names (such as "cvt") much quicker than the equivalent punctuation of options (such as remembering incorrectly as "abbr=yes" or "abbrev=on" rather than actual "abbr=on") plus avoids invalid punctuation (such as "convert/abbr:on") especially if other frequent templates have alternate punctuation. In practice, new words should be limited to 5-9 in short-term use; however, for a list of names, then 20 shortcuts would be manageable for many people, but expert users could be expected to remember over 100 template names in common usage. For decades, people have been known to be much better at this capacity to remember several vocabulary words, rather than sequences of punctuated options, and menus could contain lists of shortcuts, such as "cvt" and people would quickly remember {cvt} as a shortcut for "{convert. Another aspect of using shortcut terms is ease of pronunciation, and {cvt} could be pronounced as either \C-V-T\ or \kiv-it\ to distinguish from \kon-Vert\ in spoken dialogue. All these principles are one reason that texting has been so popular, with some shortcut words found to be a "gr8" (great) time-saver in text entry. -Wikid77 (talk) 16:16, 30 June 2016 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Convert/Archive_June_2016&oldid=1092616871"