Template talk:Convert/Archive April 2019

Proposal: energy to temperature
In solid state, condensed matter and high-energy physics, it's common to convert between energies and temperatures (particularly energies in electron-volts; temperatures chiefly in kelvin) via the Boltzmann factor. An absolute temperature multiplied by $$k_B$$ yields an energy, and an energy divided by $$k_B$$ yields a temperature characteristic of that energy. There's already some non-obvious uses, such as  yielding 600 nm, using the speed of light, another fundamental physical constant. --Daviddwd (talk) 00:27, 4 April 2019 (UTC)
 * A discussion in July 2018 concluded that such a conversion would be problematic. The issues mentioned there would need to be addressed. Also, we would need to see the text in a few articles where convert might be useful (please supply links). Johnuniq (talk) 00:41, 4 April 2019 (UTC)
 * OK. I don't have an immediate solution for those issues, but here are a few articles:
 * Neutron scattering
 * Neutron temperature.
 * I could find more. Thank you for the information. I'm ok with keeping things how they are now. I'll bring it up again if I find what I consider sufficient reason. Thanks again! --Daviddwd (talk) 01:19, 4 April 2019 (UTC)

Force add a reference citation on the unit to be converted instead of the converted unit when using ?
When using the parameter  on a wikitable, is there a way to force the reference citation to be added on the first column (the original unit to be converted) instead of the second column (converted unit):

As can be seen from above, the template adds the citation on the converted square mile column  instead of the square kilometer column. I tested  can be used as a workaround but it would mess up the table and make it difficult to understand. Can we force the citation to be added on the unit to be converted column? –Sanglahi86 (talk) 02:35, 4 April 2019 (UTC)


 * Yes, put the reference immediately after 10.89 (so it would read " 10.89 "). I changed your reference to one that will work without a ref error on this talk. Johnuniq (talk) 02:48, 4 April 2019 (UTC)
 * Thank you very much for the information. Perhaps this useful info should be added to the documentation? Thanks again. –Sanglahi86 (talk) 05:35, 4 April 2019 (UTC)

Multiple units for power and speed
It's sometimes useful to have the possibility of choosing the right order for multiple units for power and speed: e.g. 275 kW (374 PS; 369 bhp). With the present system I would get something like that 374 PS; 369 bhp (275 kW) which is not the best way to present it. Same for speed, especially for wind which can be measured in km/h, m/s, mph and knots. Is there a way to work around this? Thanks.--Carnby (talk) 17:20, 6 April 2019 (UTC)
 * No problem, the mysterious order=out option can be used to specify the order in which the units should be displayed.
 * → 275 kW
 * Johnuniq (talk) 23:05, 6 April 2019 (UTC)
 * Beware that most articles (but not all) should be metric first.
 * → 374 PS
 *  Stepho  talk 00:46, 7 April 2019 (UTC)
 * What? According to what policy/guideline?
 * —Trappist the monk (talk) 01:21, 7 April 2019 (UTC)
 * I was under the impression that the first unit which appears should be the units the cited reference uses, the units in parens being conversions from the original specification. But in this case you're already going out of your way to present them out-of-order, so it's probably more a matter of what units the overall article is using. In general, hopefully that's metric because that's what most of the world uses, but when the article is based around non-metric units (such as U.S. highway speed limits), that won't be the case. Tarl N. ( discuss ) 01:29, 7 April 2019 (UTC)
 * WP:UNITS lists a couple of exceptions for the US and UK and then states "In all other articles, the primary units chosen will be SI units". I know Carnby makes edits to automobile articles and WP:CARUNITS says pretty much the same thing.
 * I always used the units in the reference as the input to convert and then use order to rearrange to the desired order. In fact, '|disp=flip' (the predecessor of order) was originally added many years when I requested a way to change the order while still using the units from the reference as input.  Stepho  talk 01:45, 7 April 2019 (UTC)
 * Excellent, thank you very much!--Carnby (talk) 10:47, 7 April 2019 (UTC)

Switching from hidden sort keys to data-sort-value
This template is one of the last sort templates still reliant on traditional hidden sortkeys. I've not been able to get around to fixing it. What needs to happen is to replace the class="sortkey" part with something like:. The template can already do this for outputting table cells, but not yet for cell values. Once this is implemented, hidden sortkeys are fully deprecated and the CSS hiding them can be removed. This would improve accessibility and avoids accidental screenscrapging of the sortkey value by for instance Google in their snippets. —Th e DJ (talk • contribs) 14:02, 9 April 2019 (UTC)
 * It's none of my business code-wise, but I hope this template stays in tandem with Val (i.e., not loosing common functionality, instead growing towards single documtantation). -DePiep (talk) 15:23, 9 April 2019 (UTC)
 * , ah crap.... so we have 2 modules that still need fixing.. —Th e DJ (talk • contribs) 15:32, 9 April 2019 (UTC)
 * I would need more time to think about the details but I'm pretty sure that val uses convert to get the sort key, so convert is the only issue. The reason that convert does what it does is simply for compatibility. People have used sortable tables where some elements were simply numbers, or perhaps other text with a hidden sort key, and others were generated by convert. That required convert to use the hidden sort key by default. Another irritating issue is that a design decision was made for val to default to including the hidden sort key and I copied that when implementing the module. I don't like the bloat that causes because val is often used outside tables and would prefer another template like vals to be used if wanting a sort key and don't want to type  for each item in a long table. I'll look at this soon. Please ping me if I forget. Johnuniq (talk) 00:25, 10 April 2019 (UTC)

@TheDJ: I've started thinking about this. Nothing is simple in convert due to the million options and their interaction but this looks reasonable. However, I first need to understand exactly what is wanted. The boxes below show example templates and the output from Special:ExpandTemplates.

Why is "♠" in the following? I know the mechanics of why it's there, namely that Module:Sortkey and Module:Nts have code copied from Module:Convert and convert needs ♠ because of the old hidden sort key style that it uses. However, it seems superfluous with data-sort-value.

12.34

Is the following ok or is a change needed? 12.34 m style="text-align:right;" data-sort-value="7001123400000000000"|12.34
 * style="text-align:right;" data-sort-value="7001123400000000000"|40.5

The first of the following outputs is what convert currently gives, and the second is what I think is wanted. Is it correct? 12.34 m 7001123400000000000♠ 12.34&amp;nbsp;m (40.5&amp;nbsp;ft) 12.34 &amp;nbsp;m (40.5&amp;nbsp;ft) Johnuniq (talk) 07:56, 16 April 2019 (UTC)

Sorting with data-sort-value ready for test
Use convert/sandbox to test the new sort keys per above. For simplicity, convert outputs an empty span before the displayed text. I believe that is now ok. The following shows some converts and the output from Special:ExpandTemplates.

 12.34 metres (40.5&amp;nbsp;ft)

 7001123400000000000♠ 12.34 metres (40.5&amp;nbsp;ft)

style="text-align:right;" data-sort-value="7001123400000000000"|12.34
 * style="text-align:right;" data-sort-value="7001123400000000000"|40.5

style="text-align:right;" data-sort-value="7001123400000000000"| 7001123400000000000 12.34 @TheDJ: Is the above ok? I will post a similar example at Template talk:Val and will do a similar fix for Module:Age later. A related discussion with information on sort keys is at Help talk:Sorting. Johnuniq (talk) 10:41, 21 April 2019 (UTC)
 * style="text-align:right;" data-sort-value="7001123400000000000"|40.5
 * , seems good to me. —Th e DJ (talk • contribs) 17:55, 29 April 2019 (UTC)
 * OK, I'm moving to update convert + val + age in the near future but am browsing my todo list wondering whether to look at anything else. Johnuniq (talk) 23:54, 29 April 2019 (UTC)
 * Very useful job, thanks! — JFG talk 07:17, 30 April 2019 (UTC)

Acres
I noticed there is no abbreviation in the template for acres. This is actually incorrect. Acres is commonly abbreviated as ac. This is on the page for acres as well as on the wikidata link provided on the table of units. Could someone fix this? Noah Talk 00:31, 30 April 2019 (UTC)
 * What acre says about "ac" being the symbol for acre is not definitive. I can't find any previous discussions on the issue but it has been accepted for many years that writing ac instead of acre is not helpful as there is no significant space saving and ac is not a familiar term. Is there an article where ac is required? Johnuniq (talk) 01:50, 30 April 2019 (UTC)
 * Could ac be used in the template as an alternative unit code, so 70 ac results in 70 acre, similar to how ft2, sqfoot, foot2 can be used as ones for square foot but not displayed - e.g. 70 foot2 results in 70 foot2? -- Voello  talk  20:44, 30 April 2019 (UTC)
 * How would that help? Everyone knows what "acre" is. By contrast, "ac" would cause a lot of head scratching. We assume that people have had a basic education and know that kg and kilogram are the same thing, but ac is not familiar to a lot of people. Johnuniq (talk) 23:30, 30 April 2019 (UTC)