Template talk:Convert/Archive April 2015

Comma as decimal mark
- 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:
 * → 12345.678 m
 * → 1.234 m
 * 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)
 * → 1.234 m
 * 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)
 * 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

 * ❌ 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)


 * 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 &#x1F4AC; 06:45, 31 March 2015 (UTC)

Think about it
This piece in the documentation doesn't make sense:


 * Sorting
 * Use both table 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 (the improvement has been added to ). 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.

{|
 * rowspan=3|
 * rowspan=3|
 * align=center valign=bottom|Result
 * align=center valign=bottom|Result, showing the hidden sort keys (as of 16 March 2015)
 * align=center valign=top|
 * align=center valign=bottom|Result, showing the hidden sort keys (as of 16 March 2015)
 * align=center valign=top|
 * align=center valign=top|
 * align=center valign=top|
 * align=center valign=top|


 * align=center valign=top|
 * }
 * }

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. Let me break it down like this.

{| !colspan=6| Case A vs
 * rowspan=3|
 * rowspan=3|
 * align=center valign=bottom|Result
 * align=center valign=bottom|Result, showing the hidden sort keys (as of 16 March 2015)
 * align=center valign=top|
 * align=center valign=bottom|Result, showing the hidden sort keys (as of 16 March 2015)
 * align=center valign=top|
 * align=center valign=top|
 * align=center valign=top|
 * align=center valign=top|


 * align=center valign=top|
 * }
 * }

{| !colspan=6| Case B vs
 * rowspan=3|
 * rowspan=3|
 * align=center valign=bottom|Result
 * align=center valign=bottom|Result, showing the hidden sort keys (as of 16 March 2015)
 * align=center valign=top|
 * align=center valign=bottom|Result, showing the hidden sort keys (as of 16 March 2015)
 * align=center valign=top|
 * align=center valign=top|
 * align=center valign=top|
 * align=center valign=top|


 * align=center valign=top|
 * }
 * }

{| !colspan=6| Case C vs
 * rowspan=3|
 * rowspan=3|
 * align=center valign=bottom|Result
 * align=center valign=bottom|Result, showing the hidden sort keys (as of 16 March 2015)
 * align=center valign=top|
 * align=center valign=bottom|Result, showing the hidden sort keys (as of 16 March 2015)
 * align=center valign=top|
 * align=center valign=top|
 * align=center valign=top|
 * align=center valign=top|


 * align=center valign=top|
 * }
 * }

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.

Cases A and B point to a solution. It's no surprise that these cases are partially correct since 's sort key is based on. 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  is the same as , and the new ( November 2014 )   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  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. 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  (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  to   when   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  stay as is but   could automatically change be equivalent to   when   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  (same as  ) calculates the sort key from the first input value, before rounding of the input.
 * Using  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  has no effect: for   the first value entered in the convert is used, and for , the first calculated output value is used.

To illustrate, consider 204.386688 km which is 127 mi exactly. The following uses  to demonstrate that the normally hidden sort key is the same for each of the following converts: Johnuniq (talk) 07:06, 17 March 2015 (UTC)
 * → 204.386688 km
 * → 127 mi


 * 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
and  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). will convert from litres and  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. 2 might insert the input value second) then 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  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 ). 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 (e.g. where some rows of a table use ).

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 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. 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 . I still reckon that this is the way to go and so am repeating the call for  to do so as well following suit with what  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  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. number now). Related, maybe the SI-value can be returned, ie allow for all.
 * 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  could become $/m2 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"):
 * &rarr; 1 mg/oz
 * &rarr; 1 mg/oz
 * -DePiep (talk) 21:12, 22 April 2015 (UTC)
 * It doesn't work with these values  &rarr; 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.
 * → 12.7 mg/impoz
 * → 12.7 mg/usoz
 * 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 1012
I was using this... the volume of the Grand Canyon is 4.17 e12m3

But why are cubic meters in "trillions" and yards in "1 x 1012"?? 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:
 * → 4.17 e12m3
 * → 4.17 e12m3
 * 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 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)