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.

For the Lua module see the Module:Convert.
Convert tagged articles are in Category:Convert error categories
For earlier technical talks, see Technical archives.

abbr=off or abbr=none[edit]

{{convert/spell|1/2|m|in|abbr=off}}, one-half metre (20 in) or {{convert/spell|1/2|m|in|abbr=none}} one-half metre (20 in). 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[edit]

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

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)

[edit]

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 m2)"?
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 "" for abbr=on would be an interesting approach; however, "" 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 "" would be "".) 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)

Module version 5[edit]

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

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}} 38 inch (9.5 mm) 38 inch (9.5 mm)
{{convert|+3/8|in|mm}} +38 inch (9.5 mm) + 38 inch (9.5 mm)
{{convert|-3/8|in|mm}} 38 inch (−9.5 mm) 38 inch (−9.5 mm)
{{convert|3/-8|in|mm}} 3−8 inch (−9.5 mm) [convert: invalid number]
{{convert|5+3/8|in|mm}} 5 38 inches (140 mm) 5 38 inches (140 mm)
{{convert|+5+3/8|in|mm}} +5 38 inches (140 mm) +5 38 inches (140 mm)
{{convert|-5-3/8|in|mm}} −5 38 inches (−140 mm) −5 38 inches (−140 mm)
{{convert|5-3/8|in|mm}} 5 −38 inches (120 mm) [convert: invalid number]
{{convert|12+1/2|hand|in}} 12 12 hands (48.5 inches) 12 12 hands (48.5 inches)
{{convert|12.3+1/2|hand|in}} 12.3 12 hands (51.5 inches) 12.3 12 hands (51.5 inches)
{{convert|12.3+1/2|m|cm|0}} 12.3 12 metres (1,280 cm) 12.3 12 metres (1,280 cm)
{{convert|71<ref>Some reliable reference.</ref>|kg|lb}} [convert: invalid number] 71[1] kilograms (157 lb)
{{convert|12<ref>First ref.</ref>|to|34<ref>Second ref.</ref>|ft}} [convert: invalid number] 12[2] to 34[3] 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 12 hands is 12 hands 3 12 inches). Too much work is required to permit that only for hands, so 12.3+1/2 works for all units.

References
  1. ^ Some reliable reference.
  2. ^ First ref.
  3. ^ Second ref.

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 (HTML: &#8260; &frasl;) (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}}38 inch (9.5 mm) -- current, slash
{{convert|3⁄8|in|mm}}38 inch (9.5 mm) -- current, fraction slash
Sandbox (am I testing the right thing this way?):
{{convert/sandbox|3/8|in|mm}}38 inch (9.5 mm) -- sandbox, slash
{{convert/sandbox|3⁄8|in|mm}}38 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 &amp;frasl; 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}}[edit]

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}}m3

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

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)

Converting multiple input values in feet and inches to metres[edit]

The subject line says it all, I guess; I can't figure out how to cleanly use the template to convert multiple output values of feet and inches into metres. This functionality is needed at List of works by Oldenburg and van Bruggen; the only way I've figured out how to do it is by using metres as the input unit and disp=flip to swap the input and output units, which (a) is incredibly tedious and (b) produces monstrosities ike 37 ft 0 in. Any help would be appreciated. Graham87 02:49, 27 August 2014 (UTC)

Sorry, but ranges of input multiple units are not supported. One reason is that much more than feet and inches can occur (for example, a length might use miles, yards, feet, inches). However, I'm just looking at convert and I'll remind myself of how difficult a fix would be. I'll ping you if anything good happens. One ghastly workaround would be as follows (I am not recommending this!):
  • {{convert|23+6/12|x|24+11/12|x|10+11/12|ft|m|abbr=on}}23 612 × 24 1112 × 10 1112 ft (7.2 × 7.6 × 3.3 m)
Johnuniq (talk) 03:36, 27 August 2014 (UTC)
Wow! Yeah, that's probably not the best, either. :-) Graham87 04:04, 27 August 2014 (UTC)

I'm thinking about what would be involved in implementing ranges of input multiple units. There's quite a bit of complexity, so I'm not sure how far I'll go. One problem is that the normal syntax of convert would become unmanageable for the user and also for convert. If someone can write {{convert|2|ft|3|in|x|4|ft|6|in}} they might expect a mixture of units to work, such as {{convert|2|ft|3|in|x|4|yd}} and the latter is definitely not going to happen for a long time.

Therefore, I was contemplating a new syntax using colons and spaces as delimiters. The idea of the colon is that it is a character that should not occur in an input value, so convert can easily detect when the new syntax is used. Any views on the following?

  • {{convert|3:6+1/2 x 4:11 x 9:8 ft:in|m}}

The colons and spaces must be exactly as shown. The meaning is

3 ft 6 12 in by
4 ft 11 in by
9 ft 8 in

This feature would be rarely used, and the proposed syntax is pretty disconcerting, so I'm not sure if it's worthwhile. Another complication is that people might want a measurement with no feet or with no inches. I was thinking of the following syntax (both these would give the same result; not sure how hard implementation would be):

  • {{convert|3:6+1/2 x :11 x 9: ft:in|m}}
  • {{convert|3:6+1/2 x :11 x 9 ft:in|m}}

That is 3 ft 6 12 in by 11 in by 9 ft. Any thoughts? Johnuniq (talk) 03:51, 29 August 2014 (UTC)

A nice feature is that spaces are used, not pipes. That makes the input format more editor friendly! (because: more into write-what-you-expect-to-see). Might be nice for single-unit input too. -DePiep (talk) 16:25, 29 August 2014 (UTC)
Adding: why not add a parameter? Like |input_has_multiple_units=yes → treat number as doubles (triples). Still requires the colon separator, but I have the feeling it fits the grander scheme. (Maybe even, wasn't it old English writing "12/5" for 12 ft 5 in? That could allow the slash, given that the parameter is set). -DePiep (talk) 19:41, 30 August 2014 (UTC)

Metric horsepower[edit]

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)

Adjective in output[edit]

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: invalid option]
  • {{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)

Next grand step: {convert} 3.0[edit]

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 &nbsp; 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)[convert: invalid option]
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[edit]

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

  • 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)

Listing: units not supported[edit]

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

Gigalitres etc[edit]

For Murray–Darling basin#Physiography: {{convert|24,000|GL|km3 acre-foot|lk=on}} 24,000 gigalitres ([convert: unknown unit]) or {{convert|24,000|GL|km3 af|lk=on}} 24,000 gigalitres ([convert: unknown unit]) instead of {{convert|24,000|GL|km3|lk=on}} 24,000 gigalitres (24 km3) which works. {{convert|24|km3|acre-foot|lk=on}} 24 cubic kilometres ([convert: unknown unit]) or {{convert|24|km3|af|lk=on}} 24 cubic kilometres ([convert: unknown unit]) Peter Horn User talk 20:44, 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:

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

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

Display of common fractions in output[edit]

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 716 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 128 12 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)

Another pressure conversion[edit]

For Atmosphere (unit)#History {{convert|1,013,250|dyn/cm2|Pa|lk=on}} 1,013,250 dyn/cm2[convert: unknown unit]. 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)

Old {convert/...} templates not covered (e.g. {convert/text2})[edit]

With modern {{convert}}, multi-dimensional conversions usually look like:

  • {{convert|12|x|10|x|5|in|mm}} → 12 by 10 by 5 inches (300 × 250 × 130 mm) Green tickY
  • {{convert|12|x|10|x|5|in|mm|adj=on}} → 12-by-10-by-5-inch (300 × 250 × 130 mm) Green tickY

Below is a list of multi-dimensional old {convert/...} template usages, that are not covered by the {convert} template (module:convert). So these are old wikicode templates, that today cannot be replaced by the module, functionally. In brackets is the number of articles using it today.

demo: Fort McHenry: A 18, 24, and 38-pound (8.2, 11, and 17 kg) cannon
demo: ThinkPad X Series: 300×210×13–38 mm (12×8.2×0.5–1.5 in)
demo: 1980 eruption of Mount St. Helens: 23 miles across by 19 mi long (37 × 31 km)

Notes

- Even when usage is zero, the functionality is not present in current {convert}.
- The current 28 articles in here, are the result of a manual cleanup by me (where possible, modern {convert} was used). The remainning situations are the real differences.
- There may be other wikicode {convert/...} subtemplates in the same situation. I did not check. {{convert/spell}} is deprecated.

What to do? Nothing! I do not propose any consequence. This is just an overview. My impression is that it is not feasible to incorporate these options into current {convert}. (If I needed such a text myself, I'd construct it in a sandbox and then hardcode it in the article). -DePiep (talk) 22:00, 10 September 2014 (UTC)