Template talk:Convert/Archive May 2015

Minor convert range screw-case

There's this table:

Light comparison
Name	Frequency (Hz) (Wavelength)	Photon energy (eV)
Gamma ray	> 30 EHz (0.01 nm)	124 keV - 300+ GeV
X-Ray	30 PHz (10 nm) - 30 EHz (0.01 nm)	124 eV to 120 keV
Ultraviolet	30 EHz (0.01 nm) - 750 THz (400 nm)	3.1 eV to 124 eV
Visible	750 THz (400 nm) - 428.5 THz (700 nm)	1.7 eV - 3.1 eV
Infrared	428.5 THz (700 nm) - 300 GHz (1 mm)	1.24 meV - 1.7 eV
Microwave	300 GHz (1 mm) - 300 MHz (1 m)	1.24 µeV - 1.24 meV
Radio	300 MHz (1 m) - 3 kHz (100 km)	12.4 feV - 1.24 meV

I'm using the Hertz/length thing, but that's not the problem. If you look at it closely you find that the lines would probably be better done as ranges like:

Infrared, 428.5 Thz - 300 Ghz (700nm - 1 mm), 1.24 meV - 1.7 eV

Instead I'm doing: {{convert|428.5|THz|nm|abbr=on|sigfig=1}} - {{convert|300|GHz|mm|abbr=on|sigfig=1}} to give: 428.5 THz (700 nm) - 300 GHz (1 mm)

Here, the units on the different lines should really be the same, and different within the convert-to otherwise it makes it hard to work out whether the ranges are contiguous or not (of course they are, but if you make the units different on different lines it makes it messier and harder to read).

But convert can't quite do it, because the Thz, Ghz, and the nm, mm units are all slightly different. I don't think convert can do the 4 unit case? I can do it manually several different ways. No biggee I guess, it's probably not that common.GliderMaven (talk) 03:07, 12 April 2015 (UTC)

I noticed that when looking at examples of how frequency/wavelength are used. I don't think a fix will be coming soon—while convert could in principle cope with a range from 250 mm to 1.2 km there is no way for the current syntax to handle two input units. Please remind me in a month or two! Johnuniq (talk) 03:31, 12 April 2015 (UTC)

I might well create a wrapper around convert to do this perhaps.GliderMaven (talk) 03:38, 12 April 2015 (UTC)

Yes. Wrappers using partial/intermediate convert results (for example {{#invoke:Convert|unit}}) -DePiep (talk) 18:40, 12 April 2015 (UTC)

Main article: Radio frequency

Light comparison
Name	Frequency (Hz) (Wavelength)	Photon energy (eV)
Gamma ray	> 30 EHz (0.01 nm)	124 keV - 300+ GeV
X-Ray	30 PHz - 30 EHz (10 nm - 0.01 nm)	124 eV to 120 keV
Ultraviolet	30 EHz - 750 THz (0.01 nm - 400 nm)	3.1 eV to 124 eV
Visible	750 THz - 428.5 THz (400 nm - 700 nm)	1.7 eV - 3.1 eV
Infrared	428.5 THz - 300 GHz (700 nm - 1 mm)	1.24 meV - 1.7 eV
Microwave	300 GHz - 300 MHz (1 mm - 1 m)	1.24 µeV - 1.24 meV
Radio	300 MHz - 3 kHz (1 m - 100 km)	12.4 feV - 1.24 meV

seems to work albeit a bit overspecific right now. What's the best place to put the script?GliderMaven (talk) 20:57, 12 April 2015 (UTC)

Yep. Give'm a finger, they want the whole hand. -DePiep (talk) 22:46, 12 April 2015 (UTC)

Why would you put the wavelengths in brackets instead of in their own column? Hey, you know what, the energy of a photon is proportional to its frequency so how about a three-way conversion: frequency-wavelength-energy ... oh, no, the whole hand isn't enough, give us an arm. Jimp 20:58, 14 April 2015 (UTC)

I'm genuinely baffled by these ad hominen attacks.

Didn't we agree that the frequency and wavelength were equivalent for electromagnetic radiation, and that convert should put the wavelength is brackets???

I mean I can easily revert my edit, but how is it 'getting the whole hand' to use a new feature of convert as intended?

I agree that energy and frequency and wavelength are, to some degree equivalent for photons, but convert doesn't support that, and I have precisely zero intention to make it, in fact I'm against it.

I genuinely have no idea where you're coming from here.GliderMaven (talk) 01:05, 15 April 2015 (UTC)

I doubt anyone intended an ad hominen attack. Sorry if you feel like there has been one. As for me, I was only trying to be light-hearted about it but, of course, this is often hard to get across in text.

Yes, put the wavelength in brackets in prose but it seems to me that in a table conversions are easier to read when they're in a separate column. This is a common alternative supported by {{convert}} (one of a number of display options controlled by |disp=). It's just a question of what would work best in the table.

Jimp 05:54, 15 April 2015 (UTC)

Can read an ad hominem. I'm saying this: adding Herz=length^-1 was an exception to convert (which could be made 'working' quite easily). Then striving for more features relying on this exception (expanding the list of exceptions) is a time-soaker and module-corrupter. We are trying to get rid of these obscure options ("but it's working") still.

And I think Jimp's note to use |disp=table can be explored. (readers question: why "and different [units] within the convert-to" for the second value range? IMO, the same applies there - same units for ease of understanding). -DePiep (talk) 07:39, 15 April 2015 (UTC)

You might have a very good point except that the central issue you raise that striving for more features relying on this exception (expanding the list of exceptions) is a time-soaker and module-corrupter. is completely false. The script I wrote does not, in any way depend on the 'exception', as the same script can be used with every other unit that convert supports. I wasn't even asking for it to be integrated with convert, it's just that I had created it in User:GliderMaven space and asked where such scripts are normally kept.

I find that tables that have separate columns for different units for the same thing are usually wasteful of space and verbose, although they have their place if they're intended as a lookup table for conversion purposes.GliderMaven (talk) 11:05, 15 April 2015 (UTC)

It would just need to be moved into the Template namespace and for you to chhose an appropriate name for the template. -- WOSlinker (talk) 11:47, 15 April 2015 (UTC)

It's a proliferation of variant options, for stylistic preferences. Predictable: incomplete or incorrect documentation, no one knows how to handle it, no one knows where to find it. I had hoped we'd get rid of this and that sort. (and I do read a contradiction in the example cases: same units would be better to support sequence, right?). -DePiep (talk) 15:16, 15 April 2015 (UTC)

That was the first thing I tried, but it didn't look or work as well. Reading it, it gives you the uneasy feeling that they might not be contiguous, and then you have to do a lot of work to prove it to yourself they are.GliderMaven (talk) 02:09, 16 April 2015 (UTC)

What is it? 1. Do you need a list by "use the same unit in the column" or not? (so far I thought: yes, because that shows the sequence nicely, but your examples contradict this). 2. what result do you want to be shown, and what exactly do you need from {convert}? 3. Why (if at all) do you want a variant structured table? -DePiep (talk) 22:26, 17 April 2015 (UTC)

Look, convert only currently supports ranges to one, exact unit. But if the range is big enough you need more than one unit otherwise it looks stupid due to the orders of magnitude involved. I get that you are trying to think that it's just me being a bad person or something, but this table and many other electromagnetism articles have that issue, not only in the tables but in the text as well, and that's simply because many of the ranges used there are very big; many, many orders of magnitude.

Apparently this interferes with your Procrustean solutions for what scripts 'should' be written using convert. I'm trying to care about that, but frankly every single addition to this thread has made me care a little less.GliderMaven (talk) 23:32, 17 April 2015 (UTC)

"... me being a bad person or something" - again you making this into a PA? I asked content questions, some five or six by now, including about contradictions. As Johnuniq always asks on this page: A. What do you want, B. Where is it used? Bye. -DePiep (talk) 23:38, 17 April 2015 (UTC)

• Bien, tout et pardonne. Now what is your question again? Can you rephrase it, with core examples? -DePiep (talk) 21:39, 2 May 2015 (UTC)

MPG-e

I implemented Miles per gallon gasoline equivalent (mpg-e) in Module:Convert/extra, and it seems to be working (although one example was off-by-one, which I think is just rounding.) It's another of those dorky invert things, as with the normal mpgs unfortunately, because miles per gallon and kWh per miles are inversely related.

I'm still tinkering with it, but I know there's some new simpler convert stuff out there; is the way I've done it still the best way to be doing this kind of thing?GliderMaven (talk) 14:49, 29 April 2015 (UTC)

I'll admire the unit later, and read the article because I've been wondering about that topic lately. Re alternative procedures, you could experiment by editing Module:Convert/documentation/conversion data/doc and seeing what makeunits produces by clicking the purge link at the top of Module talk:Convert/makeunits. However, rather than experimenting on that page it would be better to use Template:Convert/unit sandbox (which is linked in the docs at the top of Module:Convert/extra). You would need to copy enough of the master list of units to the unit sandbox so your experiments work—any units referred to need to be defined. Once makeunits produces the unit definition, it would need to be copied to Module:Convert/extra. Since you are pushing what convert is capable of, any procedure will probably be tricky. If there is a specific convert which gives a strange result, post it and I'll have a look. Johnuniq (talk) 01:42, 30 April 2015 (UTC)

I'm not having any special difficulties with the mpg-e itself, that works very well:

{{convert|95|mpge|kWh/100 km|abbr=on}} = 95 mpg‑e (22 kW⋅h/100 km)

{{convert|95|mpge|kWh/100mi|abbr=on}} = 95 mpg‑e (35 kWh/100 mi)

but:

{{convert|95|mpge|kWh/100 km kWh/100mi|abbr=on}} = 95 mpg‑e ()

In other words, spaces in the 'to' units doesn't interwork with using spaces to separate multiple 'to' units. This is problematic with electric car related units because there's at least three different units, mpg-e, kWh/100 km and kWh/100 mi; so multiple converts are common. I've bodged it by using kWh/100km and kWh/100mi instead for the time being; but this does seem to be a bug.GliderMaven (talk) 15:49, 2 May 2015 (UTC)

Use + to make a combination when a unit code contains a space:

• {{convert|95|mpge|kWh/100 km+kWh/100mi|abbr=on}} → 95 mpg‑e (22 kW⋅h/100 km; 35 kWh/100 mi)

Johnuniq (talk) 02:18, 3 May 2015 (UTC)

Input thousands separator

I recently came across an edit where AWB changed an input number from "13450" to "13,450". I realize that the comma is accepted in the input field, but is it recommended? Is there any reason to make (or not make) this edit? Kendall-K1 (talk) 11:02, 29 April 2015 (UTC)

It makes no difference to convert whether the input number contains commas, so I think that including them is probably best because it makes values easier to check when editing. However, I wouldn't bother saving the edit if that was the only change—it's too trivial. Years ago no comma was allowed in the input, and some people got in the habit of removing commas when they insert a convert. That's not desirable because removing the comma makes checking later a little bit harder. If I correct mistake in a convert, I will sometimes insert commas as well. Johnuniq (talk) 11:50, 29 April 2015 (UTC)

Johnuniq, it would be useful to track things like {{convert|1,25|km2}} and {{convert|1.250,0|km2}}. Frietjes (talk) 14:30, 10 May 2015 (UTC)

I was hoping to avoid the overhead of the quite tedious checking that would be required. However, I just looked at my list of all converts in articles and found at least fifty badly formatted numbers that should be manually checked. I've put it on my todo for some thinking later. Johnuniq (talk) 11:13, 11 May 2015 (UTC)

Need conversions for measurement-unit-wide/thick/etc.

We need equivalents to "A 10-foot-long" corridor for thick, wide, deep, etc. Otherwise we get ungrammatical nonsense like a 10-foot (3.0 m) thick wall, and so on.--Sturmvogel 66 (talk) 22:10, 5 May 2015 (UTC)

@Sturmvogel 66: a {{convert|10|ft|m|adj=mid|-thick}} wall → "a 10-foot-thick (3.0 m) wall". Imzadi 1979 → 23:01, 5 May 2015 (UTC)

Tried it, didn't work. Must have done something wrong because your example certainly does. Thanks for the fast response.--Sturmvogel 66 (talk) 23:09, 5 May 2015 (UTC)

With adj=mid, convert shows an error if the output is omitted. You can either specify the output unit (as above) or put a blank output unit to use the default:

• {{convert|10|ft||adj=mid|-thick}} → 10-foot-thick (3.0 m)
• {{convert|10|ft|adj=mid|-thick}} → 10-foot ()

The last convert fails because template syntax means convert sees "-thick" as the output unit (as can be seen in the popup message when holding the mouse over the error message). Johnuniq (talk) 23:26, 5 May 2015 (UTC)

Module version 10

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:
  • fathom has its symbol restored to fathom as it was originally, instead of ftm (discussed here).
  • New unit cent to allow automatic per units like cent/acre (discussed (here).
  • New unit hertz for converting between frequency and wavelength of electromagnetic radiation in free space (discussed here).
  • Have removed some unused aliases (start of an effort to prune the full list of units).
  • Have removed most output combinations as automatic combinations now work (for example, "e3usgal e3impgal" works as an output unit, although "+" is needed as the separator if a unit code contains a space).
• Convert allows automatic combinations for the output unit, and the default for an automatic per unit can be an automatic combination.
• New rounding options: round=10 and round=50 (discussed here).
• If an output value is spelled (with spell=on), the default is abbr=off because showing a symbol for the output is undesirable when words are used for the number (discussed here).
• Rounding of the input value (for example, adj=ri0) works when spelling the value.

Rounding examples:

• {{convert/sandbox|12.8|to|57|m|ft}} → 12.8 to 57 metres (42 to 187 ft)
• {{convert/sandbox|12.8|to|57|m|ft|round=5}} → 12.8 to 57 metres (40 to 185 ft)
• {{convert/sandbox|12.8|to|57|m|ft|round=10}} → 12.8 to 57 metres (40 to 190 ft)
• {{convert/sandbox|12.8|to|57|m|ft|round=25}} → 12.8 to 57 metres (50 to 175 ft)
• {{convert/sandbox|12.8|to|57|m|ft|round=50}} → 12.8 to 57 metres (50 to 200 ft)

The option round=0.5 was suggested to produce the following (the second line is simulated using fixed text) but not done now as I'm not sure it would be desirable.

• {{convert|1+1/2|mi|km}} → 1+1⁄2 miles (2.4 km)
• {{convert|1+1/2|mi|km|round=0.5}} → 1 ¹⁄₂ miles (2.5 km)

Input rounding works when the value is spelled (the first line is simulated using fixed text to show what convert does now).

• {{convert|9.02|ft|m|adj=ri0|spell=in}} → nine point zero two feet (2.75 m)
• {{convert/sandbox|9.02|ft|m|adj=ri0|spell=in}} → nine feet (2.75 m)

Automatic output combination examples:

• {{convert/sandbox|12|kl|e3usgal e3impgal}} → 12 kilolitres (3.2×10^³ US gal; 2.6×10^³ imp gal)
• {{convert/sandbox|0.35|l/km|mpgus mpgimp}} → 0.35 litres per kilometre (6.7 mpg_‑US; 8.1 mpg_‑imp)
• {{convert/sandbox|0.35|l/km|l/100 km+mpgus+mpgimp}} → 0.35 litres per kilometre (35 l/100 km; 6.7 mpg_‑US; 8.1 mpg_‑imp)

Unit names with spell:

• {{convert/sandbox|2e3|km|mi|spell=in}} → two thousand kilometres (1,200 mi)
• {{convert/sandbox|2e3|km|mi|spell=on}} → two thousand kilometres (one thousand two hundred miles)

If ever needed, symbols can be used:

• {{convert/sandbox|12|cent/acre|cent/ha|spell=on}} → twelve cents per acre (thirty cents per hectare)
• {{convert/sandbox|12|cent/acre|cent/ha|spell=on|abbr=out}} → twelve cents per acre (thirty ¢/ha)

Module version history

• Version 1 December 2013
• Version 2 January 2014
• Version 3 April 2014
• Version 4 July 2014
• Version 5 September 2014
• Version 6 November 2014
• Version 7 December 2014
• Version 8 February 2015
• Version 9 February 2015

I've been slowly working on the above for some weeks and wanted to clean it up before starting on Jimp's idea that sortable=on should generate a sort key based on the SI unit appropriate for the current conversion (if any), per the discussion above. If it's a minor change that happens quickly I'll include it in this release. Otherwise, it should be done within a couple of weeks. After that I'm planning to see whether it would be worthwhile omitting some of the more esoteric and unused units (which can be quickly re-added if ever needed). Johnuniq (talk) 07:22, 6 April 2015 (UTC)

For the record: to make Hertz work in radiowaves, it is defined to be utype=length. -DePiep (talk) 19:40, 6 April 2015 (UTC)

It's inverse length, not length, following $f={\frac {c}{\lambda }}$. One peculiarity of inverse units in this context is that sorting frequencies will presumably be opposite ordered, because it will convert into wavelengths. This is a problem, since it's user visible, although less so if both are visible in the table, because the user will figure it out. There's a similar problem with miles/gallon versus l/km; convert picks one, and it's not necessarily going to be the 'most correct' whatever the user means by that.GliderMaven (talk) 21:02, 6 April 2015 (UTC)

Module version 10: sortable=on

The new sortable=on now works in the sandbox! Please test. I was gloomily pondering details of how to make a table to translate unit types to the wanted base unit (for example, a convert with units of type mass would have a sort key based on converting to kilograms), when a light went on—convert does not care if the base unit is valid or not, so no table is needed, and I just put in some code to make a fake base unit with scale = 1. There were a few minor complications that I think have been handled. I don't have an easy way to test this, so have put it in the sandbox for review. A side issue is that I wondered if there was an easier way to specify that sorting is wanted. I don't want to always output a sort key when using disp=table—I hate bloat and overhead—so I played around with ideas like disp=stable (stable = sorted table, yuck), disp=s.table and disp=sorted table. But if the last were used, you may as well write it properly as disp=sortable table and that is no better than disp=table|sortable=on. Any thoughts? Johnuniq (talk) 04:01, 7 April 2015 (UTC)

Hmm, to save anyone the trouble of reporting it, I'll mention that I had not thought much about the invert units, and sure enough the sort key for them is usually not correct. I'll think about that. Johnuniq (talk) 05:41, 7 April 2015 (UTC)

disp=tablesort or disp=sorttable? -DePiep (talk) 06:47, 7 April 2015 (UTC)

To consider: introduce new parameter (eg |table=) with options on, left, right, sortleft, sortright that replaces current + this new |disp=table_something. This way disp is freed for other settings. (Old options should stay for a while). -DePiep (talk) 06:54, 7 April 2015 (UTC)

Tip for testers: |debug=yes works with sort numbers (shows the hidden key). -DePiep (talk) 06:56, 7 April 2015 (UTC)

Here is an example using the new sortable=on:

• {{convert/sandbox|-1|yd|sortable=on|debug=yes}} → 3000085600000000000♠−1 yard (−0.91 m)
• {{convert/sandbox|0|ft|sortable=on|debug=yes}} → 5000000000000000000♠0 feet (0 m)
• {{convert/sandbox|9.87e-5|mi|sortable=on|debug=yes}} → 6999158842252800000♠9.87×10⁻⁵ miles (1.588×10⁻⁴ km)
• {{convert/sandbox|2|ft|6|in|sortable=on|debug=yes}} → 6999762000000000000♠2 feet 6 inches (0.76 m)
• {{convert/sandbox|1|yd|sortable=on|debug=yes}} → 6999914400000000000♠1 yard (0.91 m)
• {{convert/sandbox|1|yd|2|ft|sortable=on|debug=yes}} → 7000152400000000000♠1 yard 2 feet (1.5 m)
• {{convert/sandbox|99|chain|sortable=on|debug=yes}} → 7003199156320000000♠99 chains (6,500 ft; 2,000 m)
• {{convert/sandbox|81|km|sortable=on|debug=yes}} → 7004810000000000000♠81 kilometres (50 mi)
• {{convert/sandbox|79|mi|yd|sortable=on|debug=yes}} → 7005127138176000000♠79 miles (139,000 yd)
• {{convert/sandbox|7|Mm|sortable=on|debug=yes}} → 7006700000000000000♠7 megametres (4,300 mi)
• {{convert/sandbox|1.2e4|mi|sortable=on|debug=yes}} → 7007193121280000000♠1.2×10⁴ miles (1.9×10⁴ km)

Those option suggestions look good; will think later. Johnuniq (talk) 07:36, 7 April 2015 (UTC)

I put a fix in the sandbox, and I think invert units are working now, although I'll have to do more testing and thinking.

• {{convert/sandbox|3.8|kHz|km|sortable=on|debug=yes}} → 7004788927521052631♠3.8 kilohertz (79 km)
• {{convert/sandbox|3.5|kHz|km|sortable=on|debug=yes}} → 7004856549880000000♠3.5 kilohertz (86 km)

A small issue that I plan to ignore is that the fuel efficiency units sort in descending order of efficiency. The following are in order from most efficient to least efficient.

• {{convert/sandbox|9|l/100km|l/km|disp=out|sortable=on|debug=yes}} → 6992900000000000000♠0.090 l/km
• {{convert/sandbox|9|mpgimp|l/km|disp=out|sortable=on|debug=yes}} → 6993313867707035357♠0.31 l/km
• {{convert/sandbox|1|l/km|l/km|disp=out|sortable=on|debug=yes}} → 6994100000000000000♠1.0 l/km
• {{convert/sandbox|1|mpgimp|l/km|disp=out|sortable=on|debug=yes}} → 6994282480936331822♠2.8 l/km
• {{convert/sandbox|9|l/km|l/km|disp=out|sortable=on|debug=yes}} → 6994900000000000000♠9.0 l/km
• {{convert/sandbox|9|usgal/mi|l/km|disp=out|sortable=on|debug=yes}} → 6995211693124999999♠21 l/km

Johnuniq (talk) 10:55, 7 April 2015 (UTC)

I think it would be best to just have a 'invertsortable' flag to invert or negate the sortable value when the editor wants to in these or other cases. Perhaps they actually want to sort by wavelength, or they want to sort by either mpg or l/km.GliderMaven (talk) 12:32, 7 April 2015 (UTC)

Table sorting with data-sort-value

Just wondering if |sortable=on should be using the HTML5 data-sort-value attributes as mentioned at Help:Sorting#Specifying a sort key for a cell rather than hidden data? -- WOSlinker (talk) 12:53, 7 April 2015 (UTC)

• {{convert/sandbox|3.8|kHz|km|sortable=on}} → data-sort-value=7004788927521052631|3.8 kilohertz (79 km)

OK, I missed seeing that, which seems to have been added around July 2013. Convert just emulates {{ntsh}}, but it would be good to clean it up to do the "right thing". However, I need to know what the right thing for align is, and how it interacts with data-sort-value. Following is the current output from sandbox convert—each of the two examples outputs two lines.

{{convert|2|ft|in|disp=table}}
style="text-align: right;"|2
|style="text-align: right;"|24

{{convert|2|ft|in|disp=table|sortable=on}}
style="text-align: right;"|<span style="display:none">6999609600000000000</span>2
|style="text-align: right;"|<span style="display:none">6999609600000000000</span>24

Help:Tables is not helpful regarding the alignment of cell content, however I see a couple of examples with just align="right" rather than the text-align stuff above. Should convert output the following? Can parameters be appended as in the second example? Should there be a semicolon delimiter?

{{convert|2|ft|in|disp=table}}
align="right"|2
|align="right"|24

{{convert|2|ft|in|disp=table|sortable=on}}
align="right" data-sort-value="6999609600000000000"|2
|align="right" data-sort-value="6999609600000000000"|24

Johnuniq (talk) 02:46, 8 April 2015 (UTC)

I think the way to do it should be with the style attribute (see Wikipedia:HTML5#Tables_2).

Test	Value1	Value2
Test4	4	48
Test2	2	24

Although you may also want to consider adding some additional params, stylein & styleout to allow more flexibility for styling the table cells generated by convert. -- WOSlinker (talk) 06:20, 8 April 2015 (UTC)

{{convert|2|ft|in|disp=table|stylein=background-color:yellow;|styleout=color:red;}}
style="text-align:right;background-color:yellow;"|2
|style="text-align:right;color:red;"|24

{{convert|2|ft|in|disp=table|sortable=on|stylein=background-color:yellow;|styleout=color:red;}}
style="text-align:right;background-color:yellow;" data-sort-value="6999609600000000000"|2
|style="text-align:right;color:red;" data-sort-value="6999609600000000000"|24

IIRC, align="right" is deprecated HTML code. At least one should use style="text-align:right". Can WOSlinker confirm this? -DePiep (talk) 06:39, 8 April 2015 (UTC)

Some doubts: When building a table, having to consider the split pipes is a complication, especially when they don't show in code. (I mean the isolated | now showing up in there). Not every table writer knows or oversees that format. All things equal, I'd prefer a single-cell input (well, making two-column output).

Another thing: with HTML, why not write using span & attrribute, like <span data-sort-value="6999609600000000000">24</span>{{!}} val2 goes here. That would make convert independent from the between-pipes table formatting. -DePiep (talk) 07:00, 8 April 2015 (UTC)

Re align="right": Thanks for the pointer—in my naivety I thought that stuff was magic wikitext syntax, but everything mentioned here appears to be plain html that MediaWiki merely passes to the html table. Searching shows that align=xxx is highly deprecated. I don't follow the other comment as the pipes are essential because convert is generating two cells when convert is placed in a single cell. I would prefer to follow the Help:Sorting docs rather than try other approaches. Johnuniq (talk) 04:05, 9 April 2015 (UTC)

OK with me and it will work. But I do not like this making it more dependent on wiki-table code (pipes; between-pipe style additions instead by tagging; does newline cause errors?). DePiep (talk) 21:27, 11 April 2015 (UTC)

I'm planning to implement WOSlinker's proposal, probably without the stylein=xxx and styleout=xxx ideas for now, although I will think about how to cope with their possible inclusion in the future. However, there is a major complication: in January 2015, there were 16,000 converts in articles with sortable=on, and no converts used sortable=in or sortable=out. The complication is that only 2,720 of the 16,000 use disp=table or disp=tablecen, so there are 13,280 converts with sortable=on only. An example is at Madeira#Political divisions where possibly the table should be done differently, but the point is that convert can't change in a way that would break those many existing usages. From my limited understanding of tables, I conclude that convert will need to behave as it does now (using the {{ntsh}} technique of a hidden sortkey) when sortable is used alone, with no table options. Only when one of the table options is used can convert use data-sort-value. Before I get too lost in the code, WOSlinker might like to check my conclusion, and Jimp might like to check whether the sort key that is now produced by sortable=on is likely to overcome prior problems (see the above, but in brief, convert makes a fake unit with scale 1 and calculates the sort key from the value obtained by converting the input to the fake unit). Given that they appear to be unused and unhelpful, I'm tempted to make sortable=in and sortable=out equivalent to the new sortable=on to simplify the code. Johnuniq (talk) 04:05, 9 April 2015 (UTC)

Yes, I'd agree that the data-sort-value can only be used when disp=table or disp=tablecen, and if they are not used then the hidden sortkey is the only method that can be used. -- WOSlinker (talk) 07:03, 9 April 2015 (UTC)

@WOSlinker: convert/sandbox now implements the above, including stylein and styleout. I think it's working, but further checks would be good. Following is a table with styles as a demo. The first row uses the following two converts:

{{convert/sandbox|28.1|m|ftin|disp=table|sortable=on|stylein=background-color:LightSalmon|styleout=color:red}}
{{convert/sandbox|47.5|kg|lb|disp=table|sortable=on|stylein=background-color:YellowGreen|styleout=color:green}}

	Length		Weight
	metres	ft in	kg	lb
Lorem ipsum	28.1	92 ft 2 in	47.5	105
Dolor sit amet	9.9	32 ft 6 in	74.1	163
Consectetur	38.2	125 ft 4 in	31.5	69
Adipisicing elit	18.7	61 ft 4 in	52.7	116

Johnuniq (talk) 11:55, 12 April 2015 (UTC)

I've had a try with the sandbox version and it all looks good. -- WOSlinker (talk) 14:58, 12 April 2015 (UTC)

Deprecated options

As preparation for changes to use data-sort-value for sort keys, I have put a significantly refactored version in the sandbox. Since sortable=in and sortable=out were not used in January 2015, and as I can't think of any reason for them with the new sortable=on behavior, I have removed the code handling in + out and made the options equivalent to sortable=on, and marked them as deprecated. That required a method for reporting deprecated options so I have implemented something which shows a very small message (a single asterisk), and puts articles with a deprecated option in a tracking category (Category:Convert invalid options). Several other options have also been marked as deprecated per previous discussions.

Examples of each deprecated option follow. The asterisk links to a help page with a tiny bit more information (mainly how to ask a question), although only alert editors would notice the link—I might dust off AWB to fix them from the tracking category. Moving the mouse over the asterisk shows a popup message with details on which option is the problem. The number shows how many converts in articles used the option in January 2015.

• 1 × {{convert/sandbox|12|km|in|abbr=comma}} → 12 kilometres (470,000 in)
• 2 × {{convert/sandbox|12|km|in|adj=nocomma}} → 12 kilometres (470,000 in)
• 1 × {{convert/sandbox|12|km|in|disp=nocomma}} → 12 kilometres (470,000 in)
• 56 × {{convert/sandbox|12|km|in|adj=flip}} → 12 kilometres (470,000 in)
• 58 × {{convert/sandbox|12|km|in|disp=flip5}} → 12 kilometres (470,000 in)
• 40 × {{convert/sandbox|12|km|in|disp=/}} → 12 kilometres (470,000 in)
• 65 × {{convert/sandbox|12|km|in|disp=s}} → 12 kilometres (470,000 in)
• 10 × {{convert/sandbox|12|km|in|disp=slash}} → 12 kilometres (470,000 in)
• 2 × {{convert/sandbox|12|km|in|disp=2}} → 12 kilometres (470,000 in)
• 0 × {{convert/sandbox|12|km|in|disp=u2}} → 12 kilometres (470,000 in)
• 1 × {{convert/sandbox|12|km|in|near=5}} → 12 kilometres (470,000 in)
• 0 × {{convert/sandbox|12|km|in|sortable=in}} → 12 kilometres (470,000 in)
• 0 × {{convert/sandbox|12|km|in|sortable=out}} → 12 kilometres (470,000 in)

The following options are deprecated in the documentation, but not marked as such by convert because there are too many to handle at the moment.

• 2,370 × disp=5
• 21,588 × disp=flip

Any opinions on the desirability of articles showing the asterisk until the converts are cleaned? I wanted to show something for alert editors, particularly with the in/out sortable options which now do not do what they promise. I'm planning to release this with version 10 in due course. Johnuniq (talk) 10:04, 11 April 2015 (UTC)

Nice. The asterisk might be a ^{[maintenance word]} as is wiki style, but it's not that important (they'll all be gone quite soon). Template:Convert#Deprecated_options notes the alternatives. I'm surprised that some deprecations are omitted here, especially the non-MOS ones. -DePiep (talk) 10:54, 11 April 2015 (UTC)

Would it be prudent to make it ^[*] to more closely follow wiki style and avoid the possibility that someone might mistake the asterisk for a "power"? —sroc 💬 11:23, 11 April 2015 (UTC)

I tried previewing various things, including that, but I'm preferring the simple asterisk at the moment because anything else seems to draw too much attention to what is essentially trivia. Here is a sentence with 12 kilometres (7.5 mi) and some more words before 12 kilometres (7.5 mi) to show two styles in a paragraph, using fixed wikitext. I see two reasons for wanting some kind of visual marker, with the main reason being that it helps someone who is cleaning out the tracking category to find the text, and searching for ")*" will usually find the problem; the second reason is to give some feedback for an editor who is carefully checking the result. I think most people won't even see the asterisk, and as DePiep says, they won't be there long, although there will be a few days at first when they are visible as it will take some time to methodically track them. Johnuniq (talk) 03:21, 12 April 2015 (UTC)

The only deprecated options not listed above are abbr=mos (11 occurrences) and adj=1 (16 occurrences) and some range separators. I omitted the two options because I didn't want to take the time at this stage to look at them to see how they were used, and the module does not yet have a way to notice deprecated ranges. The options listed above can easily be replaced with recommended options, with no change to how the result appears. There are a lot of under-the-hood changes in this version and I would prefer to leave style issues for later. Johnuniq (talk) 03:21, 12 April 2015 (UTC)

"look at them to see how they were used" ??? is not needed because that's the job for the editor who visits the page when tagged & categorised. Unless one wants to wiggle with the deprecation and, sigh, reopen an old conclusion. -DePiep (talk) 07:47, 12 April 2015 (UTC)

Trying to re-explain what I mean to say (in case my language is limiting the clarification): I think the deprecated non-MOS options are past discussion. They can be deprecated next step: mark or remove from code. So it is strange that those were not added to the detailed deprecations list here. My surprise (or better: fear) is that their topics, the talkpage discussion, will be re-opened once more: "are there really, really non-MOS? Are we sure?". It is this walking backwards (by Johnuniq, no less) that makes me throw up my arms: what else is needed?

As for the deprecated range separators that "the module does not yet have a way to notice deprecated ranges" - the same. They are deprecated, non-MOS formats. Just remove them from code, and their articles will be maint categorised for update -- anyway.

This point we are now is that Johnuniq wants to save extra judgement space for themselves on MOS issues. I can not prevent that of course, because my authority in this template is below J'nuniqs -- no mistake. However, I find it getting into the area of "useless to discuss". And: as for me alone, I'm willing to step aside. But I remember some bright contributions by Jimp that helped us too - now tresholded by Johnuniq.

Having said this, I state that I have no single blocking reason to move into version 10. ping @Jimp:, @Johnuniq:. -DePiep (talk) 17:34, 22 April 2015 (UTC)

• Done. The modules have now been updated. The deprecated warnings will start showing up in the tracking categories, but I've reminded myself how to use AWB and will get around to fixing any problems, although I'm busy elsewhere and may take my time. Johnuniq (talk) 00:12, 28 April 2015 (UTC)

OK. If I understand the process right: once the tracking cat's are empty, the "deprecated" notions can be removed from documentation. Singular exceptions to watch etc. -DePiep (talk) 22:13, 28 April 2015 (UTC)

I copy/paste from the section below:

"Re the documentation per your comment above: Yes, I think the deprecated options should now be removed from the documentation. May as well remove all items marked as deprecated in the docs, even the ones which still work without a warning asterisk. Johnuniq (talk) 23:25, 28 April 2015 (UTC)"

I do not get this 'may as well'. My doc attitude is: if it exists and works, an editor might meet it in an article, and so must be able to find it in the /doc.

Only after cleaning up (from articles & from module code) it can be removed legally and correctly from /documentation. Not an other way around. That's the big line. -DePiep (talk) 00:10, 29 April 2015 (UTC)

I am confused. I was preparing the removal from documentation (e.g. of the option |abbr=nocomma, already redmarked in the documentation and now to be removed, I thought). Because, this paragraph described how the removal of deprecated options would happen (in new code: 1. categorize usages, 2. edit to remove bad parameter from article (use the category), 3. remove from documentation completely, 4. Gone). However, I just discovered that the deprecated parameter is still present in code & working as before. In this case it can not be removed from the documentation of course. A pity so much extra energy was spend on this intermediate, useless step. When the deprecations are totally removed from code, ping me and I will adjust the documentation. Not before. -DePiep (talk) 21:21, 10 May 2015 (UTC)

That's good, because it is reasonable for documentation to include deprecated options for completeness. It's common for "deprecated" to mean that an option still works, although an alternative is preferred, and that's what I meant. If removing the deprecated options from the documentation was useful (perhaps because it simplified the docs), it would also be reasonable to remove them now—I think there are points in favor of each strategy. Johnuniq (talk) 08:59, 11 May 2015 (UTC)

I meant to say that these deprecated options should have been out of the Lua code already. The asterisked maintenance-link is an intermediate step that only costs energy (for you especially), and does not help other editors. We'd have managed with the regular maint-cat linking. -DePiep (talk) 19:32, 18 May 2015 (UTC)

Maint cat notes in article

Do I see this right? Today, after the update Convert into v10, I see:

Article Lexus ES [1] is listed in Category:Convert invalid options (which totals 9 articles now). But: today I can not find the offending convert in the plain article page no more, as it was before. That leaves me to research all {{Convert}} instances apart. Should I cry like a baby? Or cry like a grown up? -DePiep (talk) 22:40, 28 April 2015 (UTC)

The deprecated warning is purposefully very small so trivial issues do not damage the appearance of articles. For most cases, searching for )* or *) will find the problem. However, it is probably best to leave those for me because I have got AWB worked out reasonably well and it can easily do a substantial number of updates, including disp=flip and disp=5 which are not flagged as deprecated because there are too many of them (this edit which I just did to Lexus ES is an example). I'll work the other problem options down to a smaller number in due course, before the next release deprecates those options.

Re the documentation per your comment above: Yes, I think the deprecated options should now be removed from the documentation. May as well remove all items marked as deprecated in the docs, even the ones which still work without a warning asterisk. Johnuniq (talk) 23:25, 28 April 2015 (UTC)

Without much ado, I say requiring a dedicated AWB process (or regex) is not good. This way. Before, any editor could improve a maint categorized article etc. -DePiep (talk) 00:02, 29 April 2015 (UTC)

You can do a search for them, for example disp=flip, which produces a list of nearly 8000 pages. -- WOSlinker (talk) 21:06, 18 May 2015 (UTC)

... which uses REGEX too. The point is that the maintenance-categorizing worked all right, into the detail of noting the exact offending {convert} location in the article. Not any more. Now we have an intermediate less-useful energy-absorbing asterisk, to no improvement. The problem is that Johnuniq refuses to remove from Lua code long-time deprecated parameter options. Including MOS-violating options. We can even expect re-opening of earlier concluded discussions. -DePiep (talk) 22:18, 18 May 2015 (UTC)

Listing order in temperature range conversions

When using this template with temperature ranges (e.g., {{convert|-10|to|-15|C|F}}), the output is sorted presented from high to low, just like the input→−10 to −15 °C (14 to 5 °F). Problem is, the input uses negative values (so high-to-low makes sense), while the output is positive. I understand that the output matches the input, but in these kind of cases the result looks kind of odd. Thoughts?—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); May 8, 2015; 16:59 (UTC)

If the order in your example "-10 to -15 °C" makes sense in an article, then the °F range makes similar sense being high-to-low. ("-10" and "14" are the high values). I see no reason to flip the order in the two ranges. -DePiep (talk) 19:07, 8 May 2015 (UTC)

It only looks odd until you think about it for a bit. The usual way to express a range is from low to high (though there may be cases where you'd want to put it the other way); so, instead of "−10 to −15 °C (14 to 5 °F)", I'd suggest "−15 to −10 °C (5 to 14 °F)". "−10 to −15 °C" may look odd but, again, it's an illusion; once you've given it a second's though it makes perfect sense. If you really want something to ponder, get your head around this one. Should {{convert|12|to|16|mpgimp|L/100km|abbr=on}} give "12 to 16 mpg_-imp (24 to 18 L/100 km)" (as it does) or "12 to 16 mpg_-imp (18 to 24 L/100 km)"? I don't see any good answer to this (though I'm more in favour of the former, i.e. the status quo). Jimp 17:01, 10 May 2015 (UTC)

Interesting case indeed (I'd favor the status quo too, thinking that the changed order would introduce as much confusion as it would remove -- and probably more). -DePiep (talk) 21:01, 10 May 2015 (UTC)

I'm confused by the initial post. The output isn't sorted, it's just presented in the order given, right?

• {{convert|-10|to|-15|C|F}} → −10 to −15 °C (14 to 5 °F) [high to low]
• {{convert|-15|to|-10|C|F}} → −15 to −10 °C (5 to 14 °F) [low to high]

In each case, the converted values are presented in the same order so that the first converted value refers to the first original value and the second converted value refers to the second original value, i.e., −10 °C (14 °F) and −15 °C (5 °F). This is the way it should be, as this is intuitive. This also makes sense in prose:

• Improvements from the 2014 model to the 2015 model increased mileage from {{convert|12|to|16|mpgimp|L/100km|abbr=on}}. → Improvements from the 2014 model to the 2015 model increased mileage from 12 to 16 mpg_‑imp (24 to 18 L/100 km).

This logically makes sense; it wouldn't if the converted values were flipped. To be fair, this example would be rephrased for clarity:

• Improvements to the 2015 model increased mileage to {{convert|16|mpgimp|L/100km|abbr=on}} compared with the {{convert|12|mpgimp|L/100km|abbr=on}} from the 2014 model. → Improvements to the 2015 model increased mileage to 16 mpg_‑imp (18 L/100 km) compared with the 12 mpg_‑imp (24 L/100 km) from the 2014 model.

—sroc 💬 16:11, 16 May 2015 (UTC)

"Sorted" in my original post was an unfortunate choice of words; I've changed it to "presented". The crux of the matter, however, remains unaddressed. Yes, the output is presented in the same order as the input (a totally expected behavior), but temperature ranges are normally presented low-to-high for positive (or mixed) values and high-to-low for negative values. I don't recall often seeing a range of negative temperatures presented in the low-to-high order (such as −15..−10°C). I won't claims it's never written that way, but to my eye at least it simply looks odd, hence my original question. (The mpg vs L/100km problem seems to be a different animal, since 24 to 18 L/100 km is technically still "increased mileage" and reversing those numbers would make no sense whatsoever).—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); May 20, 2015; 18:33 (UTC)

@Ezhiki:

The temperature at the site increased from −15 to −10 °C (5 to 14 °F) over 24 hours.

The temperature at the site decreased from −10 to −15 °C (14 to 5 °F) over 24 hours.

Both sentences are correct, and changing the output order would make either incorrect. Imzadi 1979 → 00:42, 21 May 2015 (UTC)

Those sentences, yes, but the ones I am thinking about go something like "the average January temperature in this region is −10 – −15 °C (14–5 °F). See how weird that looks?—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); May 21, 2015; 01:02 (UTC)

Ezhiki: temperature ranges are normally presented [...] high-to-low for negative values. Is that so? If you can convince WP:MOSNUM (they'll ask for sources), then do come back and tell us. -DePiep (talk) 02:33, 21 May 2015 (UTC)

In that example, you should avoid using the dash when there are negative figures, per MOS:ENDASH: the average January temperature in this region is −15 to −10 °C (5 to 14 °F). And yes, the lower figure—i.e., −15 °C (5 °F)—should come first. —sroc 💬 04:31, 21 May 2015 (UTC)

I am yet to see a source which lists the lower figure first in the range of negative temperatures. On the other hand, most of the sources I am working with are in Russian (and in Celsius), so perhaps this is why the ordering looks weird to me but not to y'all. I'm going to shelf this for now, but will start making notes the next time I stumble upon an appropriate source and perhaps revisit this in the future. Thanks for your responses. Cheers,—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); May 21, 2015; 17:25 (UTC)

Possible Rounding Error

See https://en.wikipedia.org/wiki/Talk:Washington,_D.C.#Conversion_to_Sq._Kilometres_of_Original_Size_of_DC. — Preceding unsigned comment added by SarahTehCat (talk • contribs) 17:59, 20 May 2015 (UTC)

This is not an error. The template is designed to avoid false precision. Options exist for adjusting the rounding (see the doc). Jimp 08:16, 21 May 2015 (UTC)

Also, see the first question and answer in the FAQ at the top of this page. Johnuniq (talk) 11:44, 21 May 2015 (UTC)

Okay. Thanks for the clarification. SarahTehCat (talk) 20:54, 26 May 2015 (UTC)

Template:Unit redirect here?

I noticed there exists a Template:Unit that redirects to {{Convert}}. With ~125 articles using. Shall we deprecate it, and replace occurrances? -DePiep (talk) 02:39, 27 May 2015 (UTC)

I think that is something to do with making it easier when copying text from frwiki, and possibly one or two others. Frwiki spells it "Modèle:Unité" but "Template:Unit" redirects to that; I think it's for formatting, not conversion. At any rate, people translate text from there to use here, and they change the template to "unit" which often works with convert. I think occurrences should be replaced with convert, with a check for each that it is doing something useful. Not sure about eventually deleting it. Johnuniq (talk) 05:42, 27 May 2015 (UTC)

I just remembered Template:Unité (also redirects to convert), and that's probably where I learned about the frwiki thing. Johnuniq (talk) 10:31, 27 May 2015 (UTC)

Delete it and delete it quick. The template {{unit}} on the French wiki does not behave like {{convert}} at all.

• {{unit|28|km|2}} gives "28 km²"
• {{unit|23|m|3}}/s gives "23 m³/s"

Hence just copying it from French turns areas and volumes into lengths. Jimp 12:16, 27 May 2015 (UTC)

I have seen it used more intelligently than that, but don't have any objection if it is deleted. I happened to notice another case after writing the above, and perhaps SimonTrew would like to comment. Johnuniq (talk) 12:33, 27 May 2015 (UTC)

@Johnuniq:. Sure. I did not translate this as such, I've been tidying it today (it was at WP:PNTCU, pages needing cleanup after translation). I had a look after you commented here but can't see exactly where you mean: I certainly added some {{convert}}s, did I cock one up somehow? User:Jimp is right, and if (presumably) whoever did the initial translate took it as a false friend (or more likely Google translate did) and translated fr:Template:Unité as {{unit}} then that is definitely wrong. "Unité" is essentially {{formatnum}} with the ability to attach a unit name, but does not do conversion. Si Trew (talk) 13:41, 27 May 2015 (UTC)

I can't see any use of this that you changed with your edit. You've lost me, a bit, I'm afraid. I do realise there was an extra bar in one convert template (which shouldn't matter), but that's different: No use of {{unit}} as far as I can tell; it's not on [2]. Si Trew (talk) 13:56, 27 May 2015 (UTC)

The extra bar matters to convert because it deals with a lot of strange parameters and so is fussy about what-goes-where, and that convert was giving an error. However, I was not commenting about that. Sorry that I didn't make it clearer why I pinged you—it's because you created Template:Unité. Re the unit/unité templates: I don't mind what happens to them, but I have seen several cases where they work quite well when text is copied from frwiki. For example, frwiki might say that something is 6 km long using that template for formatting. When that is copied here, it automatically converts the km to miles—frwiki does not want that, but we do. However, it is dubious because of the problem Jimp mentions above. Johnuniq (talk) 11:28, 28 May 2015 (UTC)

Template:Unit listed at Redirects for discussion

An editor has asked for a discussion to address the redirect Template:Unit. Please participate in the redirect discussion if you have not already done so. -DePiep (talk) 23:15, 27 May 2015 (UTC)

I was wondering whether to do that, considering the comment above about it being used in approx. 125 pages. I've responded there referring back to here. Si Trew (talk) 04:16, 28 May 2015 (UTC)

@DePiep: I've fixed above from "Tempate:Unit" to "Template:Unit" in two places. I hope that's OK. Si Trew (talk) 04:17, 28 May 2015 (UTC)

Thanks. -DePiep (talk) 10:50, 28 May 2015 (UTC)

• Added for RfD: Template:Units, similar situation (now 30 transc's in articles). -DePiep (talk) 10:50, 28 May 2015 (UTC)
• Added for RfD: Template:Unité, similar situation. -DePiep (talk) 17:56, 29 May 2015 (UTC)