Template talk:Convert

From Wikipedia, the free encyclopedia
Jump to: navigation, search
Frequently Asked Questions (FAQ)
Q: When using {{convert}} why does the answer not seem right sometimes?
A: This template takes into account the precision of the supplied value and generally rounds the output to the same level of precision. If you need to change from the default output precision, see Help:Convert.
Q: What are all the possible units (kg, lb, m, cm, ft, in, °C, °F, km, mi, nmi, mph, km/h, and so on)?
A: See: Help:Convert units.
For more, see the FAQ.

Module version 10[edit]

Some changes to the convert modules are in the sandbox, and I intend switching the main modules to use the sandbox soon.

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 12 miles (2.4 km)
  • {{convert|1+1/2|mi|km|round=0.5}}1 12 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^3 US gal; 2.6×10^3 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

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[edit]

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}}50000000000000000000 feet (0 m)
  • {{convert/sandbox|9.87e-5|mi|sortable=on|debug=yes}}69991588422528000009.87×10−5 miles (1.588×10−4 km)
  • {{convert/sandbox|2|ft|6|in|sortable=on|debug=yes}}69997620000000000002 feet 6 inches (0.76 m)
  • {{convert/sandbox|1|yd|sortable=on|debug=yes}}69999144000000000001 yard (0.91 m)
  • {{convert/sandbox|1|yd|2|ft|sortable=on|debug=yes}}70001524000000000001 yard 2 feet (1.5 m)
  • {{convert/sandbox|99|chain|sortable=on|debug=yes}}700319915632000000099 chains (6,500 ft; 2,000 m)
  • {{convert/sandbox|81|km|sortable=on|debug=yes}}700481000000000000081 kilometres (50 mi)
  • {{convert/sandbox|79|mi|yd|sortable=on|debug=yes}}700512713817600000079 miles (139,000 yd)
  • {{convert/sandbox|7|Mm|sortable=on|debug=yes}}70067000000000000007 megametres (4,300 mi)
  • {{convert/sandbox|1.2e4|mi|sortable=on|debug=yes}}70071931212800000001.2×104 miles (1.9×104 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}}70047889275210526313.8 kilohertz (79 km)
  • {{convert/sandbox|3.5|kHz|km|sortable=on|debug=yes}}70048565498800000003.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}}69929000000000000000.090 l/km
  • {{convert/sandbox|9|mpgimp|l/km|disp=out|sortable=on|debug=yes}}69933138677070353570.31 l/km
  • {{convert/sandbox|1|l/km|l/km|disp=out|sortable=on|debug=yes}}69941000000000000001.0 l/km
  • {{convert/sandbox|1|mpgimp|l/km|disp=out|sortable=on|debug=yes}}69942824809363318222.8 l/km
  • {{convert/sandbox|9|l/km|l/km|disp=out|sortable=on|debug=yes}}69949000000000000009.0 l/km
  • {{convert/sandbox|9|usgal/mi|l/km|disp=out|sortable=on|debug=yes}}699521169312499999921 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[edit]

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[edit]

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 (470000 in)*
  • 2 × {{convert/sandbox|12|km|in|adj=nocomma}} → 12 kilometres (470000 in)*
  • 1 × {{convert/sandbox|12|km|in|disp=nocomma}} → 12 kilometres (470000 in)*
  • 56 × {{convert/sandbox|12|km|in|adj=flip}} → 470,000 inches (12 km)*
  • 58 × {{convert/sandbox|12|km|in|disp=flip5}} → 472,440 inches (12 km)*
  • 40 × {{convert/sandbox|12|km|in|disp=/}} → 12 kilometres or 470,000 inches*
  • 65 × {{convert/sandbox|12|km|in|disp=s}} → 12 kilometres or 470,000 inches*
  • 10 × {{convert/sandbox|12|km|in|disp=slash}} → 12 kilometres or 470,000 inches*
  • 2 × {{convert/sandbox|12|km|in|disp=2}} → 470,000 in*
  • 0 × {{convert/sandbox|12|km|in|disp=u2}} → in*
  • 1 × {{convert/sandbox|12|km|in|near=5}} → 12 kilometres (472,440 in)*
  • 0 × {{convert/sandbox|12|km|in|sortable=in}}700412000000000000012 kilometres (470,000 in)*
  • 0 × {{convert/sandbox|12|km|in|sortable=out}}700412000000000000012 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)

Minor convert range screw-case[edit]

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)

Density[edit]

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}}[convert: unit mismatch] (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! Face-smile.svg--Carnby (talk) 06:16, 23 April 2015 (UTC)

Trillions versus 1 x 1012[edit]

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

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:
  • {{convert|4.17|e12m3|e12yd3}} → 4.17 trillion cubic metres (5.45×10^12 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)