Template talk:Convert/Archive May 2016

Plural of inch

The convert template has a handy method of preventing foot being pluralised into feet. The same thing is required for the inch which gets pluralised into inches when it would not normally be so. For example when refering to old fashioned vinyl records one would describe a particular size as a "12 inch record", not a "12 inches record". Thus using {{convert}} to add the metric equivalent as in It was released on a {{convert|12|in|m|sigfig=1}} record yields "It was released on a 12 inches (0.3 m) record", instead of the correct "It was released on a 12 inch (0.3 m) record". There are many other instances when the singular is required despite there being more than one inch in the size. --Elektrik Fanne 17:51, 4 May 2016 (UTC)

It's not a singular, it's the adjectival form of the unit. See Template:Convert/doc#Adjective: a 10-mile distance Try:

• "It was released on a {{convert|12|in|m|sigfig=1|adj=on}} record"
• "It was released on a 12-inch (0.3 m) record"

Although why anybody would need a convertion of "12-inch record" is beyond me. --RexxS (talk) 18:38, 4 May 2016 (UTC)

Outside the US and UK these are known as "30 cm" records. The conversion is as valid here as it is anywhere else. So what you want is {{convert|12|in|cm|sigfig=1|adj=on}} 12-inch (30 cm). Kendall-K1 (talk) 18:56, 4 May 2016 (UTC)

I doubt Australia, Canada or South Africa use "30 cm" records, and this is the English Wikipedia. Google shows me a few hits for "30 cm record" and the non-coincidental ones are from Japan and Germany, so you may well be right that somebody might want the conversion. But it's stretching it a bit to say that's as valid as any other conversion from imperial to metric. A Belgian friend of mine, who lives in Sweden, laughed when I tried to convert "a 28-inch monitor" into centimetres in my head. Apparently, monitor size is a prime example of an imperial measurement that everybody understands. I'm surprised that "12-inch record" is less ubiquitous. --RexxS (talk) 19:39, 4 May 2016 (UTC)

I did say that record was not the only example - just the one I rather foolishly picked. If I had chosen (say) an 8 inch gun, then a metric conversion would be appropriate. But thanks for the help. --Elektrik Fanne 13:38, 5 May 2016 (UTC)

Yes, we were just chewing the cud. The example I'd have picked would be the famous 12-inch pianist. --RexxS (talk) 15:05, 5 May 2016 (UTC)

Nicely cleaned up! --Elektrik Fanne 13:22, 6 May 2016 (UTC)

I'm thinking about putting in a page move request for Nine Inch Nails to {{convert|9|in|spell=In|adj=on}} Nails "Nine-inch (230 mm) Nails" Kendall-K1 (talk) 15:29, 5 May 2016 (UTC)

million

Is there a simple way to make {{Convert|1.6|e6miles|e6km}} → 1.6 million miles (2.6×10^⁶ km) display the word 'million' for both sides? Thanks.  Stepho  talk  05:15, 19 April 2016 (UTC)

Only by using abbreviation off:

• {{convert|1.6|e6miles|e6km|abbr=off}} → 1.6 million miles (2.6 million kilometres)

Johnuniq (talk) 06:54, 19 April 2016 (UTC)

Ok. Bummer about losing the abbreviation but I can live with it today. Thanks.  Stepho  talk  07:17, 19 April 2016 (UTC)

Another million question: The original text is "... 3.9 million square kilometres of wilderness". Trying to put in a square miles convert and use similar language. It does not seem possible as though there is a "e6km2" parameter, there is no "e6sqmi". {{convert|3.9|e6km2|sqmi}} is the best I could do which produces: "3.9 million square kilometres (1,500,000 sq mi)". Have I missed something? TIA — 72.234.220.38 (talk) 03:03, 9 May 2016 (UTC)

The engineering notation prefixes of e3, e6, e9, e12, e15 can be used with most units (details).

• {{convert|3.9|e6km2|e6sqmi|abbr=off}} → 3.9 million square kilometres (1.5 million square miles)

Johnuniq (talk) 03:12, 9 May 2016 (UTC)

Ah, thank you @Johnuniq:! I just didn't use the "abbr=off". It seems to default that with the first unit, but not on the second.

And yes, the engineering notation prefixes can be used on sqmi, I must have missed something. Works both ways, eg. e6sqmi & e6mi2. Much appreciated. — 72.234.220.38 (talk) 03:38, 9 May 2016 (UTC)

Correcting mi/d unit name

Copied from Module talk:Convert/Archive 2#Correcting mi/d unit name. Johnuniq (talk) 03:16, 9 May 2016 (UTC)

Hello, I noticed that the mi/d unit was incorrectly labeled "miles per year" and I corrected it to "miles per day". The change has been successfully processed by makeunits. @Johnuniq: could you apply the change to the production version? (I read elsewhere that you prefer to do this from a local TSV file.) Thanks! — JFG ^talk 20:04, 8 May 2016 (UTC)

Thanks, that has been there since October 2014 when I copied it from a new unit without much thought. I've got a few other things to adjust (above and here) and unless there is some urgent need I would prefer to wait. If a fix is needed right now for a particular article, the procedure is to make up a new unit code (say Mi/d) and add it to Module:Convert/extra by copying the mi/d definition from Module:Convert/data and changing the unit code and name1 and name2. Johnuniq (talk) 03:16, 9 May 2016 (UTC)

Sure, no rush, I had no use for a particular article, just noticed this discrepancy while looking for the way you handle speeds expressed in Mach numbers (which I found). — JFG ^talk 12:46, 9 May 2016 (UTC)

Viscosity

I can't figure out how to use {{convert}} with units for viscosity, e.g. in the lead of glass transition there is the figure "10¹² Pa·s" that I don't know how to reproduce - the help doesn't mention viscosity at all! Thryduulf (talk) 18:43, 27 April 2016 (UTC)

It does seem odd that we document a way to get division of two units but not multiplication. Although presumably you would be converting to poise or stokes, so something similar to "/" wouldn't help in this case. Kendall-K1 (talk) 19:09, 27 April 2016 (UTC)

I'm only copyediting here, and have no knowledge of the actual units involved but using "pa/s" as the input unit with links on links to pascal and second, rather than viscosity (directly or via the pa·s redirect), and indeed seemingly isn't the same thing. I was hoping that convert would know the suitable alternative units to convert to! Thryduulf (talk) 19:16, 27 April 2016 (UTC)

There isn't really any other unit of viscosity worth converting to. There is no US unit I'm aware of, and anyone who uses poise or stokes will already be aware of the conversion. Why are you trying to convert if you don't know what units you want? Kendall-K1 (talk) 19:32, 27 April 2016 (UTC)

When I see a metric or imperial unit in an article without a conversion I add it to benefit readers who don't know the other. I know pascal as an SI unit of pressure and assumed there'd be a viscosity unit derived from psi or something like that too. Thryduulf (talk) 00:15, 28 April 2016 (UTC)

http://www.unitconversion.org/unit_converter/viscosity-dynamic.html - Who'd have thought that 1 Pascal.second is equal to 0.020885434 slug/foot/second --RexxS (talk) 00:39, 28 April 2016 (UTC)

When I was in engineering school we still used "pounds" and "atmospheres" and the gas constant was in liter-atmospheres per mole-degree, but we never measured viscosity in slugs per foot-second. I would be surprised to find anyone using that unit today. I would be doubly surprised to find anyone using that unit who was not also intimately familiar with the standard units. Kendall-K1 (talk) 01:07, 28 April 2016 (UTC)

Indeed. I forgot to add the smiley at the end. I simply found it amusing that viscosity might be measured in comparison to the speed of a slug - another example of natural units. (Yes, I know, a "slug" in this case has the dissensions of mass, but let's not spoil the joke.) I do agree that back in the Jurassic, when I was a young dinosaur, we didn't use the metric system as much either, yet I also don't recollect using any of the imperial units that page suggests like "pound-force second per square inch". In fact, in the first chem lab I worked at, we measured the viscosity of paint by timing how long it took a measured amount to pour out of a container via a standard hole. It was good enough to tell us when it was time to order some new paint for the Mini sub-frame line. --T-RexxS (rawr) 10:31, 28 April 2016 (UTC)

So you got paid to watch paint dry? Kendall-K1 (talk) 00:56, 29 April 2016 (UTC)

"...and if you tell that to the young people today, they won't believe you." --RexxS (talk) 01:23, 29 April 2016 (UTC)

Do you mean to tell me: that no one is using farthing, fathom, fortnight system anymore? --Elektrik Fanne 17:53, 4 May 2016 (UTC)

Would that be difficult to add? That and furlongs. It would make excellent example for training sessions. --ClemRutter (talk) 13:12, 19 May 2016 (UTC)

Rounding the original value

I was looking at Ben Nevis. The Ordnance Survey has just altered their value for the height, and because it's the tallest mountain in the UK, it's got a bit of press.

Basically, they tend to report heights to the nearest metre on maps. Before the remeasurement, the measured height was just under 1344.5 metres, so it was rounded to 1,344 metres. Now it's 1344.527 metres, so rounds to 1,345 metres.

The correct rounded measurement should be 4,411 feet in either case, as that would work for anything between 1,344.32 metres and 1,344.63 metres. But if you actually round the numbers with the convert template you get 4,409 feet for 1,344 metres and 4,413 feet for 1,345 metres. The flip option doesn't help because it gives the wrong answer (4,411 feet is 1,344.47 metres).

Is there any way of getting a code that allows me to input 1,344.527 metres so that it displays "1,345 metres (4,411 ft)"? Thanks, Kahastok talk 09:56, 20 March 2016 (UTC)

Yes. The input may be rounded with ri0 (0 decimal places), ri1 (1 decimal), ri2 (2 decimals), or ri3 (3 decimals). When using a lot of precision, the output defaults to use similar precision, so it needs to be rounded as well:

• {{convert|1,344.527|m|ft|adj=ri0}} → 1,345 metres (4,411.18 ft)
• {{convert|1,344.527|m|ft|0|adj=ri0}} → 1,345 metres (4,411 ft)

Johnuniq (talk) 10:44, 20 March 2016 (UTC)

Thank you very much, I will use that in the article. Kahastok talk 11:06, 20 March 2016 (UTC)

So, we're still using that adj=ri0 stuff, ay? Perhaps it's not the highest thing on the list of priorities but sometime we should move away from this kind of thing. adj should be for switching from noun to adjective form, as it was originally. Using adj for anything else make no syntactic sense. This is one of the many hacks introduced years ago to get around the parameter limitations of the old version of {{Convert}} (I should say "Middle Convert" rather than "Old Convert", the real Old Convert was Drum Guy's big {{#switch}}, so Middle Convert or Version 2). (It wouldn't be fair to blame Wikid for this, blame whoever created Version 2.) New Convert (Version 3, the Lua version) has no such limitations. What would be nice would be a dedicated parameter for rounding input, better still, a number of parameters. I'd suggest something like inprec, insigfig, innear and infrac for rounding the input (respectively to a given precision, a given number of significant figures, the nearest given number and the nearest given fraction ... fractions are numbers so perhaps innear and infrac could be combined, e.g. innear=1/3 for the nearest third). This would not only make the syntax more rational but it would give us hugely more options for input rounding than merely 0, 1, 2 or 3 decimal places. Of course, there are probably more pressing issues to deal with but, surely, as an eventual goal, we should aim to be rid of such nonsense. How about we consider this to be on the to-do list? (I'd do it myself if I had the time but learning Lua is a bit of a hurdle to begin with, also I'm afraid of breaking something.) Thanks. Jimp 11:47, 22 March 2016 (UTC)

I agree with those principles, but planning the right syntax is the trick. The round=X option applies to the output, where X can be 0.5, 5, 10, 25, 50, or an obscure "each" for a range. Option near=5 was added but is deprecated. Johnuniq (talk) 06:47, 23 March 2016 (UTC)

Support proposal. I see |adj=ri2 is not even in the documentation yet.

Note: for name congruence, better use 'round' consistently: |innear= |inround=, // |round=. Or, more meaningful name, both use 'near' (swap the deprecation). -DePiep (talk) 06:25, 30 March 2016 (UTC)

one step at a time: Johnuniq, 1. could you agree on the set of options Jimp describes (and if so, merge params |innear= and |infrac= or not?) 2. If we could go ahead, what parametername set would you prefer? Expand on the old one with incongruent additions, or along Jimps resoning (|name= and |inname= all parallel)? -DePiep (talk) 13:35, 5 April 2016 (UTC)

Planning stuff like that is surprisingly difficult. I have been agonizing over some minor syntax issues in Module:Date and it takes forever to get a clean result. The date module is brand new and I can do anything to it, but convert is different because there are two million converts in half a million articles and people are very used to how it currently works. I think the current "round" is a good name that has a meaning people can immediately grasp. By comparison, "near" is a puzzle. I would need several hours over a couple of days to make a sensible suggestion. Also, any plan should account for other things on the wish list. All I can think of at the moment is that people want ranges to span different units, say from 120 mm to 5 km. Johnuniq (talk) 02:19, 6 April 2016 (UTC)

Makes loads of sense. At least, let's not make things impossible in this (so, yet another 'keep checking this wish' on the list ;-) ). -DePiep (talk) 06:59, 6 April 2016 (UTC)

When the input ends with a zero

I question the default rounding behaviour. It assumes that any input that ends in a zero is rounded to the nearest ten, and does the same to the output. This caused a glaring problem in the List of hills in San Francisco: the three highest peaks were said to be '925 feet (282 m)', '910 feet (280 m)' and '909 feet (277 m)', so a one-foot difference between the second- and third-highest peaks were shown as a 3-metre difference, ten times as large as the actual difference. The problem was with the conversion of the second-highest: since the Roman measurement ended in a zero, it rounded the converted value to the nearest 10m, which brought it way out of whack.

I fixed this by adding '|0' to all the macros (resulting in '910 feet (277 m)'), but this seems like a lot of work to prevent what is essentially an error as significant as an order of magnitude. It also means the page author has to remember to add that extra parameter, each time they're working with a value that happens to end in zero. I think the macro should be modified to handle these cases better. I suggest that if the input ends in a zero (either because it's a multiple of 10, or because there's a trailing zero to the right of a decimal point) and the conversion multiple is greater than e (a foot is 3.28× a metre, greater than 2.72), then the number of significant digits in the output is incremented. (There's already some condition like this; the macro, thankfully, does not convert 900' to 300m!) MikZ (talk) 17:32, 28 April 2016 (UTC)

Tried to fix end-zero over 5 years ago: @Original mikz: Among numerous other precision problems, the conversion for end-zero was debated years ago to stop these hated over-rounding cases. Currently, {{convert|910|ft}} gives: 910 feet (280 m), but I agree should work like {convert|910|ft|0}, to give 910 feet (277 m). The smart-precision Template:Numsense (deleted 2014) was created to help fix those cases, but deleted by people with zero understanding of the problems. A partial fix was provided by Template:Convert/2 (also deleted), but handled by the limited range option for 2 values, as for 2 peaks: {convert|910|and|909|ft|m} to give nonsense range: 910 and 909 feet (277 and 277 m). The deleted {Convert/2} would auto-increase the precision as: 910 and 909 feet (277.4 and 277.1 m), to avoid the nonsense of both 910/909 showing the same "277 m". -Wikid77 (talk) 15:36, 19 May 2016 (UTC)

Interoperability with Wikidata

I've been asked to consider how {{convert}} could be used when the values are drawn from Wikidata. For example, at South Pole Telescope the diameter (d:P2386 d:Property:P2386) is fetched from Wikidata and is formatted by entity:formatPropertyValues(propertyID).value which returns "10.0±0.1 metre". Calls can therefore be made to extract just the numeric value and just the unit separately, allowing uses in other templates - {{convert}} being an obvious one.

The following code when pasted and previewed in a section of South Pole Telescope produces 10.0 metres (32.8 ft)

• {{convert|{{#invoke:Wikidata|getRawValue|P2386|FETCH_WIKIDATA}}|{{#invoke:Wikidata/sandbox|getUnits|P2386|FETCH_WIKIDATA}}}}

That works because {{convert}} accepts "metre" as an alias for "m"; {{convert|10.0|metre}} gives 10.0 metres (32.8 ft).

However, not all of the unit names produced by Wikidata are accepted by {{convert}}. For example, South Pole Telescope the area (d:P2046) is also fetched from Wikidata. In this case, the formatted value fetched is "78.5±0.1 square metre". Unfortunately, "square metre" is not an alias for "m2", so the following code when previewed in South Pole Telescope produces 78.5 square metre

• {{convert|{{#invoke:Wikidata|getRawValue|P2046|FETCH_WIKIDATA}}|{{#invoke:Wikidata/sandbox|getUnits|P2046|FETCH_WIKIDATA}}}}

Now, it would be possible to write a lookup that takes units like "square metre" and return the preferred abbreviation for {{convert}}, but that would either entail nesting module calls via templates - which is not always successful - or have to be hard-coped into each existing module like Module:Wikidata, meaning that the output would be only useful for {{convert}}.

It seems to me that the most flexible mechanism would be for {{convert}} to accept what I might call the "natural" names for units that Wikidata returns, like "square metre". This would ensure interoperability with any template that made use of Wikidata quantities. From what I can see, for each 'missing' unit, it should be no more difficult than e.g. adding a row such as | square metre || =m2 at Module:Convert/documentation/conversion data/doc to add "square metre" as an alias for "m2". What do others think? --RexxS (talk) 09:12, 26 April 2016 (UTC)

I know you have been working on Wikidata for quite a while, but are you confident it could ever be tamed sufficiently for this purpose? Is there some documentation for what getRawValue and getUnits will produce? Those functions are your frontends—what I really mean is documentation for the stuff that Wikidata generates. What units are possible? Does it ever generate "square meter" rather than "square metre", or perhaps "square foot"? Is the unit guaranteed to be singular? How about more complex stuff like cm/s2 (acceleration: centimetre per second squared)?

Is the number guaranteed to be just a number? Never something like 12.3×10⁵?

Did you mention what happens to the ± above? I think you are ignoring it at the moment presumably on the basis that it is the value that is wanted. However, if underlying data is available (like ±0.1) then people are going to want to use it. You probably know that this is possible:

• {{convert|10.0 ± 0.1|metre}} → 10.0 ± 0.1 metres (32.81 ± 0.33 ft)

If just a dozen aliases are needed, then sure, make a list and we'll sort it out. However, my experience of projects like Wikidata makes me imagine that there will never be an end to the surprises and corner cases and head-banging WTFs that arise if its output is used as a value in a calculation, where any deviancy will generate an error. OTOH, perhaps it is intended for machine-readable output and so might work?

My first reaction is that it would be better to have a frontend template (I suppose "dconvert" would be too cute?) that used Module:Wikidata to get the value and unit, did any translations required ("square meter" → m2), then called convert. The aim would be to use something like the second of the following, rather than the first:

• {{convert|{{#invoke:Wikidata|getRawValue|P2386|FETCH_WIKIDATA}}|{{#invoke:Wikidata/sandbox|getUnits|P2386|FETCH_WIKIDATA}}}}
• {{dconvert|P2386}}

Johnuniq (talk) 10:05, 26 April 2016 (UTC)

Well, I'm eternally the optimist about technological improvements, so I'll always work on the assumption that there's a way of getting stuff out of a database in the format we want. You can preview {{#invoke:Wikidata|Dump} in an article to see the structure and values stored in Wikidata. The call to getRawValue simply looks at whatever is stored in Wikidata in claims[PropertyID].mainsnak.datavalue.value, which should be a table, and then gets things like the sitelabel of the ["numeric-id"] if it's a "wikibase-entityid" or the ["amount"] if it's a "quantity". Numbers are also sanitised by stripping out thousands separators, precision modifiers, etc. so we get just the basic number. That's why it's suitable as an input to {{convert}}. Similarly, getUnits is intended to return the units as formatted by mw:Extension:Wikibase Client/Lua #mw.wikibase.entity:formatPropertyValues. As you have realised, I'm at the mercy of whatever the developers of the API called by Lua to get stuff from Wikibase decide to supply. The documentation at that page is all I have to work with, so there's a lot of trial-and-error. If I were designing the API for the units, I'd return the label from the Wikidata page for the unit, like d:Q25343 for 'square metre', so that it would automatically internationalise, but there's no guarantee that's what actually happens or will happen at any point in the future. Still, I'm pretty sure that Wikidata sticks with SI spellings for units, so I can't see us ever having to deal with "square meter".

I only just sandboxed getUnits() to try to provide a solution to a request on User Talk:Mike Peel, so it was aimed at answering that specifically, and the precision wasn't wanted. Nevertheless the code in getUnits has all that's needed to supply the 10.0 ± 0.1 as well - it would just need a bit of padding to match the format you gave (and yet another call in the module to return that result).

I'm attracted by the idea of {{dconvert|P2386}}. It would need a little bit of string handling in the template itself so that we could supply a local value that over-rode fetching from Wikidata (because we're still bound by the results of Wikipedia:Requests for comment/Wikidata Phase 2 as far as I know). Even so, in the long run, I think life would be easier all-round if {{convert}} understood inputs like "square metre". --RexxS (talk) 11:30, 26 April 2016 (UTC)

Related to the above: how does {{convert}} react if the units to convert to are not specified? I searched the documentation and was unable to find this. — Martin (MSGJ · talk) 21:25, 26 April 2016 (UTC)

Not really all that related, so this should have gone in a new section. The default output unit is given in the "Default" column of the tables at Module:Convert/documentation/conversion data/doc. Which may seem obscure, but it's linked from the "Units" section of the template doc. Kendall-K1 (talk) 21:37, 26 April 2016 (UTC)

@Kendall-K1: There is some relevance. If a quantity is fetched from Wikidata, we can't prejudge what units it will return, so for fully automatic operation, we will be not be specifying the units to convert to. From experience, the default choice is usually the most useful, which is why I didn't feel the need to supply anything more than a value and a single unit name from Wikidata to {{convert}}. --RexxS (talk) 23:53, 26 April 2016 (UTC)

I've got some off-wiki stuff and won't be able to think for a while, but my current idea is that we would not have a dconvert template. Instead, I would investigate making {{convert|P2386}} work. Is p2386 (lowercase P) a valid id? Are any other forms of id likely to be needed for a while? If such an id is detected, convert would call another module that I would write. It would call your Module:Wikidata to get the value and unit, do any required manipulations, then return a table to convert which would be used to generate the results. I'll ping you in a week. If you want "square metre" to work right now for some reason, add an alias at Module:Convert/extra (or I'll do it). The following should do:

["square metre"] = { target = "m2", },

Johnuniq (talk) 00:51, 27 April 2016 (UTC)

@Johnuniq: Thanks, John. Wikidata dropped support for lowercase 'p' some time ago, so P2386 is what we would get from mw.wikibase calls. Not that it's a problem to lowercase a string before spitting it out, but I'd recommend sticking to what is normally used, as it removes one opportunity from users to slip up. I assume you will want to make {{convert|10.0|P2386}} work? Can I suggest considering a named parameter in that case? I've found that to cover exceptions to the general parameter cases, something more like {{convert|10.0|pid=P2386}} is easier to catch in the module and doesn't disturb the order of the unnamed parameters (in case you want to expand things later to consider ranges, etc.). Cheers --RexxS (talk) 12:04, 27 April 2016 (UTC)

Perhaps you could explain how you think that unnamed parameter in the example above would work exactly? — Martin (MSGJ · talk) 12:16, 27 April 2016 (UTC)

Looking at Johnuniq's proposal above: I was assuming that there would be two distinct calls to Module:Wikidata to fetch (1) the numeric value and (2) some token representing the units separately. In which case, the first unnamed parameter would be the numeric value as it is now, and the unit token would be detected and used to replace the unnamed parameter that normally specifies the units. I was suggesting that using a named parameter to pass the unit token would simplify detection of that and minimise the changes needed to Module:Convert to accommodate John's idea. Of course, if he just takes the property ID as the sole input, he could fetch the quantity value and unit name with a single call, but then he'd have to separate the two internally, and he'd still be relying on Wikidata's mechanism for naming the unit - which I think we both believe to be dangerous as a potential point of vandalism. --RexxS (talk) 17:36, 27 April 2016 (UTC)

John, There are three pages that hold a demo of how we could return unit names or the code required by {{convert}} from the QID as input. The idea being that by storing these locally, we can protect them from vandalism in a way that we cannot if we rely on Wikidata to change the unit's QID into something usable by our templates on Wikipedia. The pages are Module:Sandbox/RexxS/Units, Module:Sandbox/RexxS/Unitsdemo, Module talk:Sandbox/RexxS/Unitsdemo. I think we are close to being able to make use of the {{convert}} template without any further modifications. We could easily have a {{dconvert|P2386}} wrapper to simplify its use for editors if wanted. I certainly don't want to discourage you from upgrading {{convert}}, but we might as well give Martin and Mike a preliminary solution to use in the meantime. --RexxS (talk) 17:36, 27 April 2016 (UTC)

It sounds as if you have everything under control, and I can go back to sleep. However, I may as well understand the {{convert|10.0|P2386}} example (or its pid=P2386 variant). Say P2386 has the unit metre—would that convert be equivalent to {{convert|10.0|metre}}? I cannot see why someone would want that. I thought the idea was that there is a P2386 property that has a value and a unit, and someone might want that value and that unit displayed by convert, along with a conversion to some other unit. I was planning to treat a word like P2386 as a special case which would cause convert to get the value and unit from Module:Wikidata, and convert would then use those to do its normal work.

To spell it out, if P2386 is "10.0±0.1 metre" then {{convert|P2386}} would be equivalent to {{convert|10.0|metre}}.

I'm confused about other points. It appears that people want to use (say) P2386 from Wikidata, but you are suggesting the value and/or unit should be cached in a table in an enwiki module so they are protected from vandalism? Some bot procedure would occasionally report on any discrepancies between the Wikidata properties and the locally cached copies? Is that what you are saying? By the way, your OP includes d:P2386, but the linked page says "This entity does not exist". Johnuniq (talk) 11:33, 28 April 2016 (UTC)

Agreed, John, you're right that using a single parameter when a property ID is supplied is best. I was too focussed on the potential problem of vandalism and felt that the numeric value and the units had to be dealt with separately, so I was assuming two parameters would be supplied to {{convert}}. I can see that it doesn't have to be done that way.

For a particular page, say South Pole Telescope again, the property diameter (P2386) actually seems to hold {amount = "+10.0", upperBound = "+10.1", lowerBound = "+9.9", unit = "http://www.wikidata.org/entity/Q11573"}. So we can deal with those either using the built-in entity:formatPropertyValues(propertyID).value (which will indeed return "10.0±0.1 metre") or by manipulating the raw values. I've been exploring both options, as I was alerted to the possibility of a single label (like 'metre') being vandalised on Wikidata causing massive numbers of {convert} error messages on Wikipedia if we used the Wikidata label as the input to {convert}. That's why I've been looking at the second option and creating a module on en-wp to mediate the conversion from the Wikidata IDs of common units to the code used as input to {convert}. Once created, it would be expanded as needed, but would never need to be amended since 'Q25343' is always going to mean 'square metre' and 'm2' (even if somebody vandalises the Wikidata label). Does that make sense?

Sorry about the false link, I'd forgotten that Wikidata treats properties differently from items in its url scheme; you can use d:Q11573, but you have to write d:Property:P2386. Would you like me to strike it in my OP? --RexxS (talk) 12:25, 28 April 2016 (UTC)

I think we are all on the same page on this. It just needs to be decided whether to put the code in this module or over on Module:Wikidata. What are your thoughts on this? (Whichever module will have to call the other one anyway.) Would anyone mind if I added a column to the unit tables for the unit's wikidata QID? (Like this.) I suspect that quite a number of items will need to be created, and I could make a start on this. — Martin (MSGJ · talk) 13:01, 28 April 2016 (UTC)

I doing some off-wiki stuff and won't be able to think about this for a couple of days but while adding that column seems fine, what is its point? I'm really lost with Wikidata and have no idea why someone would want to know that "square kilometre" is d:Q712226. Also, why would that be of interest to someone looking for a unit to use with convert? Would some module such as convert need to know that Q id? FYI the complete list of units as used by convert is here.

@RexxS: Thanks for the link explanation; no need to do anything but perhaps fixing the OP would be helpful for others in the future. I'll think about the issue later. Johnuniq (talk) 00:47, 29 April 2016 (UTC)

Fixed the link - thank you John for spotting it. I think that Martin is considering the opposite conversion, e.g. from d:Q712226 to "square kilometre" (or perhaps to "km2") and keeping it self-contained within Module:Convert, rather than relying on the separate module I've sandboxed. This is intended not for people, but for machine readability. Wikidata's items are uniquely identified by the QID, not by a name, unlike Wikipedia. That leaves Wikidata open to novel mechanisms for disruption that are not available on Wikpedia, since the name (i.e. label) is freely editable. From that you can see that when you fetch data from Wikidata, it's safest to use the unit's QID as the input to {convert}, either dealing with it internally, or externally via a protected "translation" module. Cheers --RexxS (talk) 01:13, 29 April 2016 (UTC)

Johnuniq: what we are looking to do, is to establish a 1-1 correspondence with units on wikidata and the units used on convert. The best way to do this may be to add them to Module:Convert/data but I don't understand how {convert} works and am scared to touch it. If you could advise, it would be appreciated. For example could we add "qid" to the following definition for metre?

    ["m"] = {
	_name1   = "metre",
	_name1_us= "meter",
	_symbol  = "m",
        qid      = Q11573
	utype    = "length",
	scale    = 1,
	prefixes = 1,
	default  = "v > 0 and v < 3 ! ftin ! ft",
	link     = "Metre",
    },

I guess this would not be helpful because as RexxS points out, we want to go in the other direction. So we just need a module basically that connects "Q11573" to "m". (It would be nice if this could be displayed on the tables, at least temporarily, because this is going to take some work and it would be easier to collaborate and see what other's have already tackled.) — Martin (MSGJ · talk) 08:46, 29 April 2016 (UTC)

One advantage to adding the qids to the convert data is that you could use the getsitelink function to obtain a possibly more reliable link to the unit on Wikipedia. — Martin (MSGJ · talk) 09:11, 29 April 2016 (UTC)

Convert is massively complex so I would like to proceed slowly. Despite what the documentation at the master list of units says, the master list is actually generated by a script that I run on a local computer. An on-wiki script (makeunits) then generates the wikitext for Module:Convert/data by reading the unit definitions at the master list page. I still use my local script because it is much easier and more reliable to add changes to a local TSV file, then have it generate the master list.

At any rate, it would be straightforward for me to add a qid field to my local TSV file, and change the scripts to handle the new field. Then convert would have qid knowledge built-in.

However, I would want to understand several details before embarking on that. First, where is the list of qid/unit values coming from? Is there some way of having a script list the units known to Wikidata and the corresponding qid codes? The idea of manually adding stuff for more than 20 units is very unattractive because we would forever be fixing typos and finding things that were forgotten. Further, we would need to have some semi-automated way of periodically comparing the enwiki qid/unit list with Wikidata.

Second, what exactly would convert do with this information? I would like to see examples of the wikitext that would be put in an article, with a 20,000-foot description of what convert (or some other template) would do with that wikitext.

A problem is that convert has tricks to generate unit codes from basic definitions. For example, millimetre is not defined in convert. When handling {{convert|12|mm}}, convert finds that mm is not defined, then determines whether it is an SI unit or something else such as kg/hl (kilograms per hectolitre) or e6usgal (million US gallons). For mm, convert decides the unit is milli metre and automatically generates the unit symbol and name. The point is that there is no way to record a qid for mm or km or any other SI multiple of a base unit.

If both-ways look up is needed (unit to qid and qid to unit), I could devise something to handle it. It would help to know roughly how many units we think might be needed. Also, what is the Wikidata procedure for units like mm or mm/s? Would they have unique qid values? Convert has 1,113 unit codes built in (many unused), and lots more derived codes like those mentioned.

I have been meaning to learn about Wikidata for some time, and I will have to slowly digest some docs to follow this discussion—I'll start with WP:Wikidata but if other pages related to Q or P or units are known, please link to them for my education. Johnuniq (talk) 11:20, 29 April 2016 (UTC)

Thanks for the useful response. Part of the problem is that you don't understand wikidata and we don't understand convert ;) Basically we need to convert qid to convert code. Going the other way would be of ancillary use only. So there is probably little value in adding it to /data at this stage. To answer your other queries in no particular order: when you enter a quantity in wikidata, you enter a number followed by a unit. The unit must correspond to an item; this means that there must be an item for every unit that might conceivably be used. There is currently metre per second (Q182429) but mm/s does not exist and would need to be created before it could be used over there. More later. PS Before looking at the wikicode I was sure that 20,000-foot would be produced by {convert}, but no, you did type that! — Martin (MSGJ · talk) 13:13, 29 April 2016 (UTC)

If you're coming to Wikidata from the perspective of a Lua programmer, John, then there are not many resources that I've been able to find. One thing that is instructive is to paste {{#invoke:Wikidata|Dump}} into a short section of any article, then preview it. You'll see a JSON-like structure of the data stored in the Wikidata entity corresponding to that article. There is an API exposed to Lua to access that data, with some processing of formats available: something resembling documentation is at https://www.mediawiki.org/wiki/Extension:Wikibase_Client/Lua which I keep bookmarked in case it changes. The Module:Wikidata contains numerous functions that attempt to put front-ends on the different things that may be accessed from Wikidata, so that they can be used in Wikipedia templates, so it might be worth looking at for examples. Hope that helps, --RexxS (talk) 16:13, 29 April 2016 (UTC)

OK, I'll need time to digest this. MSGJ added a QID column to the area units. I infer some manual method probably mentioned above was used to work out the QID for each unit listed there? I gather there is no way to list the units currently defined in Wikidata?

One more point about units that I didn't mention: there are many units that have no useful conversion. They are therefore not listed in convert's data. Examples: volt, ampere, lumen. That is another reason convert's data table may not be the best place to store QID values. Johnuniq (talk) 01:02, 30 April 2016 (UTC)

I found lots of interesting links including d:Wikidata:Units which includes database report links for Units of measurements and Items with unit symbol and a discussion with an amazing SPARQL query to list "which items are most commonly used for units". Johnuniq (talk) 10:29, 30 April 2016 (UTC)

Trial implementation of convert with Wikidata

@RexxS, @MSGJ: I have done a very quick implementation for a test. Article South Pole Telescope is item Q1513315 and property P2386 is diameter. At the article, you can preview the following (it fails here because this talk page has no such property):

• {{convert/sandbox|P2386}} →

It is also possible to specify the item code, so this works here:

• {{convert/sandbox|P2386|qid=Q1513315}} →
• {{convert/sandbox|P2386|in|abbr=off|sp=us|qid=Q1513315}} →

The second of those has some extra parameters just to demonstrate that the normal rules for convert apply. What is new is that using a P code as the first parameter will cause that code to be replaced with the appropriate value and unit. It simulates the user entering: {{convert/sandbox|10.0|m|in|abbr=off|sp=us|qid=Q1513315}}

I put a "cache" of some Wikidata units in Module:Convert/data/sandbox. They are in the string wikidata_units at the bottom of that module. This is all Q&D and if it looks desirable I will need to spend some quality time checking details. I might also make the error text a tiny bit more helpful. In convert, hold the mouse over the error message to see more details. Johnuniq (talk) 05:27, 1 May 2016 (UTC)

I added more units and a function to list them. It could be improved, but is useful. Preview the following in a sandbox to list all the Wikidata units known to convert:

• {{convert/sandbox|test=wikidata}}

The first item in the list is:

• d:Q100995 (pound) = lb (pound)

Text on the left of "=" is the Wikidata information in convert: the Q identifier and label (the label is not used by convert; it is a convenience only).

Text on the right of "=" is from convert: the first item is the unit code, and the text in brackets is the singular name resulting from looking up that unit code in convert.

Johnuniq (talk) 12:11, 1 May 2016 (UTC)

You've done a great job there, John. When you can retain all the functionality of the previous code without having to hedge around exceptions, you know you've got the right implementation of the new feature. It certainly is the solution that Martin was looking for in his original question to Mike Peel. I think there might be potential value in having the Wikidata units in a separate module, to cater for the possibility that some future application also wants to do the job of converting from QID to convert code - or more likely to unit name, although I can see the problem of litre (Q11582) vs metre (Q11573) for US/GB variants. Well done! --RexxS (talk) 14:06, 1 May 2016 (UTC)

Nice work indeed. A couple of points which occur to me:

1. The most common way to implement this in infobox templates is to allow input via a parameter and then fall back to wikidata if no parameter is defined. So on Template:Infobox telescope for example, could we use code like {{convert/sandbox|{{{diameter|P2386}}}}}? (It doesn't work currently because a blank input produces an error rather than a blank output.)
2. As you note above, there are some units (e.g. volts) which {convert} does not deal with. It would be nice though if it could at least handle the units for us, even if it can't convert to something useful. So for voltage (P2436) it would be possible to use {{convert/sandbox|P2436}} to get the value followed by "volts".

— Martin (MSGJ · talk) 11:02, 3 May 2016 (UTC)

I have wondered about interpreting a blank input value as "no operation" to make it easier for a template to call convert. Possibly a special option could say "called from a template" and that would mean to not make a fuss about a missing value. The same option might also make convert handle a unit it does not understand by displaying only the input, as given. OTOH displaying just the input value/unit is more of a job for {{val}}. But an infobox user won't know which units are understood by convert... I'll need to ponder that. Johnuniq (talk) 12:32, 3 May 2016 (UTC)

Didn't even know about {val}, and I see it does stuff with units as well. Perhaps that is the more natural place to put this code? Or perhaps that module could share the wikidata codes with this module so that they both recognise the same units? — Martin (MSGJ · talk) 13:29, 3 May 2016 (UTC)

I would suggest testing for a local parameter in the relevant template. For example in {{Infobox telescope}}, we could write something like:

• | label11 = Diameter
• | data11 = {{#if:{{{diameter|}}} | {{{diameter|}}} | {{convert|P2386}} }}

That would allow editors to supply a local parameter |diameter= in an article, which would override the Wikidata value. Naturally, that article parameter could also contain a convert template if desired. In the default case, though, it's only the designers of infobox templates who need to know what units {convert} understands. --RexxS (talk) 15:21, 3 May 2016 (UTC)

Looks like the right approach. Could we further simplify the job, even if it's just for infobox tinkerers? If the wikidata property is correctly named, we shouldn't have to look up the property identifier. I suggest creating a {{wikidata read}} template which would do the heavy lifting, so that in your example, the infobox designer would only have to enter:

• | label11 = Diameter
• | data11 = {{wikidata read | diameter}}

{{wikidata read}} would take the named parameter if present, otherwise read its value from wikidata with the appropriate convert invocation on the matching property. Do we have a way to look up a wikidata property by name? — JFG ^talk 17:44, 8 May 2016 (UTC)

I can see the attraction of making it simpler, but it poses two problems: (1) the Wikidata property is an editable label, not a unique name in the same way that a Wikipedia article is. There is diameter (P2386) (a property), diameter (Q37221) (an entity corresponding to the Wikipedia articles in different languages) and Diameter (Q1208617) (the German Wikipedia dab page}}, all labelled "diameter" - so picking the right one is a real complication - any of which could be vandalised on Wikidata; and (2) we really ought to be ensuring that it is easy to internationalise our code for use by the smaller Wikipedias, but hard-coding the English name by matching it with what we've decided to call an infobox parameter will make it harder to translate. Hope that makes sense. --RexxS (talk) 22:31, 8 May 2016 (UTC)

@RexxS: I see your point, however I think that the advantages of a simple syntax outweigh the inconvenients. To your objections:

1. Wikidata properties are very stable, labels are well-maintained in many languages and are the natural names which will often match parameter names in infoboxes. For example, diameter (P2386) is already correctly labeled in 24 languages and the Italian infobox it:Template:Telescopio uses diametro as expected. Vandalism on names of property labels should be minimal (there is not much incentive to disrupt there — do we have stats on this?), and can be reversed easily.
2. On the contrary, Wikidata can help us with i18n, because properties are already labeled in many languages, and even inexperienced editors can easily add the appropriate property names for new languages. English has no special role, because infobox parameters on each local wiki are already named in the local language.

To address the diversity of existing infobox parameter names for the same concept, we would simply add an optional parameter to {{wikidata read}} which would accept an infobox name when that is different from the wikidata label. So the template could be invoked with {{wikidata read | diameter}} or {{wikidata read | diameter | mirror_diameter}} to match an existing infobox parameter called mirror_diameter. And our Italian friends will use {{wikidata read | diametro}}, Germans {{wikidata read | Durchmesser}}, etc. Elegant much? — JFG ^talk 13:27, 9 May 2016 (UTC)

Ask the Spaniards about vandalism on Wikidata causing havoc on the Spanish Wikipedia because of its extensive use in infoboxes there. It is a genuine concern and I don't agree that we can ignore it. I do like the idea of having an optional parameter name when it would differ from the Wikidata label, though. That would still leave us with the problem of distinguishing between 2386, 37221 and 1208617, assuming we can make a call to read the numeric ID associated with "diameter" on Wikidata. Any suggestions? --RexxS (talk) 14:27, 9 May 2016 (UTC)

Convert with Wikidata nearly ready

@RexxS, @MSGJ: I have implemented most of what is needed to have convert work with Wikidata properties. The results are in the sandbox modules:

• 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

See my sandbox (permalink) for the convert demo given previously, and a list of the Wikidata units known to convert. Three things remain:

• Thorough check (it's been pretty rushed)!
• Fix convert/wikidata to do something better than taking the first claim (see TODO).
• Think about whether something is needed to handle a property given to convert but which does not exist for the specified item in Wikidata.

I know it is very impure for convert to have a bunch of code and data for handling Wikidata, but the tricks required to function with convert make the code very convert-specific. I don't think it is worth generalizing, although things can be refactored later if needed. Johnuniq (talk) 12:20, 16 May 2016 (UTC)

I've just pasted and previewed in South Pole Telescope the following:

• {{convert/sandbox|P2044|abbr=on}}
• {{convert/sandbox|P2044|abbr=off}}
• {{convert/sandbox|P2386|qid=|0}}
• {{convert/sandbox|P2046|qid=}}
• {{convert/sandbox|P666}}

The expected results are returned in each case, including "Error in convert: Could not read property P666 (help)" for the last one in preview mode. It's useful to be able to specify the qid, but as it then becomes an expensive call, most of the time in infoboxes it will be called without qid or with |qid= blank. That's nothing like a thorough check, but handling the wikidata-specific parameters cleanly is a good sanity check.

If you want to deal with other than first claim, perhaps take a look at Module:Sandbox/RexxS/ImageLegend, which I tried to document copiously for use by the Lithuanian astronomers. I had to fetch a sub-property (media legend (P2096)) from a qualifier of a property (image (P18)), where the base property could have multiple values, so I had to deal with the raw values of ranks, because mw.formatPropertyValues only returns the base property value. The astronomers were quite happy to designate one image the 'preferred' one on Wikidata, and that's the approach I'd recommend.

I'm reasonably happy with how convert handles being asked to convert (P666) in South Pole Telescope. It's a blatant error and, to my mind, it should show an error. Does it also populate a tracking category?

As for programming impurity, I'd say "stuff it". I've seen programming fashions come and go many times since I first learned COBOL in the 1960s and I long ago stopped worrying about ringing the last 28.35 grams of performance or inter-operability out of the code. We're not working in big teams here with interchangeable 'black-box' modules. Lua modules are not the easiest objects to expose calls to other modules and duplicating working code inline is cheap and easy to follow later. Your approach and implementation is fine. --RexxS (talk) 17:07, 16 May 2016 (UTC)

Thanks for the ideas in your code. Wikidata is a bit of a mess because there are essentially no rules so a client such as a module has no clue what to do. I wrote a nice iterator to get the statements in preferred/normal order, but then I found I had written Python code! Turning it into Lua was a mess, so I just made a list instead and iterate that with ipairs. It's actually very efficient because the list holds references to tables.

New feature: a property can be made optional by appending "?". The following could go in {{Infobox telescope}}:

• {{convert/sandbox|{{{diameter|P2386?}}}}} Broken! See below.

That would use diameter if given, or P2386 if it exists, or output nothing (no error if property not found). If the question mark is omitted and the property does not give a usable value/unit, an error is shown. Convert errors put articles (not other pages) in a tracking category. I won't give the details because the category name is changing, but it works.

A nicely formatted list of Wikidata units in convert is at Module talk:Convert/wikidata/data/sandbox. Johnuniq (talk) 12:10, 18 May 2016 (UTC)

Looks nice thank you. I wonder if the ? syntax should be the default behaviour? These are mostly going to be used on infobox templates, so statements for a certain property will not exist for each and every article. By all means show the error message for non-existent properties like 666, but for valid properties without statements, I think perhaps returning nothing would be best. — Martin (MSGJ · talk) 12:22, 18 May 2016 (UTC)

Agree with MSGJ, forget the question mark, display nothing when the target item has no such property. — JFG ^talk 13:06, 18 May 2016 (UTC)

OK, I'll investigate although experience suggests that having an error with a tracking category finds a lot of broken stuff, includes IPs and vandalism accounts who make random changes to infoboxes. My above comment about {{convert/sandbox|{{{diameter|P2386?}}}}} is wrong because if "diameter" is used, it would have to be accompanied with a unit. And that unit would break the convert when diameter is not supplied and P2386 is used. I'll think about that too. Johnuniq (talk) 02:45, 19 May 2016 (UTC)

There is a fix in the sandbox: P2386? is now an error (because "?" is not recognized), but P2386 will either work, or will output nothing. Except, if the item ID is specifed (qid=Q1513315), it will give an error if the property does not work.

There is a new parameter which might make handling optional parameters easier.

For example, {{convert/sandbox|{{{diameter|P2386}}}|inunit=ft}} will:

use the diameter value with input unit ft (if given); or

use the value and unit from P2386 (if found for the current page) and ignore inunit; or

output nothing.

If diameter is given and the convert is invalid, an error will be shown (with tracking category).

Please think about whether this would be useful because I don't want to add strange options if they will not be used. Some testing would be good! Johnuniq (talk) 06:27, 19 May 2016 (UTC)

I don't think that |inunit= will be a fix because I'm expecting the convert to be embedded in an infobox template definition by a template coder, not provided by an editor in an article. In that case, the coder can't know in advance what units will be used for every article where the infobox appears. I think we're full circle back to where I thought that the numeric value and units would be provided separately. Once you go with a single parameter like 'P2386', you need to also be able to cope with a single locally supplied value passed from the infobox, like |diameter=10 metres. If you remember we looked at how we might address that sort of issue in the getUnits call I was working on, and I think you'll need to split the |diameter=10 metres into the numeric part and the units inside the call to convert, using some logic to recognise that a single parameter has been passed. Hope that makes sense. --RexxS (talk) 07:22, 19 May 2016 (UTC)

I'm used to infoboxes having fields such as elevation_m and elevation_ft. The user is supposed to enter the value in the correct field, and the infobox coder would know that one of them has unit m while the other is ft. If that's not the case, some other fix is needed. I have noticed that some person infoboxes can do magic with height fields where the user can enter "5 ft 11 in" or "1.7 m" and something passes the correct values/units to convert. I never got around to finding what that something is, but a generic value-and-unit parser would be helpful. I could look at putting something in convert, perhaps input=1.7 m but handling composite units like ft+in would be too much overhead (Module:Convert is over 3,600 lines, not counting its companions!). It would be possible to handle just ft+in with a simple regex, but a general solution might be tricky. Johnuniq (talk) 08:13, 19 May 2016 (UTC)

I'm now thinking convert might accept parameter data=xxx where xxx could be something like 10 m or 10 meters or other common units, or could be a property like P2386. Any thoughts on data vs. input or something else? My thinking was that "data" hints at Wikidata and avoids the somewhat overworked ideas of "input" and "output" in convert. Johnuniq (talk) 12:17, 19 May 2016 (UTC)

I thought about my suggestion of trapping the single parameter case (#frame.args == 1), but realised that would spoil the ability to use convert's other parameters. So yes, a named parameter is eminently sensible as it preserves all of the other functionality. Infobox coders would quickly learn to use |data 99 = {{convert/sandbox|data={{{diameter|P2386}}}|abbr=on|sp=us}}, etc. If I might make one suggestion: should the convert module fail to recognise units in a locally passed parameter, like {{{diameter}}}, would it make sense for the module to silently return that value with no conversion? The advantage is that the infobox will still work even with unrecognised (and probably erroneous) units, or none at all - which editors at the article level may well supply. The disadvantage is that it wouldn't catch editors' mistakes in the same way as a nice bold error message does; but on the other hand, you won't have every cockup that editors can manifest reported to you for fixing. --RexxS (talk) 13:18, 19 May 2016 (UTC)

I decided to use input= instead of data=. Can have:

input=<value><space><unit> or

input=<propertyid>

Examples:

• {{convert/sandbox|input=12 kilograms}} → 12 kilograms (26 lb) ("kilograms" is an alias for "kg")
• {{convert/sandbox|input=12 kg}} → 12 kilograms (26 lb) ("kg" is a convert unit)
• {{convert/sandbox|input=P2386|qid=Q1513315}} → 10.0, 1 metre (32.8, 3.3 ft)
• {{convert/sandbox|P2386|qid=Q1513315}} → (must use new "input=property")
• {{convert/sandbox|input=12 widgets}} → 12 widgets (invalid input gives an error is output as given)
• {{convert/sandbox|input=P666}} → (a not-found property gives no output)

Convert will return nothing if a property is not known. However, if input=value-unit is used, an error will be shown if it is not valid. I decided on that because it is common for there to be accidental typos and purposeful vandalism in converts, and having an error/category makes dealing with many of them quite easy. This needs testing and thought. Johnuniq (talk) 08:04, 20 May 2016 (UTC)

Hmmm. Using convert in Template:Infobox telescope works ok (as far as I can tell without saving an edit) at South Pole Telescope, but is a mess at Southern African Large Telescope where several of the fields have extraneous stuff like references and complex statements. I suppose convert could ignore errors and just return the input, but ignoring errors worries me. I might leaving bashing convert for a while because there are other imponderables such as whether people want auto-populating infoboxes (RfC). However if anyone has ideas or notices a problem, please post. Johnuniq (talk) 11:14, 20 May 2016 (UTC)

Southern African Large Telescope is a perfect example of where editors will present all sorts of stuff in infobox fields ("Diameter = hexagonal array of ~11.1 x ~9.8 m"). Let's face it: if editors find that data constraints don't help them write the article, they will do away with data constraints. Does a hexagon even have a diameter, and what does it matter? So my recommendation is to let that sort of stuff pass through silently, and learn not to worry about it. As Douglas Adams accurately observed, it's an SEP. --RexxS (talk) 15:17, 20 May 2016 (UTC)

Yeah, convert would have to ignore stuff like that, and we'll never be able to summarize the world's knowledge with clean numbers. I'll ponder the situation. One reason for hesitancy is that if input=x works without error in infoboxes, people will use it in articles. Then errors will occur and go unnoticed. I sometimes revert a dozen pieces of number-changing vandalism a week on obscure BLPs where jokers go too far and mess up convert. Johnuniq (talk) 01:17, 21 May 2016 (UTC)

I updated the module again. I think it's doing pretty much what you suggested. See the examples just above: I added the last example and noted "output as given" on another. After more thought/testing I'll start a new section and invite further thoughts. Johnuniq (talk) 12:21, 21 May 2016 (UTC)

More confusion

@RexxS: An experiment has left me confused. What's going on with the following?

• Edit Template:Infobox telescope.
• Replace its content with the following (do not save).

{{infobox
| title  = {{{name|{{PAGENAME}}}}}
| label1 = Diameter
| data1  = {{#invoke:Wikidata|getValue|P2386|{{{diameter|FETCH_WIKIDATA}}}}}
| label2 = [[Focal length]]
| data2  = ({{{focal_length|P2151}}})
}}

• Under "Preview page with this template" at the bottom, enter:

  Southern African Large Telescope

• Click Show preview.

The result includes "()" for Focal length. How can that occur? Why isn't it "(P2151)"?

I noticed this when trying convert ({{convert/sandbox|input={{{focal_length|P2151}}}}}). Convert receives input=x with x as an empty string, just like the empty string between the parentheses. Have I been doing too much Lua coding?? Johnuniq (talk) 11:56, 20 May 2016 (UTC)

@Johnuniq: It's a quirk of the way that the template preview ability works. It sort of substitutes your infobox for the article's current infobox using the article's parameters, but doesn't seem to behave in the way we expect. If you instead copy your infobox code into a section of the actual article Southern African Large Telescope and preview it, you will indeed see Focal length (P2151). The article actually had | focal_length = in the infobox, so the template preview function was presumably just using that {blank) value, rather than following the code you wrote. I've just removed the | focal_length = from the article, and now the template preview shows what you were expecting. Hope that helps. --RexxS (talk) 13:56, 20 May 2016 (UTC)

Thanks. I've got used to that preview working beautifully. Ideally I would make a succinct example and report the problem somewhere because it must be processing parameters like data2 above correctly in most cases or it would never work. Johnuniq (talk) 01:11, 21 May 2016 (UTC)

Troy weights

I need troy weights from old currency etc. In 1600s there was a currency called "Cologne mark" used throughout northern Europe – Dutch / Norwegian / Swedish / and plenty of prince states.
The units are:

1 Troy pound (lb t)	=	12 troy ounce
1 troy ounce (oz t)	=	20 pennyweight
1 pennyweight (dwt)	=	24 grains
Mint weights (or moneyers' weights)
1 grain (gr)	=	20 mites
1 mite	=	24 droits
1 droit	=	20 perits
1 perit	=	24 blanks

I would like output multiples be available for troy weights. E.g. ozt+dwt ozt+dwt+gr dwt+gr lbt+ozt lbt+ozt+dwt lbt+ozt+dwt+gr
(don't need submultiples of grain). BTW plural of pennyweight is the same. Not pennyweights. 213.205.252.158 (talk) 11:39, 20 May 2016 (UTC)

These units exist (the full list is here):

• gr = grain (unit)
• dwt = pennyweight
• ozt = troy ounce
• lbt = troy pound

Currently pennyweight adds "s" for the plural. I just corrected that, but it won't go live for a few weeks when the next release occurs. Thanks for the correction. On second thoughts, I wonder if this is an WP:ENGVAR issue? Does anyone know the "correct" plural of pennyweight in US/UK speak?

Hundreds of obscure units are defined in convert and are never used. Please spell out which text in which articles need new features. Are you sure a bit of prose would not be sufficient? Putting it another way, does it matter how many pennyweight there are in kilogram? Johnuniq (talk) 00:38, 21 May 2016 (UTC)

I think I gave too much information. My question was about asking for multiple outputs, i.e. similar to avoirdupois of lbs-oz for troy weights would be oz-dwt. See Strainer spoon, London 1774, 3 oz. 18 dwt. or New York, ca. 1755. It seems that heavy items are still left in ounces, not pounds. (31 ozt → 2 lbt : 7 ozt). And how were the weights written down? Is there a shorthand, similar to £sd = £12-11-10 or £12/11/10, or just the weights like 11 oz 19 dwt. They don't use the word 'troy'.

I don't really know about using dwt, but remember when the coalman came, a sack of coal was 1 cwt and two sacks were 2 cwt. (hundredweight in single or plural).

213.205.252.158 (talk) 08:47, 21 May 2016 (UTC)

The plural of 'pennyweight' is 'pennyweight' - no 's' added. --Elektrik Fanne 16:48, 22 May 2016 (UTC)

I think there is more to it (possibly WP:ENGVAR as mentioned above). For example, see wikt:pennyweights. I'm not suggesting that Wiktionary is a reliable source, merely that it is an example of what appears to be a common idea. I have an old Shorter OED that includes "pure silver is 12 pennyweights fine", and have seen other dictionaries claiming the plural includes "s". Johnuniq (talk) 09:59, 24 May 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)

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)