Template talk:Convert/Archive September 2014

Module version 5

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

• Module:Convert • Module:Convert/sandbox • same content
• Module:Convert/data • Module:Convert/data/sandbox • same content
• Module:Convert/text • Module:Convert/text/sandbox • same content
• Module:Convert/extra • Module:Convert/extra/sandbox • same content
• Module:Convert/wikidata • Module:Convert/wikidata/sandbox • same content
• Module:Convert/wikidata/data • Module:Convert/wikidata/data/sandbox • same content

The changes are:

• Rather than anything goes, input fractions must follow a restricted syntax. That is to provide an error message rather than "garbage in, garbage out" because a fraction like 3-1/2 may be entered for 3.5, but currently it is interpreted as 2.5.
• Each input value can have a single reference appended. That is intended for infoboxes which might, for example, have a weight field where the value is passed to convert. Editors are tempted to add a reference to the value, and that currently breaks the convert.
• Two new "volume per unit length" units are moved from "extra" to "data".

The output in the following examples use fixed wikitext so the displayed text will not change when future updates occur.

Convert	Version 4 output	Version 5 output
{{convert|3/8|in|mm}}	3⁄8 inch (9.5 mm)	3⁄8 inch (9.5 mm)
{{convert|+3/8|in|mm}}	+3⁄8 inch (9.5 mm)	+ 3⁄8 inch (9.5 mm)
{{convert|-3/8|in|mm}}	−3⁄8 inch (−9.5 mm)	−3⁄8 inch (−9.5 mm)
{{convert|3/-8|in|mm}}	3⁄−8 inch (−9.5 mm)
{{convert|5+3/8|in|mm}}	5 3⁄8 inches (140 mm)	5 3⁄8 inches (140 mm)
{{convert|+5+3/8|in|mm}}	+5 3⁄8 inches (140 mm)	+5 3⁄8 inches (140 mm)
{{convert|-5-3/8|in|mm}}	−5 3⁄8 inches (−140 mm)	−5 3⁄8 inches (−140 mm)
{{convert|5-3/8|in|mm}}	5 −3⁄8 inches (120 mm)
{{convert|12+1/2|hand|in}}	12 1⁄2 hands (48.5 inches)	12 1⁄2 hands (48.5 inches)
{{convert|12.3+1/2|hand|in}}	12.3 1⁄2 hands (51.5 inches)	12.3 1⁄2 hands (51.5 inches)
{{convert|12.3+1/2|m|cm|0}}	12.3 1⁄2 metres (1,280 cm)	12.3 1⁄2 metres (1,280 cm)
{{convert|71<ref>Some reliable reference.</ref>|kg|lb}}		71 kilograms (157 lb)
{{convert|12<ref>First ref.</ref>|to|34<ref>Second ref.</ref>|ft}}		12 to 34 feet (3.7 to 10.4 m)

Hovering the mouse over the error message for {{convert|3/-8|in|mm}} shows Value "3/" must be a number. That occurs because when convert decides that 3/-8 is invalid, it interprets - as an assumed "to" range; it then finds that 3/ is invalid. Some special code gives a better message for the 5-3/8 example, but it's not worth trying to perfect that for all possible input.

The results for the hand unit are to show that one quirk is allowed for fractions: a single digit after a decimal point is permitted (12.3+1⁄2 hands is 12 hands 3+1⁄2 inches). Too much work is required to permit that only for hands, so 12.3+1/2 works for all units.

References

Johnuniq (talk) 11:00, 26 August 2014 (UTC)

can we change the testcases to use the live and sandbox versions of the module (instead of convert/old)? Frietjes (talk) 16:25, 26 August 2014 (UTC)

I love the reference option (only days ago, Tal Block appeared in the error category for this). As a minor note, should not the ref link appear later, like: 71 kilograms^[1] (157 lb) or: 71 kilograms (157 lb)^[1]; maybe even the range showing 12 to 34 feet^[2][3] (3.7 to 10.4 m)? (I spend last July working on this in these infoboxes). Anyway, do not let me spoil the party. Improvement. -DePiep (talk) 16:45, 26 August 2014 (UTC)

Re tests: I use Template:Convert/testcases#Sandbox testcases. The four pages linked there contain almost all the tests from the other pages, as well as some extras. They compare output from convert/sandbox with fixed text so they run very quickly and over 1000 tests can be on one page. For example, looking at the history of Template:Convert/testcases/sandbox2 shows it was set up on 23 June 2014, and was updated on 7 July 2014 and 26 August 2014. The updates show the changes to the tests that were required in order to make convert/sandbox pass all the tests, so it's a nice record of what updates to the module have done. So, I don't see a need to update the other tests to compare the live and sandbox modules because (almost) all the tests are performed, and those tests can be checked by purging just four pages. More tests can be added to the fourth sandbox test page. However, if someone wants to adjust how the other tests work, that's fine by me. Johnuniq (talk) 01:11, 27 August 2014 (UTC)

Re references: Yes, I saw that article pop up in the error category and that irritated me as I've seen the same problem several times before, so I looked at what could be done and found a simple workaround. I regard it as a bit of a kludge and not something I would recommend. The positioning of the reference was mainly for expediency as it was simple to add it to the end of the formatted input number. A bit more work could move it elsewhere, but there are a lot of strange cases and I didn't think it was worth the effort of thinking about them all. If the feature gets used, that can be revisited. Johnuniq (talk) 01:11, 27 August 2014 (UTC)

Just to mention the other solutions, non-{convert}, for ideas. Recently I edited {{Chembox}} and {{Infobox element}} to have like

| melting point C =

| melting point ref =

| melting point comment =

that produces infobox row

Melting point | 10 °C (50 °F; 283 K)^[1] (some comment)^[2]

It has maximal outside control (by infobox param handling) -DePiep (talk) 22:46, 27 August 2014 (UTC)

• About fraction slash U+2044 ⁄ FRACTION SLASH (⁄) (as opposed to regular keyboard slash /). Is it possible to accept & process that one for fraction input? If it is easy to do, I suggest adding it to version 5 (while you are at it, so to speak).

Current version:

{{convert|3/8|in|mm}} → 3⁄8 inch (9.5 mm) -- current, slash

{{convert|3⁄8|in|mm}} → 3⁄8 inch (9.5 mm) -- current, fraction slash

Sandbox (am I testing the right thing this way?):

{{convert/sandbox|3/8|in|mm}} → 3⁄8 inch (9.5 mm) -- sandbox, slash

{{convert/sandbox|3⁄8|in|mm}} → 3⁄8 inch (9.5 mm) -- sandbox, fraction slash

The reason for asking is, that in this wiki the fraction slash is the preferred character (not the keyboard slash), see MOS:FRAC and in {{frac}}.

So it even might be worth postponing the change to test & introduce, because it funnels to MOS and basic input (copy+paste from wiki article). No need to care for ⁄ input though. Whadayya think? -DePiep (talk) 19:21, 27 August 2014 (UTC)

OK, I've put that in the sandbox (just the U+2044 fraction slash). I had to add "/sandbox" to your converts. Johnuniq (talk) 08:15, 28 August 2014 (UTC)

Great! -DePiep (talk) 09:17, 28 August 2014 (UTC)

Re tests: I added a few tests at Template talk:Convert/testcases/sandbox4. If anyone would like to see how that works, go to that page and observe that it says "All 32 tests passed" (because I clicked the "purge this page" link at the top). The line just above "All 32 tests passed" shows how to run the tests on convert (rather than convert/sandbox). If you copy that single line and paste it into a sandbox, the preview will show that the new tests I added fail for the current convert because it does not support the new stuff. Searching for "Fail" finds those results (easy to do because it's a short page, but searching is needed when there are hundreds of tests). Johnuniq (talk) 09:51, 28 August 2014 (UTC)

Use of {{val}}

Some {{val}} usage uses the following option in convert:

• {{convert/sandbox|1|example|disp=unit or text}} → example
• {{convert/sandbox|1|example|disp=unit or text|lk=on}} → example
• {{convert/sandbox|1|m3|disp=unit or text|abbr=on|lk=on}} → m³

When the text is not a known unit, an unfortunate consequence is that Module:Convert/extra is loaded and that bloats Special:WhatLinksHere/Module:Convert/extra. I have put a new version in the sandbox which does not load extra when the above option is used. That means there won't be so many unnecessary links to the extra module. Previewing the above examples in a sandbox shows the extra module is not used, but if "/sandbox" is removed, the current convert will load extra. There is a procedure to add extra unit names to val so there is no need for a new unit to be added to convert simply so it can be recognized by {{val}}, so I do not think there is any problem with this new approach. If anyone can see a problem, please explain. Johnuniq (talk) 03:28, 29 August 2014 (UTC)

Done

I updated the modules as above. I had been dreaming of adding the "ranges of input multiple units" issue mentioned in the next section, but it turns out to be quite tricky and will have to wait for another time. Johnuniq (talk) 10:29, 1 September 2014 (UTC)

jō

As provided on https://en.wikipedia.org/wiki/Tatami#Size , "In Japan, the size of a room is often measured by the number of tatami mats (-畳 -jō), about 1.653 square meters (for a standard (Nagoya) size tatami)." , can the unit be added to the conversion?C933103 (talk) 15:16, 21 August 2014 (UTC)

I don't see how a template would help much at that article because it's hard to improve on:

the size of a room is often measured by the number of tatami mats (-畳 -jō), about 1.653 square meters

Are many other articles saying things like "the room has an area of 6 mats (9.9 m²)"?

What would be the symbol (if abbr=on) and the name (if abbr=off)? Is there a "standard" mat size, and what is the exact conversion factor? Is there a reference for that? Johnuniq (talk) 03:40, 22 August 2014 (UTC)

Notes to consider: the article says "Shops were traditionally designed to be 5 1⁄2 mats, and tea rooms are frequently 4 1⁄2 mats." So if this is correct and existing parlance (more so in Japanese I guess; could be historical or in architectural profession), it is a usage (can C933103 read jawiki and expand?). A second note is that, would this be added, the datapage is growing into its secondary (I think) usefulness: an encyclopedia of convertable units. A base, well sourced, for content. For this, high usage is not needed. -DePiep (talk) 10:20, 22 August 2014 (UTC)

I also understand that it has a aspect ratio defined (2:1). This makes a secondary property, like golden ratio. We could think of converting a "from 1=0.91 m mat into 1 m mat" by this ratio.

Then Tatami#Size says that there are regional size differences (0.91 m, 0.955 m) for the "1", with one (Nagoya) being "formal" somehow. All have the 2:1 ratio. -DePiep (talk) 10:28, 22 August 2014 (UTC)

The unit is actually similar to tsubo that is already in Module:Convert/documentation/conversion_data/doc. 1jō=0.5tsubo. (The link given in tsubo's row there contain some more clearer info)
For unit and symbol name, That would be the same 畳, but the problem is it have some different possible romanization, which for example Invaders of the Rokujyōma!? used jyō for the unit's transcription in title, while articles like the one i previously quoted or in Washitsu the jō is used. And there are also cases in these articles where 畳 is translated as Tatami mats, so probably 'Tatami mat' could be the (if abbr=off) name while the direct romanization being the (abbr=on) name?
And from what i understand, the aspect ratio is just used to define shape of an actual tatami, and it does not have any effect on using this as a unit.
I just searched on google that seem like most japanese government institution like statistical department seem like just consider 2jō=1tsubo=3.3m^2. And also I found a page saying 910mm*1820mm have become the mainstream size for tatami (and thus size for the unit, i.e. 1jō=1.6562m^2).
And as for usage, [1] and [2] C933103 (talk) 01:06, 27 August 2014 (UTC)

"Jyō" is a non-standard transliteration (in all three major systems). (Its existence is probably due to confusion). The author of Invaders of the Rokujyōma!? didn't have to conform to such standards much less our guidelines but "jyō" is ruled out by WP:MOS. Using "tatami mat(s)" (note the lower case "t") for abbr=off and "jō" for abbr=on would be an interesting approach; however, "jō" isn't an abbreviation, it's a Japanese word. I'd hope we were aiming at making this template more logical rather than less. Might it not be better (if we need both) to introduce two input codes (tatami mat and jo) and have them just ignore abbr=on? (Note that the plural of "jō" would be "jō".) Jimp 03:15, 4 September 2014 (UTC)

Thanks C933103 and Jimp for the details which, while interesting, are way over my head, however I cannot see how convert could be very useful with this unit. Let's wait and see whether there are more cases where it might be used. Johnuniq (talk) 09:27, 4 September 2014 (UTC)

Metric horsepower

The documentation says:

• Watts, kilowatts, milliwatts, etc. are supported. As is horsepower (English & metric). Use standard abbreviations as input code (lowercase hp for horsepower, for example)

As if anyone would know the standard abbreviation for metric horsepower! To find it, you must scroll through the list on this page, discover it's not there, click through to Template:Convert/list of units, search and discover it's not there either, then on to Module:Convert/documentation/conversion data/doc. Can we make this a bit easier? Maybe have a link straight to the full list instead of pointing users first at the partial list? Kendall-K1 (talk) 10:51, 3 September 2014 (UTC)

I happen to remember that PS (Pferde stärke)_ is the standard symbol for metric horsepower, so {{convert|100|kW|hp PS|abbr=none|lk=on}} 100 kilowatts (130 horsepower; 140 metric horsepower) {{convert|100|kW|hp PS|abbr=on}} 100 kW (130 hp; 140 PS) Peter Horn User talk 14:11, 4 September 2014 (UTC)

PS is the only one that works. eg cv, etc, do not. Peter Horn User talk 14:22, 4 September 2014 (UTC)

Listing: units not supported

I have started Template:Convert/units not supported. Should gather knowledge. -DePiep (talk) 23:38, 4 September 2014 (UTC)

Adjective in output

For TAM (tank) {{convert|155|mm|in|abbr=in|adj=out}} 155 mm (6.1 inches) instead of 155 mm (6.1 inch). It does not appear to work now. Peter Horn User talk 13:58, 4 September 2014 (UTC)

I've noticed that abbr=on (or in) turns off adj. I don't know if that's intended behavior or not. Kendall-K1 (talk) 20:31, 4 September 2014 (UTC)

I recap:

A. {{convert|155|mm|in|abbr=in|adj=out}} → 155 mm (6.1 inches) -- straight {convert}

Peter Horn expects: 155 mm (6.1 inch) -- (hardcoded here)

Kendall-K1 tests:

B. {{convert|155|mm|in|abbr=in|adj=out}} → 155 mm (6.1 inches) -- |abbr=in

C. {{convert|155|mm|in|abbr=on|adj=out}} → 155 mm (6.1 in) -- |abbr=on

D. {{convert|155|mm|in|abbr=in|adj=off}} → 155 mm (6.1 inches) -- |abbr=in

E. {{convert|155|mm|in|abbr=on|adj=off}} → 155 mm (6.1 in) -- |abbr=on

F. {{convert|155|mm|in|abbr=in}} → 155 mm (6.1 inches) -- |abbr=in

G. {{convert|155|mm|in|abbr=on}} → 155 mm (6.1 in) -- |abbr=on

H. {{convert|155|mm|in|adj=on}} → 155-millimetre (6.1 in)

I. {{convert|155|mm|in|adj=off}} → 155 millimetres (6.1 in)

-DePiep (talk) 21:27, 4 September 2014 (UTC)

The original example is {{convert|155|mm|in|abbr=in|adj=out}} and the options do not do what is expected. The problem is that Help:Convert#Parameter list shows that adj=out is not a valid option. Unfortunately, the template runs with warnings off so it simply ignores unknown options and leaves the user in the dark. Using {{convert/sandbox}} would show the problem, although it invokes the sandbox modules which are sometimes different from the main modules used by the normal template. It is not feasible to enable warnings in the main template at the moment because there are thousands of cases of bad syntax in articles. One defect is that the module ignores any parameters after it has gathered what it thinks is required for the convert (it does not go looking for additional unnamed parameters). Remember to mouse over the error message to see more:

• {{convert/sandbox|155|mm|in|abbr=in|adj=out}} → 155 mm (6.1 inches)
• {{convert/sandbox|155|mm|in|I like apple pie}} → 155 millimetres (6.1 in)

By design, adj=on (and adj=mid) only apply to unit names on the principle that only formal writing would be using adj=on, and such cases should use the full name.

• {{convert|155|mm|in|adj=on}} → 155-millimetre (6.1 in)
• {{convert|155|mm|in|adj=on|abbr=on}} → 155 mm (6.1 in)
• {{convert|155|mm|in|adj=on|abbr=in}} → 155 mm (6.1-inch)
• {{convert|155|mm|in|adj=on|abbr=off}} → 155-millimetre (6.1-inch)

Johnuniq (talk) 02:16, 5 September 2014 (UTC)

Thanks. Peter Horn User talk 20:32, 6 September 2014 (UTC)

Gigalitres etc

For Murray–Darling basin#Physiography: {{convert|24,000|GL|km3 acre-foot|lk=on}} 24,000 gigalitres (24 km³; 19,000,000 acre⋅ft) or {{convert|24,000|GL|km3 af|lk=on}} 24,000 gigalitres () instead of {{convert|24,000|GL|km3|lk=on}} 24,000 gigalitres (24 km³) which works. {{convert|24|km3|acre-foot|lk=on}} 24 cubic kilometres (19,000,000 acre⋅ft) or {{convert|24|km3|af|lk=on}} 24 cubic kilometres () Peter Horn User talk 20:44, 6 September 2014 (UTC)

• Try {{convert|24,000|GL|km3 acre·ft|lk=on}} 24,000 gigalitres (24 km³; 19,000,000 acre⋅ft) -- WOSlinker (talk) 22:30, 6 September 2014 (UTC)

Possibly the unit "acre ft" was tried first. In a combination with km3 that would give "km3 acre ft" which convert rejects because it does not work out that the second space is part of the unit code. For that situation, use "+" to join units:

• {{convert|24,000|GL|km3 acre ft|lk=on}} → 24,000 gigalitres ()
• {{convert|24,000|GL|km3+acre ft|lk=on}} → 24,000 gigalitres (24 km³; 19,000,000 acre⋅ft)

Johnuniq (talk) 22:49, 6 September 2014 (UTC)

Thanks, that was fast. Peter Horn User talk 01:09, 7 September 2014 (UTC)

abbr=off or abbr=none

{{convert/spell|1/2|m|in|abbr=off}}, one-half metre (20 inches) or {{convert/spell|1/2|m|in|abbr=none}} one-half metre (20 inches). abbr=off or abbr=none do not work here with "convert/spell". Peter Horn User talk 00:53, 17 August 2014 (UTC)

Perhaps even better one-half metre (twenty inches). Peter Horn User talk 01:04, 17 August 2014 (UTC)

Yikes, we might have to delete {{convert/spell}} as a reminder that it should not be used (see April).

• {{convert|1/2|m|in|spell=in}} → one-half metre (20 in)
• {{convert|1/2|m|in|abbr=none|spell=in}} → one-half metre (20 inches)
• {{convert|1/2|m|in|abbr=off|spell=in}} → one-half metre (20 inches)
• {{convert|1/2|m|in|abbr=on|spell=in}} → one-half m (20 in)
• {{convert|1/2|m|in|0|abbr=off|spell=on}} → one-half metre (twenty inches)

Johnuniq (talk) 01:17, 17 August 2014 (UTC)

{{convert/spell}} is in many articles and thus replacing it systimatically would be a hassle. Again, thanks. Peter Horn User talk 02:57, 17 August 2014 (UTC)

Removed the old template from 29 articles. Remaining: in 47 talkpages etc. Using in mainspace will splash the page with a warning.

In short: for most cases {{convert|...|spell=in}} will do. (Other options: |spell=In, |spell=on, |spell=On). -DePiep (talk) 12:50, 17 August 2014 (UTC)

Thanks! That looked straightforward and yet solves the problem perfectly. I had never heard of {{main other}}, and coupling it with {{error}} gives a great result. Johnuniq (talk) 23:51, 17 August 2014 (UTC)

Why "one-half metre" rather than "half a metre"? We don't talk in half metres ... do we ... or could it be a dialect thing? I remember thinking it odd when I found that in Canada people would say "a half hour" whereas in Australia we say "half an hour". Is that what's going on (if so, maybe we need a grammar parameter) or is the template just blindly spelling out 1/2 as "one-half" oblivious to the fact that it's not just a number we're after but half of a thing? Jimp 03:18, 4 September 2014 (UTC)

It's just blindly spelling it out. I've given up trying to work out what is "right" because a couple of years of hanging around Wikipedia have got me used to many dialects that I would once have regarded as "wrong". I can tell when to use "color" and "colour", but that's about it. The main reason for "one-half metre" is that there are probably some instances where that is what is wanted, so changing it to "half a metre" (or "half metre"?) may need an option to choose plain "one-half metre" instead. The spelling is done by Module:ConvertNumeric and it could be used to display "one-half" in contexts unrelated to convert. We would probably need to find examples in articles and deliberate on the best procedure. Johnuniq (talk) 09:23, 4 September 2014 (UTC)

Perhaps it might be best to bring it up at Module:ConvertNumeric. Perhaps they could figure out a way to give appropriate output when we've got a half of a thing (or a quarter, two-thirds, etc.) then we could send the number and unit to Module:ConvertNumeric (we might have to send another parameter for "a" vs "an"). You could be right that there may be cases where what we're now getting is what's wanted but I have a feeling that they'd be fewer than the other. Maybe there is a dialect thing going on and it would be good to look at examples out there. But if it is a dialect thing, noting that the default spelling is Commonwealth, I'd suggest we look first to Commonwealth dialects (which, I think, prefer "half a kilogram" to "one-half kilogram", etc.). Jimp 04:40, 10 September 2014 (UTC)

I don't think a discussion at Module:ConvertNumeric would help because I tried to entice the module's author into supporting the spelling of fractions, but he did not respond. In the end I added the code, and it's possible that its only usage is in convert. I added the subsection below with some examples. Johnuniq (talk) 06:26, 10 September 2014 (UTC)

Spelling fractions

The following are all converts that were in articles in early May 2014 which spell a fraction.

• Adams Avenue Parkway {{convert|1/2|mi|km|adj=mid|-long|spell=in}} → one-half-mile-long (0.80 km)
• Adams Avenue Parkway {{convert|1/2|mi|km|adj=mid|-long|spell=in}} → one-half-mile-long (0.80 km)
• Clackline Bridge {{convert|1+1/2|m|spell=in}} → one and a half metres (4 ft 11 in)
• Clackline Bridge {{convert|5+1/2|m|spell=in}} → five and a half metres (18 ft)
• Great Eastern Highway {{convert|3+1/2|km|spell=in}} → three and a half kilometres (2.2 mi)
• Interstate 35 in Minnesota {{convert|spell=in|1/4|mi|km|adj=mid|-long}} → one-quarter-mile-long (0.40 km)
• Interstate 70 in West Virginia {{convert|1+1/5|mi|m|adj=mid|-long|spell=in}} → one-and-a-fifth-mile-long (1,900 m)
• Interstate 80 in Utah {{convert|1+2/5|mi|km|adj=mid|-long|spell=in}} → one-and-two-fifths-mile-long (2.3 km)
• Interstate 80 in Utah {{convert|4+1/2|mi|km|adj=mid|-long|spell=in}} → four-and-a-half-mile-long (7.2 km)
• Interstate 80 in Utah {{convert|4+1/2|mi|km|adj=mid|-long|spell=in}} → four-and-a-half-mile-long (7.2 km)
• Iowa Highway 965 {{convert|1/2|mi|km|adj=mid|-long|spell=in|1}} → one-half-mile-long (0.8 km)
• List of former state routes in Ohio (354–568) {{convert|1+1/2|mi|km|spell=in}} → one and a half miles (2.4 km)
• List of former state routes in Ohio (675–824) {{convert|1+1/2|mi|km|adj=mid|-long|spell=in}} → one-and-a-half-mile-long (2.4 km)
• Oklahoma State Highway 147 {{convert|3+1/2|mi|km|spell=in}} → three and a half miles (5.6 km)
• Utah State Route 200 {{convert|1+9/10|ft|cm|spell=in}} → one and nine-tenths feet (58 cm)
• Utah State Route 61 {{convert|1+9/10|ft|m|spell=in}} → one and nine-tenths feet (0.58 m)

I haven't thought about the above yet, but looking at where these are used might help decide if any changes to how convert spells fractions are warranted. Johnuniq (talk) 06:26, 10 September 2014 (UTC)

Display of common fractions in output

For Willie wagtail {{convert|19|-|21.5|cm|in|abbr=on|disp=frac}} 19–21.5 cm (7.5–8.5 in) (common fractions not yet displayed) instead of 19.0–21.5 cm (7½–8½ in), in the same manner that {{RailGauge}} displays fractions, e.g. {{RailGauge|900mm}} 900 mm (2 ft 11+7⁄16 in). Peter Horn User talk 13:10, 9 September 2014 (UTC)

Maybe you mean {{convert|19|-|21.5|cm|in|abbr=on|frac=2}} → 19–21.5 cm (7+1⁄2–8+1⁄2 in)

-DePiep (talk) 13:31, 9 September 2014 (UTC)

Much obliged for "the cat's meow". Peter Horn User talk 21:18, 9 September 2014 (UTC)

I am happy to see you referred to RailGauge (my baby {{track gauge}}) as a demo. That's the trick to ask me anything. ;-) .-DePiep (talk) 21:31, 9 September 2014 (UTC)

So {{RailGauge}} was moved? Peter Horn User talk 17:22, 10 September 2014 (UTC)

Yes, but the old name keeps working. DePiep (talk) 17:32, 10 September 2014 (UTC)

AS a "redirect" of course. Peter Horn User talk 19:10, 10 September 2014 (UTC)

Next grand step: {convert} 3.0

OK. So old wikicode {convert} is in Lua code since December 2013. Today it has 673,940 tc's (from 550,000 in November 2013. That's up 21% in nine months!). Also, I note that there are iw translations, and no blocking situations have appeared. Great.

From this and from today, I want to aim for the next goal: a more grande, universal, less-restricted {convert} availability. The current module had to solve the issue of continuity: old situations may not be broken, by December 2013. Clearly, that had been served. From this, the grand design should be: "What would it be like, if you'd redesign the template from zero?".

Quite too often, I read module designers's (Johnuniq) complaint about 'complexity'. Of course that exists. And it is limiting development and user friendliness. But today the old wikicode does not restrict us any more, so we can jettison that load. What is needed, is the one-year-ahead situation: without the constrictions the developer themselves mentions, what could it look like?

(And to be frank: in three or five years, we do not like this inherited setup we have today. Why not start redesigning, with new freedoms, today?). -DePiep (talk) 23:12, 4 September 2014 (UTC)

I agree whole-heartedly. This Lua version (let's call it Version 3) has inherited a whole lot of convolutions from the previous multi-subtemplate verion (call it Version 2). There are to many to simply list (it would take a short essay to do this justice) but disp=flip is one example. Using disp for this meant that it couldn't be used for its proper job, i.e. controlling the "display" (brackets, tables, lists with "or", etc.). I'd started on a revamp about three years ago but dropped it when Lua hit the scene. I like the idea of starting from scratch. Let's not put too much emphasis on backward compatibility: get a bot to get rid of old rubbish. Jimp 23:59, 4 September 2014 (UTC)

All fine, but one: I do explicitly applaud the current version, as I said. (v2.0). Also, keeping Juniq on board might be a good idea (to say the least). Mostly, I want @Johnuniq: to say like: 'how interesting, let me think about this'. -DePiep (talk) 00:09, 5 September 2014 (UTC)

I'm with you on those points. I'm saying that the former incarnation was full of quirks due to its evolution from a much more limited template. Johnuniq's done a lot to address this but I reckon there's more work to be done. For example, when the need arose for rounding to the nearest 5 disp=5 was introduced because the old structure made it quite difficult to add new parameters but this caused problems when we wanted to use disp for something else. Now that Johnuniq has give us the near parameter disp=5 is obsolete and should be eliminated. Jimp 02:17, 5 September 2014 (UTC)

I'm interested in a new syntax although I haven't had the energy to think about it seriously. I agree with DePiep on many issues, but one big difference is that D likes long options (to be self-explanatory), whereas I shudder at the thought of an article with converts having something like |input_has_multiple_units=yes as discussed at #Converting multiple input values in feet and inches to metres above. Something approaching natural language would be much nicer: put nearly everything in a single parameter with spaces as delimiters; use "in" when abbreviated inch is wanted and "inch" for the name. I was also thinking of something like the printf idea where a single parameter would have the text wanted with placeholders where convert results should be placed. However, everything has drawbacks and allowing/requiring users to enter their own text would mean MOS details like   were not being enforced.

Re disp, Jimp said something similar to the above earlier and I added some options more or less as trials: |order=flip and |round=5 and |round=25

• {{convert|1234|ft|m|disp=or|round=5|order=flip}} → 375 metres or 1,234 feet

A problem with that is that we end up with too many options. Johnuniq (talk) 03:21, 5 September 2014 (UTC)

Johnuniq, what do you mean by "too many options"? Do you maybe mean "too many parameters"? -DePiep (talk) 19:00, 10 September 2014 (UTC)

I agree that we don't want to many options but the options we do have should use sensibly named parameters; thanks, Johnuniq, for getting started on that. Jimp 03:55, 5 September 2014 (UTC)

Sort of lol: when I propose using a new parameter, I give it a preliminary name that describes clearly its job. Of course, later the name can be more pointy. But to start an option by naming it like |inp= does not help clarification.

More structural is that we should prevent overloading parameters. For example, we could splice off the different areas that |disp= works on. Or, opposite approach, allow most options into one: |format=adj abbr slash spell. -DePiep (talk) 10:40, 5 September 2014 (UTC)

The first option was pretty much along the lines I was suggesting though the second would have its merits. Over "Version 2"'s seven years (between Drum Guy's switch and Johnuniq's module) the set up made it difficult to add new parameters. This resulted in new functionality being added using old parameters which had originally been intended for other things (disp for rounding and ordering, adj for adding text, etc.). Many parameters are already overloaded. I'm suggesting we reverse this. First delete mention of these options from the documentation; next run a bot to switch all disp=5s to near=5s, all disp=flips to order=flips, etc.; then remove these options entirely. Retaining relics of a by-gone day is only going to make using the template more difficult in the long run. Jimp 04:23, 10 September 2014 (UTC)

That's doable, and after working out a plan we could approach the AWB people and ask that suitable instructions be added so they were part of the routine cleanup that it performs, then later think about a bot. However, the problem is that some options are probably an unbreakable habit with many editors. Johnuniq (talk) 07:06, 10 September 2014 (UTC)

Yes, sounds very sound. Below I'll start a section to gather the deprecated parameter options. (I guess no parameters themselves are deprecated, right?). Note that following steps (AWB, bots) can be decided later. First task is to get the list right, and then put these out of sight. -DePiep (talk) 18:58, 10 September 2014 (UTC)

Some 'deprecations' could be removed completely in the next version, right away. Like |abbr=comma (ouch). Then the abusing pages will show up in the error category - we can solve. -DePiep (talk) 21:01, 10 September 2014 (UTC).

Invalid options won't show up until we enable warnings in the template—they are disabled at the moment because there are thousands of problems in articles. I made a list of them (on a local computer) from an April dump of articles, and later I could update that and post it somewhere for consideration. Example (the sandbox template invokes the sandbox modules and enables warnings; only the first problem is shown):

• {{convert|123|ft|disp=bogus|wrong=wronger}} → 123 feet (37 m)
• {{convert/sandbox|123|ft|disp=bogus|wrong=wronger}} → 123 feet (37 m)

Re my "too many options" comment above: I mean that it takes mental effort to remember all the option names. An example is that it's easy to remember that there is an option which rounds to the nearest 5, and if "disp" does nearly everything apart from abbr and adj, then trying "disp=5" will work. However, we would need to draft an alternative to the current system to assess whether that might be a problem. Johnuniq (talk) 02:12, 11 September 2014 (UTC)

OK. Only if it is easy to categorise specific (deprecated) options, that could help us. I'm talking the ugliest options only.

There is a plus side on what you say, but memorising that "disp=5" has to do with rounding is a bit weird. Especially since there is the (more easy to remember) "round=5" - or "near=5". -DePiep (talk) 02:17, 11 September 2014 (UTC)

There are levels of deprecation.

Level doc1: Document for user (editor). Plain user documentation

Level doc2: Remove from user documentation, or write way below. (does not require code change)

Level doc3: Technical/debug options: do not write in main doc page. (does not require code change)

Level code3, code4: (to follow. Code change needed)-DePiep (talk) 00:11, 12 September 2014 (UTC)

Deprecated options

The next parameter options are deprecated. The list is in development; improvements can be added.

• |disp=5 use: |round=5
• |disp=flip5 use: |order=flip |round=5
• |disp=mos use: |disp= (?)
• |disp=2 use: |disp=output only (or: disp=out?)
• |disp=u2 use: |disp=unit2
• |disp=s use: |disp=slash or |disp=/
• |abbr=comma use: |disp=nocomma -- wrong word!

-DePiep (talk) 18:58, 10 September 2014 (UTC) ... and later

Technical and debug

• |2=tonocomma (todo: use future |comma=none)
• |debug=yes debug, not for documentation. About |sortable=.

Parameter questions

• Q1 How definitive is |order=flip? If it is OK, it can be documented.
• Q2 Are |near= and |round= the same? I miss them in Help:Convert.
• Q3 Could you (Johnuniq) consider to add an option |comma=none or so, to replace |disp=nocomma? I think it fits nicely the |comma= series. -DePiep (talk) 20:50, 10 September 2014 (UTC)

All these are experimental—for us to evaluate. I'll get around to documenting the options, but if you are desperate it's reasonably easy to decode the table near the bottom of Module:Convert/text—that shows what "round" options are available. Also, if you take a bit of time to grasp the layout, the table quickly confirms that |disp=flip is equivalent to |order=flip (they each result in "opt_flip"). Both "near" and "round" are new—I'm now thinking we should keep round and delete near.

Re comma: Yes, it's easy to include comma=none, and all that needs cleaning. There is a ghastly undocumented option:

• {{convert|12345|to|12349|m|ft}} → 12,345 to 12,349 metres (40,502 to 40,515 ft)
• {{convert|12345|tonocomma|12349|m|ft}} → 12345 to 12349 metres (40502 to 40515 ft)

I would like to confirm that it is unused, then delete it from the module (it's built in to Module:Convert). Cleaning up the other comma options is just some easy edits to convert/text. All the odd options were for compatibility, and as Jimp notes above, the old template needed to reuse options which is why adj and disp are burdened with comma settings. Johnuniq (talk) 02:40, 11 September 2014 (UTC)

How do we do a "for us to evaluate"? They are in {convert} live now, so we just use them? I understand this is about |order=flip, |near=, |round=, .... No problem with this at all, but I'd like to learn the long term view on this. -DePiep (talk) 23:52, 11 September 2014 (UTC)

I added options near and order in response to Jimp's suggestion in August 2013 (before the module went live). Later (December 2013), when making the module guess a better default precision for ranges, I added the round option. By evaluate, I just mean that since the options work we can try examples in a sandbox and decide what to do. I'm thinking that near should be removed as redundant, and that we should proceed with planning deprecation for some other options. Johnuniq (talk) 04:01, 12 September 2014 (UTC)

• Q4 Is there a more gentle way to enter those |disp=x words?

No. MediaWiki trims leading/trailing spaces from parameters of the form |something=text, but not from unnamed parameters. Using |disp=x sometimes needs leading/trailing spaces, and sometimes not, so the parameters have to be unnamed. Johnuniq (talk) 04:01, 12 September 2014 (UTC)

Another pressure conversion

For Atmosphere (unit)#History {{convert|1,013,250|dyn/cm2|Pa|lk=on}} 1,013,250 dynes per square centimetre (101,325 Pa). Peter Horn User talk 17:17, 10 September 2014 (UTC)

Not an answer, but for these questions we could use a searchable help-subpage. -DePiep (talk) 22:04, 10 September 2014 (UTC)

Noted in Template:Convert/units not supported Peter Horn User talk 18:18, 13 September 2014 (UTC)

We discussed this at Template talk:Convert/Archive July 2014#New pressure conversion. There is no reason to use convert every time a unit is mentioned, and I still think convert should not be used for the cases discussed. Johnuniq (talk) 08:09, 14 September 2014 (UTC)

Option missing?

Resolved

To display only a part of the outcome, we have Help:Convert#Displaying_parts_of_a_convert.

{{convert|2|cuyd|m3}} → 2 cubic yards (1.5 m³) -- to compare

How can I get output "2 cubic yards"? -DePiep (talk) 20:15, 20 September 2014 (UTC)

I put the options for that at Help:Convert#Displaying parts of a convert. Unfortunately the code for handling the input is very complex and it does not format what the user enters apart from inserting commas. I have looked at what would be involved for an option to show the input (properly formatted) but it is tricky and I doubt it would be useful. At any rate, the workaround is to cheat:

• {{convert|2|cuyd|cuyd|0|abbr=off|disp=out}} → 2 cubic yards

Johnuniq (talk) 02:42, 21 September 2014 (UTC)

I've added the trick (workaround) to the Help page. OK with me. -DePiep (talk) 18:45, 21 September 2014 (UTC)

I'll have to look at what's been going on there because it was documented in the section we both linked at one stage. Johnuniq (talk) 03:00, 22 September 2014 (UTC)

Yes it was there last month (using a fraction demo). In my cleanups I deleted that one, but now it is back with a simple 2 cuyd demo. In explaining, I prefer not to introduce irrelevant parameters - they make it look more complicated. -DePiep (talk) 11:08, 22 September 2014 (UTC)

order=flip

Resolved

Time to document this? Kendall-K1 (talk) 16:24, 22 September 2014 (UTC)

Added Help:Convert#Flipping_the_order_of_output. Was already in /doc. Waiting for Johnuniq to proclaim deprecation of |disp=flip, formally. -DePiep (talk) 17:22, 22 September 2014 (UTC)

MJ/m3

For Coal gas#Gas for industrial use: {{convert|3.7|to|5.6|MJ/m3|abbr=on}} 3.7 to 5.6 MJ/m³ (99 to 150 BTU/cu ft) instead of 3.7 to 5.6 MJ/m³ (100-150 Btu/ft³ Peter Horn User talk 23:46, 21 September 2014 (UTC)

I added that unit:

• {{convert|3.7|to|5.6|MJ/m3|abbr=on}} → 3.7 to 5.6 MJ/m³ (99 to 150 BTU/cu ft)
• {{convert|3.7|to|5.6|MJ/m3|abbr=on|round=5}} → 3.7 to 5.6 MJ/m³ (100 to 150 BTU/cu ft)

Given abbr=on there are no range options that show "to" for the input and "–" for the output. Johnuniq (talk) 03:31, 22 September 2014 (UTC)

The link actually writes, hardcoded: "3.7 to 5.6 MJ/m³ (100-150 Btu/ft³ (std))". That is, it specifies BTU to be (std). BTU seems to have variant definitions. Even worse, there was a habit of writing "MBtu" for thousand (mille) BTU, not mega. Should we pay attention to that? -DePiep (talk) 12:16, 22 September 2014 (UTC)

Found this: Module:Convert/documentation/conversion_data/doc. Lots of BTU specifications. -DePiep (talk) 23:44, 22 September 2014 (UTC)

Examining the 1.7 million converts in all articles in May 2014 shows: 33 have BTU, 6 have btu, 5 have MMBtu (all in Firewood), 4 have MBtu (all in Exelon Pavilions), 3 have Btu. I think only 10 converts have an output different from what BTU would do. I don't think it's worth supporting more variations unless a real need is demonstrated. Johnuniq (talk) 00:08, 23 September 2014 (UTC)

120 BTU/scf

For Syngas#Energy capacity:
{{convert|120|BTU/sqft|MJ/m2|abbr=on}} and/or {{convert|120|BTU/ft2|MJ/m2|abbr=on}} 120 BTU/sq ft (1.4 MJ/m²) and/or 120 BTU/sq ft (1.4 MJ/m²) instead of 120 BTU/scf Peter Horn User talk 23:17, 22 September 2014 (UTC)

The link there, currently ref #18, does not work. -DePiep (talk) 23:35, 22 September 2014 (UTC)

I don't see how MJ/m2 (energy per unit area) would work. Should it be MJ/m3 and BTU/cuft? Johnuniq (talk) 00:12, 23 September 2014 (UTC)

No, the paragraph presents 120 BTU/scf without the missing t. This is BTU/area. Peter Horn User talk 00:45, 23 September 2014 (UTC)

I left a question at Talk:Syngas#BTU/area or BTU/volume?. Peter Horn User talk 00:58, 23 September 2014 (UTC)

"scf" in oil and gas industry context means "standard cubic foot" which is volume, not area. Beagel (talk) 17:53, 23 September 2014 (UTC)

So scf stands for Standard cubic foot. Thanks a million for the clarification. Peter Horn User talk 00:07, 24 September 2014 (UTC)

Energy or volume confusion

See the discussion section under the following table for what this is about. Johnuniq (talk) 02:46, 24 September 2014 (UTC)

Energy units to be checked

Energy units

Unit code Symbol US symbol Scale Extra Name Plural name US name US plural name Prefix Default Link scc scc 0.101325 standard cubic centimetre standard cubic centimeter mJ Atmosphere (unit) scf scf 2869.2044809344 standard cubic foot standard cubic feet kJ Atmosphere (unit) scfoot scf 2869.2044809344 standard cubic foot standard cubic foot kJ Atmosphere (unit) scy scy 77,468.5209852288 standard cubic yard kJ Atmosphere (unit) sl sl 101.325 standard litre standard liter J Atmosphere (unit) ccatm cc·atm 0.101325 cubic centimetre-atmosphere cubic centimeter-atmosphere mJ Atmosphere (unit) cm3atm cm3·atm 0.101325 cubic centimetre-atmosphere cubic centimeter-atmosphere mJ Atmosphere (unit) cufootatm cu ft atm 2869.2044809344 cubic foot of atmosphere cubic foot of atmosphere kJ Atmosphere (unit) cuftatm cu ft atm 2869.2044809344 cubic foot of atmosphere cubic feet of atmosphere kJ Atmosphere (unit) cuydatm cu yd atm 77,468.5209852288 cubic yard of atmosphere cubic yards of atmosphere kJ Atmosphere (unit) GLatm GL·atm 101,325,000,000 gigalitre-atmosphere gigaliter-atmosphere GJ Atmosphere (unit) Glatm Gl·atm 101,325,000,000 gigalitre-atmosphere gigaliter-atmosphere GJ Atmosphere (unit) impgalatm imp gal·atm 460.63256925 imperial gallon-atmosphere J Atmosphere (unit) kLatm kL·atm 101,325 kilolitre-atmosphere kiloliter-atmosphere kJ Atmosphere (unit) klatm kl·atm 101,325 kilolitre-atmosphere kiloliter-atmosphere kJ Atmosphere (unit) Latm L·atm 101.325 litre-atmosphere liter-atmosphere J Atmosphere (unit) latm l·atm 101.325 litre-atmosphere liter-atmosphere J Atmosphere (unit) m3atm m3·atm 101,325 cubic metre-atmosphere cubic meter-atmosphere kJ Atmosphere (unit) MLatm ML·atm 101,325,000 megalitre-atmosphere megaliter-atmosphere MJ Atmosphere (unit) Mlatm Ml·atm 101,325,000 megalitre-atmosphere megaliter-atmosphere MJ Atmosphere (unit) mLatm L·atm 0.101325 millilitre-atmosphere milliliter-atmosphere mJ Atmosphere (unit) mlatm l·atm 0.101325 millilitre-atmosphere milliliter-atmosphere mJ Atmosphere (unit) USgalatm US gal·atm U.S. gal·atm 383.5568490138 US gallon-atmosphere U.S. gallon-atmosphere J Atmosphere (unit) µLatm µL·atm 0.000101325 microlitre-atmosphere microliter-atmosphere µJ Atmosphere (unit) µlatm µl·atm 0.000101325 microlitre-atmosphere microliter-atmosphere µJ Atmosphere (unit)

Energy or volume discussion

The discussion at #120 BTU/scf above showed that the energy capacity of syngas can be given in BTU/scf = BTU per standard cubic foot (energy/volume).

Problem: convert has an scf unit, but it is energy rather than volume. There are several related units which don't make much sense to me; I've extracted them from the master list of units into the table in the previous subsection. Two of the old templates follow to show that the module has simply copied what they do (and I assumed they were energy because of the default output unit using joules).

• Template:Convert/scf (edit | talk | history | links | watch | logs)
• Template:Convert/cuftatm (edit | talk | history | links | watch | logs)

Looking at all convert templates in articles in May 2014, none of the above units are used. Would we want to think about removing any of them? Regardless of that, I'm hoping Jimp or others can clarify what these units should be. Are they correct? Are they energy or volume? Johnuniq (talk) 02:46, 24 September 2014 (UTC)

More thoughts: A standard cubic foot measures a quantity of gas rather than its volume. Presumably some long-forgotten formula would relate a standard cubic foot of an ideal gas to a certain amount of molecular kinetic energy, resulting in the scales shown? On that basis, I guess it is reasonable for the listed units to be regarded as energy, although it seems the units are unused. This theory would mean BTU/scf is energy/energy as far as convert is concerned, which is a bit odd—I guess BTU/scf really means energy per a standard quantity of gas, and it's probably not worth trying to shoehorn that into the convert template. Johnuniq (talk) 03:37, 26 September 2014 (UTC)

I think that scf is really dimensionless, as it's just a number of molecules. However if you convert BTU/scf, it takes units of energy because of the BTU and it will by default need to convert to BTU/scm, still takes units of energy, and it will obviously be bigger.

It may be that BTU/scf is what the 'scf' unit possibly means in the old convert.GliderMaven (talk) 03:57, 26 September 2014 (UTC)

The cubic foot of atmosphere is an energy unit equal to one cubic foot multiplied by standard atmospheric pressure (1 cu ft × 101.325 kPa = 3.4577615 kJ) i.e. the energy it would take to push a one-square-foot surface a distance of one foot where the difference in pressure between one side of the surface and the other is one atmosphere. According to the article, a standard cubic foot is a measure of quantity (like a mole): the amount of gas there is in 1 cu ft at a specific temperature and pressure (60 °F and 14.73 psi according to our article giving us 1.19804 moles though NIST says 21 °C and 101.35 except for LPG which is at 60 °F but pressure isn't mentioned). I don't know why the default went to kilojoules that was probably a mistake. So BTU/scf would be energy per unit of quantity which should probably convert to kJ/mol and/or kJ/scm (not a hybrid like BTU/scm though). Do we need them? If in seven years they've never been used, perhaps we can afford to ditch them. Jimp 02:21, 28 September 2014 (UTC)

Thanks, that makes sense. I might make a private note that these units could be removed but it's probably easier to leave everything as-is. Re BTU/scf: leaving it undefined would also be easy—we can wait until a clear need arises. Johnuniq (talk) 03:55, 28 September 2014 (UTC)

Some unit input options

• Here [3] I edited out an "inches" input unit (error), into "inch". And now it correctly outputs ... "inches". If it is easy to change, I suggest unit "inches" is recognized.
• From reading module:Convert/text (and nothing else) I see that to(-) has synonym to- recognised. Should then not and(-) have this option and-? As said, relevance may be theoretical only. -DePiep (talk) 19:20, 29 September 2014 (UTC)