Template talk:Convert/Archive April 2015

Comma as decimal mark

Rejected - cannot mix up period and comma in one wiki. Per MOS. -07:23, 3 April 2015 (UTC)

Is there an option to use the comma as a decimal mark instead (South African English uses a comma instead of a period), for example: 22,5 km (twenty two and a half kilometers). In an article about South African towns/villages it looks kind of weird. Thanks in advance. Servien (talk) 18:49, 24 March 2015 (UTC)

Interesting point (pun comes free). I have put up a question at MOS talk. I don't expect a definite MOS rule, but people there usually have lots of ideas. -DePiep (talk) 19:34, 24 March 2015 (UTC)

Convert is capable of using different decimal marks and thousand separators, but I think applying some kind of WP:ENGVAR to these options would be very confusing. One problem is that you have to consider the input to convert as well as the outputs produced. I put a quick demo in {{convert/sandbox2}} demonstrated here:

• {{convert|12345.678|m|m}} → 12,345.678 metres (12,345.678 m)
• {{convert/sandbox2|12345.678|m|m}} → 12.345.678 metres (12.345.678 m)
• {{convert/sandbox2|12345,678|m|m}} → 12.345,678 metres (12.345,678 m)
• {{convert|1.234|m|ft}} → 1.234 metres (4.05 ft)
• {{convert/sandbox2|1.234|m|ft}} → 1.234 metres (4.049 ft)

These results show the problem pretty well. Sandbox2 is using a comma for the decimal mark and a dot for the group separator. Johnuniq (talk) 22:06, 24 March 2015 (UTC)

Yes, there is a definite rule to not use commas. See WP:DECIMAL. Dicklyon (talk) 04:15, 25 March 2015 (UTC)

Agree. We can have "football" and "soccer" in this wiki to mean the same, but not "1,234" and "1.234" to mean the same. -DePiep (talk) 22:21, 25 March 2015 (UTC)

Protected edit request on 31 March 2015

Cancelled Wrong talkpage. -DePiep (talk) 07:24, 3 April 2015 (UTC)

Dear Sir / Madam I am conservatively confident that spelling for the name of this river in English language is incorrect (as well as in French). Sofore I would like to ask you to change the of way how it is written on Wikipedia from Lyamin to Liamin. If you would like to get more information about grounds of my request please do not hesitate to contact me any time. Best regards costamara — Preceding unsigned comment added by Costamara (talk • contribs) 05:40, 31 March 2015 (UTC)

@Costamara: This is the talk page for the {{convert}} template; your comment belongs at Talk:Lyamin River. Please also remember to sign your post by typing four tildes (~~~~) at the end of your posts on talk pages. —sroc 💬 06:45, 31 March 2015 (UTC)

Think about it

This piece in the documentation doesn't make sense:

Sorting

Use both |disp=table |sortable=on to produce table columns (pipe symbols), with sortable table column. As of January 2013, only the first (lefthand) column will sort (improvements pending).

The second sentence: of course subsequent columns are sorted the same as the first, as they refer to the same entity. Unless there is some sort of random or inverse conversion method I've not come across before!

-- Unbuttered parsnip (talk) mytime= Wed 12:18, wikitime= 04:18, 4 March 2015 (UTC)

The documentation was outdated, I rewrote it: Template:Convert/doc#Sorting (the improvement has been added to {{convert}}). Your second note, that the sorting would be/should be the same because it is the same input, has two nuances:

1. Yes the source value is the same, but WP:TABLESORT must be instructed to use the numeric value. Otherwise, it would sort like 1-11-2 etc. Adding the hidden sortkey to each column solves this.

2. Parameters like |sigfig= can alter the value of an output parameter. That may imply a different sort order (far fetched, this).

Let us know if you experience troubles or errors with this. -DePiep (talk) 10:48, 4 March 2015 (UTC)

It's nice to have that sorted but think about this

The sort key used is based on the input number only and the same sort key is used for both columns. This would be fine if the template is used in the same way for every column but it may not be the case. For example, some rows might convert from feet to metres whilst others convert the other way and others still might have both feet and metres entered without using the template for conversion as in the example below.

{| class="wikitable sortable" |- !m !ft |- |{{convert|3.0|m|ft|0|disp=table|sortable=on}} |- |{{convert|11|ft|m|disp=table|sortable=on|order=flip}} |- |align=right|{{nts|3.7}} |align=right|{{nts|12}} |- |{{convert|4.0|m|ft|0|disp=table|sortable=on}} |- |{{convert|14|ft|m|disp=table|sortable=on|order=flip}} |- |align=right|{{nts|4.6}} |align=right|{{nts|15}} |}
		Result		Result, showing the hidden sort keys (as of 16 March 2015)
		m ft 3.0 10 3.4 11 3.7 12 4.0 13 4.3 14 4.6 15		m ft 70003000000000000003.0 700030000000000000010 70011100000000000003.4 700111000000000000011 70003700000000000003.7 700112000000000000012 70004000000000000004.0 700040000000000000013 70011400000000000004.3 700114000000000000014 70004600000000000004.6 700115000000000000015

As we can see this messes the sorting up entirely. Jimp 07:19, 16 March 2015 (UTC)

Different hidden key formats causes the disruption, so it is not an in-convert issue (see cat:sort templates). For now, there is no need to change the {convert} sortkey. I've been struggling with numbers in this table (no {convert} used), still having to try better minus-sortings.

I was thinking: we could use a generic sort template for numbers, that requires the input value only (editors/source value, to be shown) and then creates the sortkey under the bonnet. IMO this created sortkey best be the {convert} solution, being most universal. That would be a split-out of this function(s) into a separate lua module. Even more universal would be when the code handles text sorting too. No editor needs to count and fill zero's, and then having to research the minus/plus/none prefix situations. -DePiep (talk) 07:42, 16 March 2015 (UTC)

I think, perhaps, by trying to make too many points at once I might not have made any of them clear enough. Sorry about that. Yes, different templates produce different hidden sort keys and this is a problem. (It's a problem worth addressing but not specifically on this page.) However there is a problem to discuss with respect to {{convert}}. Let me break it down like this.

Case A {{convert}} vs {{nts}}
{| class="wikitable sortable" |- !m !ft |- |{{convert|3.0|m|ft|0|disp=table|sortable=on}} |- |align=right|{{nts|3.7}} |align=right|{{nts|12}} |- |{{convert|4.0|m|ft|0|disp=table|sortable=on}} |- |align=right|{{nts|4.6}} |align=right|{{nts|15}} |}
		Result		Result, showing the hidden sort keys (as of 16 March 2015)
		m ft 3.0 10 3.7 12 4.0 13 4.6 15		m ft 70003000000000000003.0 700030000000000000010 70003700000000000003.7 700112000000000000012 70004000000000000004.0 700040000000000000013 70004600000000000004.6 700115000000000000015

Case B {{convert| ... |order=flip}} vs {{nts}}
{| class="wikitable sortable" |- !m !ft |- |{{convert|11|ft|m|disp=table|sortable=on|order=flip}} |- |align=right|{{nts|3.7}} |align=right|{{nts|12}} |- |{{convert|14|ft|m|disp=table|sortable=on|order=flip}} |- |align=right|{{nts|4.6}} |align=right|{{nts|15}} |}
		Result		Result, showing the hidden sort keys (as of 16 March 2015)
		m ft 3.4 11 3.7 12 4.3 14 4.6 15		m ft 70011100000000000003.4 700111000000000000011 70003700000000000003.7 700112000000000000012 70011400000000000004.3 700114000000000000014 70004600000000000004.6 700115000000000000015

Case C {{convert}} vs {{convert| ... |order=flip}}
{| class="wikitable sortable" |- !m !ft |- |{{convert|3.0|m|ft|0|disp=table|sortable=on}} |- |{{convert|11|ft|m|disp=table|sortable=on|order=flip}} |- |{{convert|4.0|m|ft|0|disp=table|sortable=on}} |- |{{convert|14|ft|m|disp=table|sortable=on|order=flip}} |}
		Result		Result, showing the hidden sort keys (as of 16 March 2015)
		m ft 3.0 10 3.4 11 4.0 13 4.3 14		m ft 70003000000000000003.0 700030000000000000010 70011100000000000003.4 700111000000000000011 70004000000000000004.0 700040000000000000013 70011400000000000004.3 700114000000000000014

In A the metres column works fine but the feet column is messed up. In B it's the feet column which is okay but the metres column is a mess. In C both columns are a mess.

Case C doesn't use {{nts}} and so shows that there is a problem inherent to {{convert}}.

Cases A and B point to a solution. It's no surprise that these cases are partially correct since {{convert}}'s sort key is based on {{nts}}. If we were to use something like {{numkey}} or {{rank}}, we'd have no luck at all. (It would probably be beneficial to work on that plan to eliminate these conflicting templates but that's a battle to be fought elsewhere.)

If the sort key for output cells were based on output values, the problems in each of these three cases would be solved. Jimp 10:46, 16 March 2015 (UTC)

I can't look at this at the moment, but someone requested an option to choose which value is used to determine the sort key. Option sortable=on is the same as sortable=in, and the new (November 2014) sortable=out can also be used. Johnuniq (talk) 11:01, 16 March 2015 (UTC)

I'm trying to look at the above now, but will have to disappear soon. Meanwhile, a correction to my comment: It was December 2013 that sortable=out was introduced (discussion). Johnuniq (talk) 06:15, 17 March 2015 (UTC)

Great report by Jimp. No cmt. -DePiep (talk) 11:20, 16 March 2015 (UTC)

Using sortable=out

Following is Case C from above, using "out" when flipped.

convert	m	ft
{{convert|3.0|m|ft|0|disp=table|sortable=on}}	3.0	10
{{convert|11|ft|m|disp=table|sortable=out|order=flip}}	3.4	11
{{convert|4.0|m|ft|0|disp=table|sortable=on}}	4.0	13
{{convert|14|ft|m|disp=table|sortable=out|order=flip}}	4.3	14

Johnuniq (talk) 07:16, 17 March 2015 (UTC)

It looks like the above table solves the convert side of the problem raised by Jimp above. When I went to look for the article mentioned in the original discussion, I saw that it was Jimp who had added converts with sortable=out (diff), so my example is not news. More would be needed to make convert's sort key compatible with all the other templates.

The natural question is why doesn't convert automatically change sortable=in to sortable=out when order=flip is used? I can't remember if there was a reason for that. I might have been unsure whether always forcing that change was desirable, and perhaps thought that requiring the user to specify what they wanted would be better. Some deep thought would be needed to decide what should be done. If flip changed sortable in to out, why would there be an out option for users? Johnuniq (talk) 08:39, 17 March 2015 (UTC)

It would probably be best if sortable=in stay as is but sortable=on could automatically change be equivalent to sortable=out when order=flip is used. Jimp 19:58, 18 March 2015 (UTC)

re Johnuniq. FWIW, I remember (did not research now) that I proposed to use the input-sortnumber always as an easy way to improve the result (before, only one column had a sortvalue; the 2nd column had none so sorted very bad). It was the quick & dirty solution I porposed. I think the perfect solution is to calculate the sortnumber twice and keep it with the result number, irrespective of flipping. -DePiep (talk) 20:16, 18 March 2015 (UTC)

Sort notes

To clarify my thoughts I have collected the following notes from previous discussions.

• Using sortable=on (same as sortable=in) calculates the sort key from the first input value, before rounding of the input.
• Using sortable=out calculates the sort key from the first output value, before rounding of the output.
• If a range is used, the sort key is calculated from the first number in the range; other values are ignored for the sort key.
• Using order=flip has no effect: for sortable=in the first value entered in the convert is used, and for sortable=out, the first calculated output value is used.

To illustrate, consider 204.386688 km which is 127 mi exactly. The following uses debug=yes to demonstrate that the normally hidden sort key is the same for each of the following converts:

• {{convert|204.386688|km|mi|disp=flip|abbr=on|sortable=on|adj=ri0|0|debug=yes}} → 7005204386688000000♠127 mi (204 km)
• {{convert|127|mi|km|abbr=on|sortable=out|adj=ri0|0|debug=yes}} → 127 mi (204 km)

Johnuniq (talk) 07:06, 17 March 2015 (UTC)

I just updated the documentation to reflect the current behavior as I understand it, that sortable=on emits sortkeys based on the input value. I think the "expected" behavior (and therefore should be default for "on"?) is that the sortkey is based on the output value (sortable=out) That is, the displayed values sort according to the displayed values. It shouldn't matter to the reader how the editor happened to pass the raw data to the template. I've spent a few days getting annoyed and trying to hack around that feature (sortable=out isn't mentioned at all in the table/sorting section, so I didn't bother to look in the full technical parameter list to find other sortable= options). DMacks (talk) 02:20, 3 April 2015 (UTC)

I'm sorry you had to spend this time because I left that out of the /doc, DMacks. This thing was not core {convert}, and also has changed recently (especially wrt the 2nd value). Warning: the big units-list is documented, but may be difficult to navigate too. -DePiep (talk) 08:14, 3 April 2015 (UTC)

Sorting by SI base units

sortable=in and sortable=out would fix these problems mentioned above but they will probably be difficult for people to use (I doubt many know the full ins and outs of the template) and there are other potential problems that would not be fixed.

Suppose you have a table with litres, imperial pints and US pints (in that order). {{convert|123|l|imppt USpt|disp=table|sortable=in}} will convert from litres and {{convert|123|USpt|l imppt|disp=table|sortable=out|order=flip}} will convert from US pints but you cannot currently concisely convert from imperial pints. Perhaps one day we'll have more options for order (e.g. |order=2 might insert the input value second) then |sortable=out might work.

Suppose you have a case where different cells in a column have different units (as on Mississippi National River and Recreation Area). You might, for example, have some cells with just feet and others with feet and inches. Currently {{convert|1|ft|1|in|sortable=on}} gives a sort key based on inches. Another example would be where the values in the table might range so widely, over so many orders of magnitude, that it would be impractical to use the same unit for the whole column (it's not very common but some tables are like this).

A possible solution would be to base the sort key on SI base units. So, 12 km, for example, would be sorted as 12,000, 10 imp pt would be sorted as 0.0056826125, 10 in would be sorted as 0.254, 32 °F as 273.16, 90 km/h as 25, etc. (still using the same sort key as {{nts}}). A new template could be created to produce this sort key and/or an identical sort key could be added to {{val}} if needed outside of {{convert}} (e.g. where some rows of a table use {{convert and others don't}}).

I think this would make things a lot less fiddly on the user end getting rid of these ins and outs ... maybe we could also even get rid of ons too and just automatically add the sort key to everything (though that may not be the best) or at least we could make the sort key automatic with |disp=table. Jimp 13:58, 19 March 2015 (UTC)

We've been discussing sortable tables with large ranges of orders of magnitude, where powers-of-ten are represented using both scientific notation and metric prefixes, at Talk:Periodic table#Po: atomic weight. We're just dealing with orders of magnitude modifying the same base unit (not also conversions to/from other units). We've spent a few days stumbling through various ideas, often not realizing all the existing features (both good and bad). I got lost in the discussion of the various sortable= and flip= modes. But we're also interested in just getting sortable values for the input (and we'd welcome this feature propagated through {{val}} because we have complex formatting requirements too), not getting multiple columns displaying the values also converted to a standard unit, so we can't just convert to a base unit and have that be the displayed and sortable value. Scientific notation already is handled correctly (1000, 10e2, and 1e3 all become 7003100000000000000), so it knows how to handle powers of ten for the actual value. Just need to get metric prefixes hooked into that same mechanism and base-units would be fully functional? DMacks (talk) 02:40, 3 April 2015 (UTC)

The sort key I've suggested here (based on SI base units) has been added to {{val}}. I still reckon that this is the way to go and so am repeating the call for {{convert}} to do so as well following suit with what {{val}} is now doing. To get it working the old unit subtemplates have been employed (see {{val/sortkey}}); I wonder whether there might be a better way to do this using Module:Convert/data instead. Jimp 06:46, 3 April 2015 (UTC)

I have not followed the discussions on other pages. Is the proposal that sortable=on would always generate a sort key based on the SI unit appropriate for the current conversion? For example, any convert of lengths would give a sort key based on m, regardless of the input and output units. There would be a table translating unit type (such as length) to the unit code (such as m) that sortable=on should use. Any weird units not covered by the table would sort as they do now. We would keep sortable=in and sortable=out unchanged until someone carefully checks everywhere they are used and tells us that the new behavior is what is wanted. Then we would change in and out to be the same as on, and deprecate them. The drawback to the proposal is that convert would be even more complex and take longer because it would have to do two conversions (probably), but the overhead would probably not be noticable. The advantage would be that a table converting chains to inches and km to miles and nm to angstroms would have a sort key based on the m value for every row, and so should sort correctly. Is that it? Johnuniq (talk) 10:15, 3 April 2015 (UTC)

Yes, that's it. Jimp 12:21, 3 April 2015 (UTC)

NIce. At last, I understand Jimp's. I add: (skipping the additional table Johnuniq mentions, and a more generic setup): Every unit has its SI unit in the base module:Convert/data table, plus its scale factor (to be added for all, then). This SI-set (unit + scale factor) used only when sortable is needed.

I'd prefer this not have this build deep inside the |table= options only. The sortkey value could be made available as partial-result (just as we can ask for e.g. |disp=number now). Related, maybe the SI-value can be returned, ie allow for all {{Convert|number|unit|SI}}.

More details: Should cover SI prefixes. Input and converted values normally have the same sortkey value, except when some output rounding is set. Weirder units like $/acre could become $/m² in the same scheme. -DePiep (talk) 13:30, 3 April 2015 (UTC)

Density

Could you please add mg/floz to convert table units into mg/L and so on, as it is done on this site about caffeine?--Carnby (talk) 21:04, 22 April 2015 (UTC)

Just to get the question (skip the "fl"):

{{convert|1|mg/oz}} → 1 milligram per ounce (0.00054 gr/g)

{{convert|1|mg/oz|abbr=on}} → 1 mg/oz (0.00054 gr/g)

-DePiep (talk) 21:12, 22 April 2015 (UTC)

It doesn't work with these values {{convert|12.7|mg/oz|mg/L|abbr=on|order=flip}} → (12.7 mg/oz).--Carnby (talk) 21:30, 22 April 2015 (UTC)

The problem is that convert regards oz as mass, whereas the above needs volume. That leads to confusion because you have to choose between imperial and US fluid ounces.

• {{convert|12.7|mg/impoz|mg/L|abbr=on|order=flip}} → 450 mg/L (12.7 mg/imp fl oz)
• {{convert|12.7|mg/usoz|mg/L|abbr=on|order=flip}} → 430 mg/L (12.7 mg/US fl oz)

Johnuniq (talk) 01:33, 23 April 2015 (UTC)

Thanks a lot. Now it works! --Carnby (talk) 06:16, 23 April 2015 (UTC)

Trillions versus 1 x 10¹²

I was using this... the volume of the Grand Canyon is 4.17 trillion cubic metres (5.45×10^¹² cu yd)

But why are cubic meters in "trillions" and yards in "1 x 10¹²"?? I kind of like trillions for both here. I like to saw logs! (talk) 04:44, 24 April 2015 (UTC)

Sorry, it works like that when the output is abbreviated. The only way of getting it spelled out is to turn abbreviations off:

• {{convert|4.17|e12m3|e12yd3}} → 4.17 trillion cubic metres (5.45×10^¹² cu yd)
• {{convert|4.17|e12m3|e12yd3|abbr=off}} → 4.17 trillion cubic metres (5.45 trillion cubic yards)

Johnuniq (talk) 04:50, 24 April 2015 (UTC)

Sortable tables

If you use the convert template in sortable tables, it sorts as thought it were text and not as numbers. This is unhelpful. I can provide an example if you like.-- Toddy1 (talk) 21:04, 28 April 2015 (UTC)

Did you include the |sortable=on option? -- WOSlinker (talk) 21:09, 28 April 2015 (UTC)

Ah. I did not know about that. Using "|sortable=on" fixes the problem. Thanks.-- Toddy1 (talk) 21:57, 28 April 2015 (UTC)

I did not research or improve recent documentation wrt tables & sorting. If someone feels inclined to clarify, by paragraph -- enjoy the edit. -DePiep (talk)