Template talk:Convert

Prominent error message on preview

Convert produces error messages that are very easy to miss. The plan was that readers of an article should not be bothered with disturbing messages due to possibly minor problems. I am proposing to change how errors are displayed when an edit to an article is previewed. If the article is saved with errors, the messages will be the same as they are now (easy to miss). There is a new test=preview parameter so the prominent error messages can be seen in a saved page.

These four converts have errors that show the easy-to-miss messages (hold the mouse over each message to see details):

• {{convert/sandbox|12|xyz|m}} → 12 xyz
• {{convert/sandbox|1234|ft|kg}} → 1,234 feet ()
• {{convert/sandbox|123|mm|in|sigfig=0}} → 123 millimetres (4.8 in)
• {{convert/sandbox|123|mm|in|disp=s}} → 123 millimetres (4.8 in)

When previewing an edit, the same four converts display hard-to-miss messages:

• {{convert/sandbox|12|xyz|m|test=preview}} → 12 xyz
• {{convert/sandbox|1234|ft|kg|test=preview}} → 1,234 feet ()
• {{convert/sandbox|123|mm|in|sigfig=0|test=preview}} → 123 millimetres (4.8 in)
• {{convert/sandbox|123|mm|in|disp=s|test=preview}} → 123 millimetres (4.8 in)

For testing, it is also possible to use test=nopreview to preview the real messages as they would appear if the edit were saved. For example, if this section is edited and previewed, the following convert will show the normal (easy to miss) error message.

• {{convert/sandbox|12|xyz|m|test=nopreview}} → 12 xyz

Assuming everyone is happy with this I will include this change in the next update. I'm still pondering the Wikidata changes discussed above which will also be included. Johnuniq (talk) 10:09, 9 May 2016 (UTC)

• Support Great idea! — JFG ^talk 12:48, 9 May 2016 (UTC)
• Support Kendall-K1 (talk) 14:20, 9 May 2016 (UTC)
• Oppose as burden for next editors: When a user saves a {convert} with errors, then a glaring red-error message would be shown in preview to the next editors, who likely have no idea/desire to fix all prior editors' mistakes. Also, as more Convert features are deprecated, then whole tables will likely show hundreds of red-error message, red-error message, red-error message, (etc.) to disrupt the view of the table. Currently, the wp:CS1 cite templates have 200,000 (thousands) of hideous red-error or green-error messages which few editors know to fix, and so the solution is to show only small superscript-notes and log error-categories for wp:wikignome editors to view and fix, but instead the glaring error messages are far worse than the tiny error, which they try to grandstand into worldwide notification, when viewing a page from miles away (several km away). Ideally, as in software 40 years ago, the wp:MediaWiki software would have error-counter data (passed between templates) to suppress excessive messages after the first few errors were reported. -Wikid77 (talk) 15:56, 19 May 2016 (UTC)

Aren't you mistaking, Wikid77? As the proposal is, it only shows in Preview. -DePiep (talk) 22:34, 24 May 2016 (UTC)

• Support, with this addition: the message in Preview should show always (not just when |test=preview is set). So: when an editor edits {{Convert}}, the message is shown in preview (and does not show after Save). The maintenace-category should work the same (categorise error situation). To add a detail: in a similar situation (error message in Preview), I have added tot the big-red error message in green: "This message is harmless, won't show when saved". -DePiep (talk) 22:34, 24 May 2016 (UTC)

• Yes, that's how it works now. The test=preview used above is to make the messages visible in the saved edit. If you preview {{convert/sandbox|12|xyz}} in a sandbox you will see the red message, but if you save the edit, the small blue message will be shown. The tracking category is always added if there is an error in a convert in an article. Johnuniq (talk) 23:24, 24 May 2016 (UTC)

OK, I missed that. Using test=... explicitly will be rare then, like in talkpage and /doc demo's only. -DePiep (talk) 23:41, 24 May 2016 (UTC)

• Support This should be very helpful without causing trouble. Jimp 16:43, 26 May 2016 (UTC)
• Comment. Below, in the changes-announcement, you write: 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. Suggestion: the parameter value =preview looks illogic (has different meaning). Shouldn't it be like: |test=show_errors? -DePiep (talk) 18:53, 29 May 2016 (UTC)

  The purpose of test=preview is to show what a previewed convert with error would look like. It is unlikely the option will ever be needed except for developing convert or possible rare use on this talk page, so it's not worth optimizing. I don't think the option should be part of user documentation. Johnuniq (talk) 23:36, 29 May 2016 (UTC)

shouldn't abbr=on the default value?

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)
• 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)

• I just updated the sandbox for some Wikidata changes (see above) and removed the default abbr=on for now. Johnuniq (talk) 06:13, 19 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/sandboxlua2|12.31|m|ftin|frac=on}} → 12.31 m (40 ft 5 in)
• {{convert/sandboxlua2|123|m|ft|sort=on}} → 123 m (404 ft)
• {{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)

Conversion using assumed accuracy

There is a discussion taking place at Template talk:Infobox mountain#Altitude conversion error where an editor is complaining that a montain with altitude 4,000m is converted to 13,000ft rather than 13,123ft because {convert} is incorrectly assuming that 4000 is correct to the nearest 1000m where actually it is correct to 1m. Is there any way to fix it for this article without changing the default for all articles? — Martin (MSGJ · talk) 08:18, 27 May 2016 (UTC)

The discussion you linked to accurately describes the situation. In addition to the 4000.0 that you tried, the following klunkiness also works:

• {{convert|4000.|m}} → 4,000 metres (13,123 ft)

That is equivalent to 4000.0 except for how it appears; I'm not recommending it. There is no generic solution because while it is probably true that mountain elevations measured in the last decade or so have accuracy better than ±0.5 ft (0.15 m), it is likely that some of the instances of {{Infobox mountain}} are for mountains where the elevation is not known to that accuracy. It is also likely that some of the elevations have changed, so the accuracy is misleading. A minor issue is that I cannot see references for the precise elevation, although I imagine they are out there.

There are two choices. First, leave the template unchanged but require that articles with elevations like 4000 or 4300 or 4320 use something like {{convert|4000|m|0}} in the elevation field. Second, change the template to use the convert just mentioned, and require that articles where that is not appropriate should use a different convert in the elevation field. Neither of those is totally satisfactory.

Possibly convert could have a new parameter to say that all the figures given should be considered to be accurate (any suggestions for the syntax!?), but that would also give invalid results because it would probably be used in places where 4000 does not mean 4000±0.5. In short, I don't know, sorry.

Postscript on previewing this comment: convert might be changed to interpret "4000." as above, but the dot could be suppressed in the result?? Johnuniq (talk) 10:23, 27 May 2016 (UTC)

Just to clarify something. You couldn't use {convert} on the article, because the infobox code would push it through {convert} again, which would cause an error. "4000." is sensible but it only works for 4000±0.5 - what could you do for 4000±5? The only rigorous way I can see is for {convert} to accept the accuracy in the value, i.e. {{convert|4000±0.5|m|ft}}. (Would also be good for Wikidata as the values typically come back in this form.) — Martin (MSGJ · talk) 10:45, 27 May 2016 (UTC)

I believe hike395's comment at 03:06, 26 May 2016 in the the discussion is accurate. The template has an elevation_m field which requires a pure number like 4000. However, there is also an elevation field which accepts anything. At Les Droites the infobox could have elevation_m blank (or delete the line), and include:

| elevation = {{convert|4,000|m|0|abbr=on}}

People are not going to want to write 4000±0.5 to mean 4000., and I wouldn't want to further complicate convert by parsing that. If a mechanism to enter 4000 as an "exact" value is wanted, I suggest treating "4000." as a special case.

Re Wikidata: Values are not like 4000±0.5 when read directly from Wikidata as convert/sandbox is now able to do. Searching this page for "I decided to use input=" shows examples of the syntax I have implemented. I was planning to post a new section soon proposing that convert/sandbox go live. When I do that, I will outline the changes including how Wikidata can be accessed, and will ping editors who may be interested including yourself. Johnuniq (talk) 11:51, 27 May 2016 (UTC)

Module version 14

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

• Module:Convert • Module:Convert/sandbox • same content
• Module:Convert/data • Module:Convert/data/sandbox • same content
• Module:Convert/text • Module:Convert/text/sandbox • same content
• Module:Convert/extra • Module:Convert/extra/sandbox • different (diff)
• Module:Convert/wikidata • Module:Convert/wikidata/sandbox • same content
• Module:Convert/wikidata/data • Module:Convert/wikidata/data/sandbox • same content

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|input=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|input=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)

• Update done. Johnuniq (talk) 03:20, 1 June 2016 (UTC)
  • Thanks John, it performs as I expected it to in all the cases I've checked so far. --RexxS (talk) 12:18, 2 June 2016 (UTC)
    • re Categories: put up the two abandoned categories for deletion (Speedy, G8). -DePiep (talk) 08:30, 9 June 2016 (UTC)
      • Good, but what about Category:Convert error categories? I put the new category (Category:Convert errors‎) in that for my convenience as I wanted to see if anything somehow turned up in the other categories. As expected, they have been empty, and new errors turn up in the new category. Johnuniq (talk) 10:34, 9 June 2016 (UTC)
        • I've deleted the old categories. -- WOSlinker (talk) 12:33, 9 June 2016 (UTC)

Obscure units: the league – some problems here?

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)

British pounds (£) to US dollars ($)

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)

A flippin' mess

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)

Astrophysical conversions

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×10³³ g and R_☉ = 9.9598×10¹⁰ 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×10¹⁰ 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×10³⁰ kg; 4.4×10³⁰ lb)
• {{convert|1|solar mass|kg lb|abbr=on}} → 1 M_☉ (2.0×10³⁰ kg; 4.4×10³⁰ lb)
• {{convert|1|solar mass|kg lb|0|abbr=on}} → 1 M_☉ (1.9885499999999×10³⁰ kg; 4.3840023146773×10³⁰ 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×10³³ g" (SM = 1.989×10³³ × 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)

Template:Cvt abbr=in broken by Lua version

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).

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)