Template talk:Convert/Archive April 2019
This is an archive of past discussions about Template:Convert. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
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 yields an energy, and an energy divided by yields a temperature characteristic of that energy. There's already some non-obvious uses, such as {{cvt|600|nm|THz}}
yielding 600 nm (500 THz), 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:
- 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 disp=table
?
When using the parameter disp=table
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):
{| class="wikitable" |- ! scope="col" | City ! scope="col" | Population (2015) ! scope="col" | Area (sq. km.) ! scope="col" | Area (sq. mi.) |- ! scope="row" | [[Cavite City]] | {{nts|319,104}} | {{convert|10.89|km2|mi2|disp=table}}<ref>Example reference.</ref> |}
City | Population (2015) | Area (sq. km.) | Area (sq. mi.) |
---|---|---|---|
Cavite City | 319,104 | 10.89 | 4.20[1] |
As can be seen from above, the template adds the citation (<ref>Example reference.</ref>
) on the converted square mile column (Area (sq. mi.)
) instead of the square kilometer column (Area (sq. km.)
). I tested order=flip
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 (Area (sq. km.)
) column? –Sanglahi86 (talk) 02:35, 4 April 2019 (UTC)
References
- ^ Example reference.
- Yes, put the reference immediately after 10.89 (so it would read "10.89<ref>Example reference.</ref>"). 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.
{{convert|275|kW|PS kW hp|abbr=on|order=out}}
→ 374 PS (275 kW; 369 hp)
- Johnuniq (talk) 23:05, 6 April 2019 (UTC)
- Beware that most articles (but not all) should be metric first.
{{convert|374|PS|kW hp PS|abbr=on|order=out}}
→ 275 kW (369 hp; 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)
- 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)
- Beware that most articles (but not all) should be metric first.
- 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: <span data-sort-value="{{#invoke:sortkey|encode|replacement sortkey value}}">visible value</span>
. 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. —TheDJ (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)
- DePiep, ah crap.... so we have 2 modules that still need fixing.. —TheDJ (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
|sortable=on
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)
- 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
- DePiep, ah crap.... so we have 2 modules that still need fixing.. —TheDJ (talk • contribs) 15:32, 9 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.
{{nts|12.34}} <span data-sort-value="7001123400000000000♠">12.34</span>
Is the following ok or is a change needed?
{{convert|12.34|m|sortable=on|disp=table}} 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?
{{convert|12.34|m|abbr=on|sortable=on}} <span style="display:none" class="sortkey">7001123400000000000♠</span>12.34 m (40.5 ft) <span data-sort-value="7001123400000000000">12.34</span> m (40.5 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.
{{convert/sandbox|12.34|m|sortable=on}} <span data-sort-value="7001123400000000000♠"></span>12.34 metres (40.5 ft) {{convert/sandbox|12.34|m|sortable=debug}} <span data-sort-value="7001123400000000000♠"><span style="border:1px solid">7001123400000000000♠</span></span>12.34 metres (40.5 ft) {{convert/sandbox|12.34|m|sortable=on|disp=table}} style="text-align:right;" data-sort-value="7001123400000000000"|12.34 |style="text-align:right;" data-sort-value="7001123400000000000"|40.5 {{convert/sandbox|12.34|m|sortable=debug|disp=table}} style="text-align:right;" data-sort-value="7001123400000000000"|<span style="border:1px solid">7001123400000000000</span>12.34 |style="text-align:right;" data-sort-value="7001123400000000000"|40.5
@TheDJ: Is the above ok? I will post a similar example at Template talk:Val#Sorting will use data-sort-value and will do a similar fix for Module:Age later. A related discussion with information on sort keys is at Help talk:Sorting#Exclamation mark. Johnuniq (talk) 10:41, 21 April 2019 (UTC)
- Johnuniq, seems good to me. —TheDJ (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)
- 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)
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? NoahTalk 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 {{convert|70|ac|ha}} results in 70 acres (28 ha), similar to how ft2, sqfoot, foot2 can be used as ones for square foot but not displayed - e.g. {{convert|70|foot2|m2}} results in 70 sq ft (6.5 m2)? --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)
- Could ac be used in the template as an alternative unit code, so {{convert|70|ac|ha}} results in 70 acres (28 ha), similar to how ft2, sqfoot, foot2 can be used as ones for square foot but not displayed - e.g. {{convert|70|foot2|m2}} results in 70 sq ft (6.5 m2)? --Voello talk 20:44, 30 April 2019 (UTC)