Template talk:Convert

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

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

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

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

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.

• Template:Convert/2(edit talk links history) -- (5 articles)
• Template:Convert/3(edit talk links history) -- (4)

demo: Fort McHenry: A {{Convert/3|18|, |24|, and| 38|lb|kg|adj=on}} cannon

• Template:Convert/4(edit talk links history) -- (0)
• Template:Convert/flip2(edit talk links history) -- (0)
• Template:Convert/flip3(edit talk links history) -- (0)
• Template:Convert/flip4(edit talk links history) -- (1)

demo: ThinkPad X Series: {{convert/flip4|12|x|8.2|x|0.5|-|1.5|in|mm|abbr=on}}

• Template:Convert/text2(edit talk links history) -- (12)

demo: 1980 eruption of Mount St. Helens: {{convert/text2 |23|across by|19|mi|km|long}}

• Template:Convert/text3(edit talk links history) -- (6)
• Template:Convert/text4(edit talk links history) -- does not exist

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)

I agree: hard-coding is generally the best option when it comes to stuff like this. Most of the instances of these seem to have been in place just for the sake of it but a lot of the time the result was far less than ideal. I've just got rid of them. The only thing that might possibly be worth considering hanging on to could be some way of naming the dimensions: i.e. somehow to give something along the lines of "12 in long by 10 in wide by 5 in high (300 mm × 250 mm × 130 mm)".

P.S. As noted below, it would be better (I reckon) if the template went back to the old practice of following the MOS i.e. giving the unit each time when giving dimensions combined by a multiplication sign. Jimp 09:46, 22 September 2014 (UTC)

I'm the guy who put convert/flip4 into ThinkPad X Series, after coming here to ask how to do it. A little disappointed it's no longer possible but I guess I can live with that. Kendall-K1 (talk) 16:22, 22 September 2014 (UTC)

Sorry to disappoint. Jimp 22:13, 22 September 2014 (UTC)

You guys have always been very helpful, and the new convert is overall better than the old. I appreciate the work you do here, please keep it up. Kendall-K1 (talk) 11:06, 23 September 2014 (UTC)

I may not have been quite as bold as Jimp but I agree with the conclusion because I have seen some of the template invocations while wondering whether the module should attempt to support them. A very small number of cases seemed natural and useful, but too complicated to add to the module. Several other cases used a syntax that the vast majority of editors would never want to grasp. I can see the sense of "long by wide by high" in Jimp's example above, and a standard way of saying that may be worthwhile. Johnuniq (talk) 01:22, 23 September 2014 (UTC)

seems these have now been deleted (or rather deleted, then archived). Frietjes (talk) 00:15, 27 September 2014 (UTC)

Plastikpork reinstalled them at (e.g.): {{Convert/old/2}} (with no redirect from {{convert/2}}. I don't know yet their intention. -DePiep (talk) 00:23, 27 September 2014 (UTC)

• I have restored the original pagenames, as those templates are not "old" but rather more-advanced than the Lua-based Convert. The intention of {convert/2} or {convert/4} is to allow ANY text between the converted amounts; note well how any text can be inserted between the multiple amounts. Compare and note the words "up to" between amounts:

• {convert/2 |4|up to|5|ft|m}} - Template:Convert/2
• {convert |4|up to|5|ft|m}} - 4 up to
• {convert/4 |2|, |4|, |6|, or rarely|8|mi|km}} - Template:Convert/4
• {convert |2|, |4|, |6|, or rarely|8|mi|km}} - 2, 4, 6 , or rarely

Hence such templates, as {convert/2} or {convert/4}, add extra functionality beyond the current capabilities of the Lua-based Convert. -Wikid77 (talk) 17:19, 6 October 2014 (UTC)

They are 'old' wrt most standard usages (I was able to replace dozens of them with simple {convert}). Their documentation should be checked no to say that params & options are fully equal to those of {convert}. -DePiep (talk) 23:10, 6 October 2014 (UTC)

Wikid77: please do not revert turn hardcoded text into old {convert/xxx} templates. Hardcoding is OK, the templates are documented bad if at all, they are diverting from main {convert} documentation (params & options), and very unfriendly for the incidental editor. -DePiep (talk) 06:46, 8 October 2014 (UTC)

Please do not disrupt Wikipedia by edit-warring to remove conversion templates and re-hardcode the amounts, which has been shown to cause mismatches when hardcoded amounts are changed by hand. Hey, all conversions could be hardcoded, but templates exist to reduce the manual conversion errors, which have been documented in numerous cases for years. Also, you can claim those templates are "old" but they post-date the Lua Convert, as new templates or newer options than provided by the Lua version, such as avoiding nonsense ranges:
     • {convert |105|-|106|F|C }} - 105–106 °F (41–41 °C)
     • {convert/2|105|-|106|F|C}} - Template:Convert/2
I assure you the view as "very unfriendly" is in your own mind, or attitude, and several users have noted the full documentation for Convert has been overwhelming to incidental editors, compared to shorter, direct documentation for templates such as Template:Convert/2. -Wikid77 (talk) 15:51, 13 October 2014 (UTC)

{convert |105|-|106|F|C|sigfig=3}} → 105–106 °F (40.6–41.1 °C)

Solved once & for all. -DePiep (talk) 18:52, 13 October 2014 (UTC)

is in your own mind, or attitude, - don't be a dick. -DePiep (talk) 22:35, 13 October 2014 (UTC)

Of course you know those editors who came to you to say documentation for Convert has been overwhelming. That is because, until a few weeks ago, it was the old documentation unchanged for the old {convert} template: mostly as it was left a year ago. Also, the compactness of that specific documentation you mention assumes knowledge of the general usage of {convert} and its main params. You won't fool me: no incidental editor can make anything out of a first encounter with say {{convert/2}} + /doc. -DePiep (talk) 22:52, 13 October 2014 (UTC)

• See #Old templates in quarantine and Category:Old subpages of template:convert that are potentially used in mainspace.

-DePiep (talk) 12:15, 18 October 2014 (UTC)

Odd balls

For Indian locomotive class WAG-9#Technical specifications:
{{convert|1.6|mg/m3|abbr=on}} 1.6 mg/m³ (0.00070 gr/cu ft)
or perhaps {{convert|1.6|mg/m3|lb/cuyd|abbr=on}} 1.6 mg/m³ (2.7×10⁻⁶ lb/cu yd)
But {{convert|0.0016|mg/L|abbr=on}} 0.0016 mg/L (5.8×10⁻¹¹ lb/cu in) works.
{{convert|4|kg/t|abbr=on}} 4 kilograms per tonne ()
{{convert|6|kg/t|abbr-on}} 6 kilograms per tonne ()
{{convert|20|kN/s|abbr-on}} 20 kilonewtons per second ()

Peter Horn User talk 02:13, 19 September 2014 (UTC)

Recent edits to Indian locomotive class WAG-9 show that the following technical specifications were changed from the no-convert text shown to use converts which do not work because the units are not defined:

• Dust concentration in terrain

  1.6 mg/cubic meter

  {{convert|1.6|mg/m3|abbr=on}}

• Starting resistance of BOXN wagons excluding locomotive on level track

  4 kg/ton

  {{convert|4|kg/t|abbr=on}}

• Starting resistance of locomotive on level track

  6 kg/ton

  {{convert|6|kg/t|abbr=on}}

• Rate of change of tractive effort

  20 kN/sec

  {{convert|20|kN/s|abbr=on}}

• Rate of change of braking effort

  100 kN/sec

  {{convert|100|kN/s|abbr=on}}

Something could be done about the first because it is a simple density, but the others are rather mysterious and would need planning. What would they be converted to? How many articles would use the units? Is there an article on the type of unit?

Regarding the first, the density units need thought. What is the unit normally used for dust concentration? What would it be converted to? Is density the right article for a link?

I'm a bit of a wet blanket on issues like this because I don't think it's worthwhile to use the convert template for everything, and would prefer to consider a range of articles that would use new units both to see that the effort would be worthwhile and that we plan for the big picture. Johnuniq (talk) 04:30, 19 September 2014 (UTC)

"The others" (4) may be the product of the imagination of Indian mechanical engineers and as such may be found only in articles about the electric and diesel electric Locomotives of India.

. Peter Horn User talk 14:07, 19 September 2014 (UTC)

A time consuming solution would be to go through the revision history of Indian locomotive class WAG-9 and find out which user/contributor added those units and then post a request on his/her talk page asking him/her for an explanation on this talk page. Peter Horn User talk 14:18, 19 September 2014 (UTC)

"The others" (4) appear to have been added at some point by User:Swapnilshelatkar User talk:Swapnilshelatkar Peter Horn User talk 15:40, 19 September 2014 (UTC)

Make that User talk:Swapnilshelatkar#Clarify. Peter Horn User talk 15:47, 19 September 2014 (UTC)

I'm thinking. There could be a covering {convert-compose} module that uses the {convert} units & calculations & facts, and then formats the outcomes as needed (allowing more juggling). -DePiep (talk) 18:49, 21 September 2014 (UTC)

So why do we not simply get rid of the other 4 which do not appear to make sense? 22:57, 5 October 2014 (UTC)Peter Horn User talk

Hello Peter Horn User talk,I received your notification. I agree with you that the BOXN wagons resistance needs to be removed but others are quite relevant to the engine. They describe the performance of the engine. If you mention these in the Locomotives of India, the article is quite lengthy and there's no need to go in detail about WAG9 in that article.07:21, 14 October 2014 (UTC)Swapnilshelatkar (talk)

The whole idea is to be able to convert these units into ones that are more universally understood and accepted and be able to be documented/explained in an appropriate article/page. The name of the game is to inform and enlighten. Peter Horn User talk 14:39, 14 October 2014 (UTC)

Output unit appearing twice when two dimensions are used with anything other than "by" parameter

When using code such as {{convert|6|x|12|ft|m}}, the output unit is repeated twice, like 6 by 12 feet (1.8 m × 3.7 m). I don't think this is ideal, and it does not occur when using the "by" parameter to separate the dimensions, like 6 by 12 feet (1.8 by 3.7 m). Is there a particular reason for the discrepancy? I discovered it at September Morn. Graham87 13:09, 20 September 2014 (UTC)

Graham87, some like it, some don't, try {{convert|6|*|12|ft|m}} instead, and if that doesn't work for you, see Help:Convert#Ranges. Frietjes (talk) 14:44, 20 September 2014 (UTC)

@Frietjes: Thanks, that works. Graham87 14:58, 20 September 2014 (UTC)

I met this recently and our MOS is involved.

This is a measurement of area, so the dimension should be like m2. A physicist will always always write, correctly:

1 m × 3 m Y or 1 × 3 m² (but this is not MOS) Y

{convert} does not (I use mm, because ft-in would be confusing):

{{convert|1x3|m|mm}} → 1 by 3 metres (1,000 mm × 3,000 mm) ?

However, {convert} also has this old |abbr=mos trick:

{{convert|1x3|m|mm|abbr=mos}} → 1 by 3 metres (1,000 mm × 3,000 mm) Y

So, the "mos" notion is the correct one for dimensional (physics) measurements & dimensions. -DePiep (talk) 19:57, 20 September 2014 (UTC)

I add: when you use the by operator, the MOS says it is OK (that would reflect speaking language):

{{convert|1by3|m|mm}} →

So, from speaking (read wiki out loud!) there may be other rules. I am not familiar with these. -DePiep (talk) 20:08, 20 September 2014 (UTC)

The x range has special code to implement MOS: With the multiplication sign.... Per MOS, the unit symbol is repeated (abbr=on) but the unit name is not (abbr=off). As Frietjes says, Help:Convert#Ranges has the alternatives: xx is the closest which does not repeat the symbol (it puts a nonbreaking space on each side of the × multiply sign), or * which outputs the mutiply sign only (no spacing). Johnuniq (talk) 02:56, 21 September 2014 (UTC)

That when the multiplication sign is used the unit needs repeating but when using "by" it doesn't is a long-established MOS guideline. This was settled by consensus at MOS before ranges were added to {{convert}}. Originally the template followed MOS but, as mentioned, some don't like the rule. Attempts have been made over the years to have this guideline overturned but none have succeeded. So, there was a certain party in the I-don't-like-this-rule camp (I won't mention names) who decided instead simply to ignore it and went about editing the template to suit. This is the origin of abbr=mos: a code to allow users to follow MOS instead of said editor's preference (though billed as a special code for pages which may need changing at the drop of a hat to keep up with our capricious MOS as if the guidelines flipped to and fro willy nilly). It became clear what had been done and the template was restored to MOS-compliance. Not to be thwarted, though, said party introduced xx as a new way to break the rule. Is this what we really want: a {{convert}} which ignores the MOS, which caves in to some user's whim regardless of extensively debated community consensus? I propose we get rid of xx and * once and for all. Note that abbr=mos was removed early last year (if I remember correctly and so was disp=slash, disp=s and disp=/) only to be reinstated when the module version came into play (I'm probably the most to blame, I should have made it clear that they were gone). Anyhow, there still is a bunch of old rubbish which could be trimmed and I'd suggest non-MOS-compliant stuff be amongst the first to go. Jimp 06:13, 21 September 2014 (UTC)

• Support for art-world conversions: The use of non-MOS-compliant formats was intended to support text from the art world, such as a painting described as "20 × 30 cm (7.9 × 11.8 in)" where a survey of hundreds of paintings will prove the widespread usage of single "cm" in canvas-frame measurements. I do not know about the mindset of the above imagined "certain party" but I added Convert option "xx" in February 2010 (5 yrs ago) to show "×" in both sides (input/output) of a range conversion (where previously the option "x" would show "by" with "×" so perhaps think option "x" was "by(x)"). In general, support for art-topic articles requires more use of ellipsis (omitting redundant or obvious text), and hence the phrase "Beethoven's 9th" is a common artistic idiom to mean "Beethoven's 9th Symphony" as omitting the implied word "Symphony" not unlike omitting the 2nd "cm" in canvas sizes. In general, many unusual options of Convert have been added to support conversions in direct quotes, such as option "disp=sqbr" to show the output conversion in editorial square brackets ("[...]"), as meaning the converted amounts were not part of the original quotation. Note the results from {convert/old}:

• {convert/old |2|x|6|ft|m}} - Template:Convert/old
• {convert/old |2|xx|6|ft|m}} - Template:Convert/old

Again, I added option "xx" in 2010 to show both input/output with "×" (not by+x), as used in art canvas/wood measurements. -Wikid77 (talk) 23:22, 7 October 2014 (UTC)

Just a note: square brackets are also used in nested bracketing:

"The Battle of Grunwald (426 cm × 987 cm (168 in × 389 in))" better be "... (426 cm × 987 cm [168 in × 389 in])" -- this about brackets only. In science this is common practice.

See also #Deprecation of "/" (slash) joint below: the slash as separator is misleading (creating a common fraction).

Maybe we need to control exceptions through |nonmos=canvas, |nonmos=slash, |nonmos=x. (This could make a maintenance category listing & post-edit checks). -DePiep (talk) 07:20, 8 October 2014 (UTC)

That explains the nailed-on look of some of the options, thanks. Looking at all converts in articles in May 2014, around 6300 use x for a range, and 220 use xx. Two examples of the latter are here (end of first para). If I had been around at the time I would not have wanted convert to have a non-MOS style, but I'm also of the view that it's often better to cater for editor choice on issues where it doesn't really matter. I could make a sandbox list of articles with dubious options like disp=slash for inspection so we could decide whether some change was warranted. Unfortunately I took a snapshot of the convert templates at some time in 2013 and did not notice changes after that. Johnuniq (talk) 03:18, 22 September 2014 (UTC)

Again, for years wp:MOS maintained a rather narrow view of the world, which fomented many debates, but the so-called MOS "consensus" was often judged by majority rule, rather than correctly seen as "no consensus" to impose a guideline where a minority (of art editors or lumberjacks) opposed the limited data formats. Similarly, we have the infamous wp:DASH which decreed rare balderdash about forcing en dashes where hyphens had been used for centuries (re "hyphenated Americans"), while the real world has been removing even hyphens from words for decades (such as "teen-age" versus new "teenage"). Another troublesome issue has been forcing the lead zero (such as in "0.38") but .38 caliber weaponry has omitted lead '0' for decades. Too many MOS rules just infuriate too many editors, where the true status was "no consensus" to force guideline rules where several people objected strongly to subsetting reality. -Wikid77 (talk) 23:22, 7 October 2014 (UTC)

1. The minors: Yes, MOS is a witch but at least we all cope with the same witch. No, but if you think MOS is not valid because somewhere a conclusion was made incorrectly, start that talk elsewhere. No, hyphen for en-dash en-dash was not used for "centuries", only since the invention of the typewriter & telegraph (Ask Gutenberg); and your example "teen-age/teenage" is weird because you say that the hyphen is replaced while it is removed (btw, {convert}-related?). And if you think caliber is an exception why not make a proposal? (We have mach as non-linear, and I spend wearing a keyboard for the tabular {{Track gauge}}).

2. But really, parameter |abbr=mos contends for the worst parameter construction in enwiki (at least because it suggests that without it, it would do non-MOS?). I'm glad Jimp explained the history of this ugly beast, and we should get rid of this inherited bastard witchcraft asap by all means. -DePiep (talk) 07:09, 8 October 2014 (UTC)

To keep topic singular, I opened |disp=slash below. This thread can continue about "by" rangemulti-dimensional variants. -DePiep (talk) 18:44, 22 September 2014 (UTC)

Break to subtopic: repetition of the unit

I am preparing a roundup of this thread, to get back to a focus or two. (So far, I found these involved params: default, |abbr=mos, |abbr=on, Multiple dimension indicators x, xx, *, by, and MOS:UNITS).

But first I have some checking questions, about the repetition of the unit. MOS says:

• With the multiplication sign, each number should be followed by a unit name or symbol (if appropriate):

  •  1 m × 3 m × 6 m or (1 × 3 × 6) m, not 1 × 3 × 6 m or 1 × 3 × 6 m³

• With by the unit need be given only once: 1 by 3 by 6 metres or 1 by 3 by 6 m
  — MOS, Wikipedia:Manual_of_Style/Dates_and_numbers#Unit_names_and_symbols

For scientific and technical context, option 1 (1 m × 3 m × 6 m) is OK (as is the non-MOS option 4: 1 × 3 × 6 m³; let's forget about this one). It is correct, because the measurement is three dimensional: it is cubic (a volume). With this MOS rule, a scientist can edit & live happily in this wiki. Sure, that scientist will not use the by options, because they give the volume as a length dimension (metre). This can be said about every multi-dimensional measurement in science.

But. There is Issue #1: {Convert} has no way one, inconsistent, way to present that correct option (correct by MOS and by science), apart from plus the option |abbr=mos. Demos (for simplicity, I'll use two-dimensional examples, that is an area still not a length; so an m × m is required, for m²):

x

• {{convert|1|x|3|m|mm}} → 1 by 3 metres (1,000 mm × 3,000 mm) N -- See also issue #2 below.

{{convert|1|x|3|m|mm|abbr=off}} → 1 by 3 metres (1,000 by 3,000 millimetres) N -- Note that setting |abbr=off changed unit pattern, and "x" (= ×) changed into "by" (with a different MOS rule!)

{{convert|1|x|3|m|mm|abbr=on}} → 1 m × 3 m (1,000 mm × 3,000 mm) Y

• {{convert|1|x|3|m|mm|abbr=mos}} → 1 by 3 metres (1,000 mm × 3,000 mm) Y

by

• {{convert|1|by|3|m|mm}} → 1 by 3 metres (1,000 by 3,000 mm) Y

{{convert|1|by|3|m|mm|abbr=off}} → 1 by 3 metres (1,000 by 3,000 millimetres) Y

{{convert|1|by|3|m|mm|abbr=on}} → 1 by 3 m (1,000 by 3,000 mm) Y

• {{convert|1|by|3|m|mm|abbr=mos}} → 1 by 3 metres (1,000 by 3,000 mm) N -- See also issue #2 below.

xx

• {{convert|1|xx|3|m|mm}} → 1 × 3 metres (1,000 × 3,000 mm) N

{{convert|1|xx|3|m|mm|abbr=off}} → 1 × 3 metres (1,000 × 3,000 millimetres) N

{{convert|1|xx|3|m|mm|abbr=on}} → 1 × 3 m (1,000 × 3,000 mm) N

• {{convert|1|xx|3|m|mm|abbr=mos}} → 1 × 3 metres (1,000 × 3,000 mm) N -- See also issue #2 below.
• Note: In {{convert|...|abbr=off|abbr=mos}} |abbr= is overwritten, and so is not considered (|abbr=mos can not set |abbr=off and v.v.). Same for |abbr=on.
• Note: The * as in {{convert|1|*|3|m|mm}} is always a spacing variant only of xx, with or without |abbr=mos, and so does not add to this issue.

Issue #1. [added later; issue has shifted] It appears that |abbr=on combined with x answers my need: a correct scientific presentation. Remaining point: |abbr=off, nor the default does not do this (these two are clearly not the same). So it is not possible to write the scientific way with unit names.

Issue #2. Three examples show having two different schemes (single unit, repeat unit) in one conversion. Though probably not a breach of MOS (both schemes are allowed), it seems to me that this is a bad style. We have a guidance that even over the whole page we should apply same style per format issue. I think {convert} should not allow this. -DePiep (talk) 13:20, 16 October 2014 (UTC)

• A possible solution.

1. Parameter |x is always shown as "×", no changes into "by" or whatever (in input, in output in LH, in RH).

2. Parameter |x always repeats units, following MOS (example 1 m × 2 m × 3 m) (in LH, in RH)

3. Parameter |by is "by" always. Follows MOS about "by". (no changes?) (in LH, in RH)

4. Deprecate |abbr=mos, after all this is done (no loss of options)

5. Parameters |xx and |*: if kept, they produce × and so must comply with changes 1 and 2 ("×" not "by": repeat units always).

-DePiep (talk) 13:55, 16 October 2014 (UTC)

A more informal note by me. At last, by crafting this post, I understand and oversee the issues involved (or most of them). It dawned that the MOS is simple and clear about the "×" and "by" 'range-indicators' (actually, dimensional operators). They each have their own MOS rule. But in {convert}, the two are mixed, in various ways (the examples show). I am not interested in where that came from, and we don't need to know that to get a proper outcome (target). That target is, {convert} should simply keep them apart always & everywhere, as I just proposed. So far, I have not seen situations the require an exception (format "by" using "×"-rules or v.v.?; see the painter's canvas example mentioned earlier: not compelling, should do with MOS). And with these two MOS-compliant options, there is no need for any |abbr=mos option. -DePiep (talk) 14:54, 16 October 2014 (UTC) ("input/output" is confusing; use LH, RH instead. -DePiep (talk) 11:34, 18 October 2014 (UTC))

We only need these situations (constructed here); unit names or symbols alike:

• {{convert|1|x|3|m|mm}} → 1 metre × 3 metres (1,000 mm × 3,000 mm) -- MOS, "×"
• {{convert|1|by|3|m|mm}} → 1 by 3 metres (1,000 by 3,000 mm) -- MOS, "by"

disp=mos deprecated and not needed.

If the unspaced (asterisk) variant stays, it's this one:

• {{convert|1|*|3|m|mm}} → 1 metre×3 metres (1,000 mm×3,000 mm) -- not MOS.

-DePiep (talk) 16:14, 19 October 2014 (UTC)

Break to subtopic: deprecate options |xx| and |*|?

In the main thread the issue was raised to deprecate options xx and * (called "range-indicators", while used as multi-dimensional operator). Parameter x is the base. MOS involved: MOS:UNITS.

Presumptions

• For ease of reasoning, we assume that parameter "x" follows MOS as projected in the subtopic section above. That is, 1. within one {convert} call, only "×" is used (not "by"), and 2. units are repeated (there is no mixup with "by" rule). The "by" option is not relevant for this issue. Current working of basic "x":

{{convert|1|x|2|m|mm}} → 1 by 2 metres (1,000 mm × 2,000 mm) N -- current. Uses both "by" and "x" forms (although each one is correct)

x - projected

• {{convert|1|x|2|m|mm}} → 1 metre × 2 metres (1,000 mm × 2,000 mm) Y -- proposed above, hardcoded here
• {{convert|1|x|2|m|mm|abbr=on}} → 1 m × 2 m (1,000 mm × 2,000 mm) Y
• {{convert|1|x|2|m|mm|abbr=off}} → 1 metre × 2 metres (1,000 millimetre × 2,000 millimetres) Y -- proposed above, hardcoded here

xx

This is a variant derived from "x", by mentioning units differently:

• {{convert|1|xx|2|m|mm}} → 1 × 2 metres (1,000 × 2,000 mm) N -- Not MOS. Both "x" and single-unit in one measurement!
• {{convert|1|xx|2|m|mm|abbr=on}} → 1 × 2 m (1,000 × 2,000 mm) N -- Not MOS. Both "x" and single-unit in one measurement

This option can be rejected (deprecated), because a mixup of the "x" and "by" rules (do or do not repeat units) is not by MOS.

*

The asterisk does the same as "xx", but with spaces removed:

• {{convert|1|*|2|m|mm}} → 1×2 metres (1,000×2,000 mm) N -- Not MOS.
• {{convert|1|*|2|m|mm|abbr=on}} → 1×2 m (1,000×2,000 mm) N -- Not MOS.

This variant is to be deprecated for the same reason as "xx". No strong reason for the nonspacing is put forward.

On top of that, a non-spaced "×" is not MOS any time, too (two MOS breaches).

Outcome. Once the proposed changes for x are applied (see section above), there is no need for "xx" and "*" variants or exceptions any more. However, if the above x change is not implemented, this reasoning shoud be rebuild with different presumptions. Conclusion: after "x" changes are applied, deprecate these two parameters. "xx" should be read as "x"; "*" should be handled as ... (tbd. Spaced × too?). -DePiep (talk) 15:40, 16 October 2014 (UTC)

(Sorry, I must correct myself. Decisions better be crisp & clear):

There can be good arguments to keep the unspaced option (|*|).

• projected: {{convert|1|*|2|m|mm|abbr=on}} → 1 m×2 m (1,000 mm×2,000 mm) -- hardcoded here

-DePiep (talk) 18:37, 18 October 2014 (UTC)

Here is a case where we use some × format unspaced: "2.6×106 y". A tight infobox table (iron, see bottom isotopes table; mobile view). Even more important: the mobile view of that box does not shown table lines. So structure visible through column- & row-recognition (by the eye). In this whitespace-is-all situation, a spaced × could create confusion. Note however, that this example does not require repeated units. -DePiep (talk) 15:11, 20 October 2014 (UTC)

Deprecation of "/" (slash) joint

Forked topic about join using a 'slash'

Above, Jimp proposed to deprecate the option |disp=slash (and its synonyms |disp=/, |disp=s). (See here)

• {{convert|10|km|mi|disp=slash}} → 10 kilometres (6.2 mi) N

I forked this topic into a subthread. -DePiep (talk) 18:44, 22 September 2014 (UTC)

I personally can agree with deprecation. But first I'd like (a) to hear Johnuniq about this, and (b) what kind of deprecation? We can "remove from documentation" (soft) or "remove from code" (tough; requires bot cleanup). -DePiep (talk) 18:52, 22 September 2014 (UTC)

I put a list of all 76 converts in articles in May 2014 that use disp=/ or disp=s or disp=slash in my sandbox (permalink). The articles need to be studied to see whether the slash usage is desirable. After that we can think about deprecation, although again my general view is that a template should not impose a style unless the alternative is really unhelpful. Johnuniq (talk) 01:58, 23 September 2014 (UTC)

The slash has a meaning in numbers. The output with a slash is simply producing the scale factor. From the examples: 295,800 lb/134,000 kg = 2.207. This factual number meaning precedes a style. To allow an exception it meaning something else (as this option does), imo requires a specific MOS rule at least. -DePiep (talk) 12:31, 26 September 2014 (UTC)

Self-trout! In this category page (I created as a serious {convert}-derivative), the "/" (slash) is used to mean "or". We sure do need more guidance & rules in this. For now, I don't know which. -DePiep (talk) 19:55, 26 September 2014 (UTC)

As DePiep mentions above, the slash does have a specific meaning (trout or no trout) and this is why I've been keen to get rid of it for years. I haven't looked through all the examples provided above but "570 mph/917 km/h; 495 kn" is an excellent one to show just how awful this option can be. Jimp 10:28, 8 October 2014 (UTC)

So at least for this article I've taken the liberty to put the more sensible disp=or in place of disp=/ but I was a little disturbed to see "570 mph or 917 km/h or 495 kn" (instead of "570 mph, 917 km/h or 495 kn"). Jimp 10:36, 8 October 2014 (UTC)

Anyhow, yes, we've got to take a good look at each of the examples of slashes to see whether it would be desirable to keep the slash but I'd suggest that what we'll find in every case is that is is not. Here's another beauty "A 1986 survey of Canadian ice shelves found that 48 km²/19 sq mi/3.3 km³/0.79 cu mi of ice ..." ... what the ... Jimp 11:09, 8 October 2014 (UTC)

I've have a look at about half of these and so far disp=or has made much more sense. Jimp 11:11, 8 October 2014 (UTC)

Re disp=or: I was pleased with that enhancement! It was prompted by a request at zhwiki to change the standard ";" between units in an output combination, and went live at enwiki in July 2014. Anything looks a bit odd when there are more than two output units, but I like the "or" between outputs. Johnuniq (talk) 02:56, 9 October 2014 (UTC)

I don't remember whose idea that was but I've never liked the semicolon; it's just ungrammatical. Using "or", as in "40 knots (74 km/h or 46 mph)" or "300 K (27 °C, 540 °R or 80 °F)" rather than "40 knots (74 km/h; 46 mph)" or "300 K (27 °C; 540 °R; 80 °F)", seems to make more sense to me; this is how English works. The semicolon has a specific grammatical function and this ain't it. I had been planning to replace it with "or" as part of a revamp of the template. Jimp 04:26, 9 October 2014 (UTC)

I've looked through the rest of them. I couldn't find a single one where keeping the slash was a good option. Jimp 09:00, 10 October 2014 (UTC)

I just checked that none of the articles listed in the sandbox use slash now, so good work at removing them! I guess they can be deprecated. I'm a bit uneasy about removing the option from the module, but the documentation could be updated. I would remove disp=/ and disp=s from the documentation, and move disp=slash to a deprecated section. Johnuniq (talk) 10:07, 10 October 2014 (UTC)

Done in Help:Convert and Template:Convert/doc. Will edit whenever I see another one. Maybe we want to use more discouraging words. About removing from module: when we have collected a list of these, we can ask a bot to check+edit all pages and then remove from module code. Good programming habit says that we may not assume that it is unused, not even today. -DePiep (talk) 16:49, 10 October 2014 (UTC)

Another option: the code could replace the output character "/" with "_or_" right away without questioning. That would leave the parameter option "slash" without error. (Still deprecation in /doc should fade its presence out, long term). -DePiep (talk) 08:04, 14 October 2014 (UTC)

Changed: I mentioned all three options as deprecated in the /doc. As long as they can appear in an article, they should be in the /doc somewhere, to be found. -DePiep (talk) 10:25, 16 October 2014 (UTC)

I read consensus. So, in documentation now:

• disp=slash, disp=s, disp=/ are deprecated. Use disp=or instead

Consequences tbd. (Delete from source code, hardcode to show " or " right away, ...). -DePiep (talk) 18:29, 18 October 2014 (UTC)

Conversion of board foot and cord (unit)

For Petrograd Standard: {{convert|1000|BF|m3|abbr=on|lk=on}} 1,000 BF {{convert|1000|bf|m3|abbr=on|lk=on}} 1,000 bf {{convert|1000|fbm|m3|abbr=on|lk=on}} 1,000 fbm Ditto for cord (unit) Peter Horn User talk 13:08, 24 September 2014 (UTC)

It would be handy if the text "A complete list is at the full list of units" were more prominent on the documentation page, although it is hard to see how that could be done in a reasonable way. Anyway, search Template:Convert for "full list", click the link, then search for "board" and "cord". Johnuniq (talk) 02:42, 25 September 2014 (UTC)

Yes. By the way, for current {{Convert/doc}}, I stole everytihng usable from Help:Convert. So far about unit lists -DePiep (talk) 22:39, 26 September 2014 (UTC)

I haven't been paying attention because I need a longish break from convert tedium, but it sounds like convert/doc and help:convert now have a lot of duplicated material. Ugh! You created help:convert and I was skeptical at first, but then got enthusiastic because there is sufficient material to justify making help pages, and help pages are more suited for displaying a lot of stuff than a doc subpage IMHO. I think convert/doc should have a very brief statement of the facts with examples of the more commonly used options, and perhaps the units list, and a link to help:convert. Whatever happens, there must not be a significant duplication of documentation because that confuses everyone, and will lead to inconsistencies. Johnuniq (talk) 00:13, 27 September 2014 (UTC)

I am surprised to remember that I created the Help page :-) . It was in the building days a year ago, to illustrate the documentation setup was done for {{cite ref}} templates. Then it was you who filled it with full module materiel; the /doc kept old stuff during the transition process. The Help page had the more complete & current situation. So far so good. Recently I started bringing the template:Convert/doc page into current Module description (getting rid of old wikicode references). It has a slightly different approach (namely, aimed at the editor who wants to use the template).

I have the opinion the /doc page should be a concise overview, not complete into every detail. For units presented there, there should be a short list (top-50 or so), and a folded longer list or even complete list (searchable, sortable). IMO the unit lists can be improved into this.

Of course there can be an overlap in the two pages. The pages have a different approach. The Help-page can be more complete (e.g., as it is about line wrapping), maybe with MOS links and other backgrounds. Help is about conversion, /doc about the conversion template. -DePiep (talk) 10:35, 27 September 2014 (UTC)

Let me put it this way.

The Template:Convert/doc page shall be the first port of call for any {{convert}}-using editor. It shows, up to the max of convenience, the top units and top parameters+options. For details, there is the link option (expect a Help-page).

The Help:Convert page shall be more complete, describing: MOS, glossary (precision, rounding, sigfig), defaults, extremes (hands), full unit list, unit-type understanding (dimension), wording issues (plural vs singular, grammar, spelling), and all subtleties discovered (by Johnuniq mostly, and in this talkpage's archives) in the process, deprecated parameters, ...

-DePiep (talk) 19:54, 27 September 2014 (UTC)

Yes, that sounds great. Since I have a list of all converts in articles, I could work out which are the commonly used units, and perhaps even the commonly used combinations of options—then we could make sure convert/doc covers those points. I'll ponder that. Johnuniq (talk) 01:50, 28 September 2014 (UTC)

As for lists of units we need, I have this live example. For {{Track gauge}} (which does conversions in a way), I made module:Track gauge/autodocument that reads the core module:Track gauge/data page to produce overviews like Template:Track gauge/doc/input options. For convert/data, it could have options like "use a top-50 unit list", or "type=area only". Smartly, it should not be in the main module, to prevent 650k transclusions. (And this is to cheer us up: [1]) -DePiep (talk) 18:36, 29 September 2014 (UTC)

So no resolution yet? Peter Horn User talk 22:52, 5 October 2014 (UTC)

If you tried what I said at 02:42, 25 September 2014 above and there is still a problem, please explain what it is. Johnuniq (talk) 23:31, 5 October 2014 (UTC)

Will try. Peter Horn User talk 20:06, 6 October 2014 (UTC)

Eureka! {{convert|1000|bdft|m3|sigfig=4|abbr=on|lk=on}} 1,000 bd ft (2.360 m³), giving it to the nearest litre or dm³. Thanks for the directions. Peter Horn User talk 20:44, 6 October 2014 (UTC)

Some unit input options

• Here [2] 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)

Practical roundoff with feet and inches for sensible sentence structure

How does one get 0.9m expressed as 3 feet proper using some kind of rounding or tolerance control? To actually specify that the target units should be feet seems a step too far -- hardly any different from writing the figures verbatim, and one might still want inches for 1.0 metre (3 ft 3 in) but prefer a 5% tolerance where it can make the sentence flow better.

{{convert|0.9|m}} gives 0.9 metres (2 ft 11 in) at time of writing (now: 0.9 metres (2 ft 11 in)). The S-mine page is peppered with 11in roundoff glitches for figures I suspect were at some point imperial and loosely converted back to metric. --sh1 (talk) 19:57, 30 September 2014 (UTC)

The m unit is a bit odd: its default output is normally ft (feet), but is ftin (feet and inches) if the m value is between 0 and 3. The rounding can be controlled as in these examples:

• {{convert|0.9|m|ft}} → 0.9 metres (3.0 ft)
• {{convert|0.9|m|ft|0}} → 0.9 metres (3 ft)
• {{convert|0.9|m|ft|3}} → 0.9 metres (2.953 ft)
• {{convert|1.0|m|ftin}} → 1.0 metre (3 ft 3 in)
• {{convert|1.0|m|ftin|2}} → 1.0 metre (3 ft 3.37 in)
• {{convert|1.0|m|ftin|frac=2}} → 1.0 metre (3 ft 3+1⁄2 in)

It's true that convert does not add much value in this case, but people like to use it because it outputs the proper non-breaking space before the output unit symbol (but a standard space before a unit name). If there is a problem I've missed, please be more specific. Johnuniq (talk) 22:56, 30 September 2014 (UTC)

Well, maybe if we start by removing the 0 in from this to improve readability:

• {{convert|0.3048|m}} → 0.3048 metres (1 ft 0 in)

After that, the problem is where you generally want feet and inches for most figures, but find that 2 ft 11 in is an unnecessarily verbose way of approximating 90cm (or, conversely, that 91cm is an unnecessarily verbose way of approximating 3 ft). One way of addressing this would be to dynamically suppress precision (for brevity) as far as possible while fitting within a tolerable error margin -- eg.:

• {{convert|0.9|m}} → 0.9 metres (2 ft 11 in)
• {{convert|1.0|m}} → 1.0 metre (3 ft 3 in)
• {{convert|0.9|m|tol=5%}} → 0.9 metres (3 ft)
• {{convert|1.0|m|tol=5%}} → 1.0 metre (3 ft 3 in)

So include inches only if they're necessary to express the value to within 5% of actual. This might logically extend to rounding the number to only a couple of significant figures. The goal here is to improve readability by removing unnecessary detail (most particularly when it's an historical rounding aberration), so it's all fairly subjective.

Another approach might be to tweak the original unit (0.91 metres) but to round that version for display as well. --sh1 (talk) 06:58, 1 October 2014 (UTC)

I don't think anything needs to be fixed—just use the wanted output unit, and if you don't like the default precision, specify one:

• {{convert|0.3048|m}} → 0.3048 metres (1 ft 0 in)
• {{convert|0.3048|m|ftin}} → 0.3048 metres (1 ft 0 in)
• {{convert|0.3048|m|ft}} → 0.3048 metres (1.000 ft)
• {{convert|0.3048|m|ft|6}} → 0.3048 metres (1.000000 ft)
• {{convert|0.305|m|ftin}} → 0.305 metres (1 ft 0 in)
• {{convert|0.305|m|ftin|frac=64}} → 0.305 metres (1 ft 1⁄64 in)

In the above, the first and second have identical results because ftin is the default for 0.3048 m. It would be misleading to omit "0 in" because that indicates the precision of the measurement (it's to the nearest inch rather than the nearest foot). Johnuniq (talk) 09:00, 1 October 2014 (UTC)

Rate of progress per day.

For Track gauge conversion#Conversion rate: {{convert|20|km/day|mpd|abbr=on}} 20 km/d () instead of 20 km/day. In the mean time I used {{convert|20|km|mi|abbr=on|disp=or}}/day 20 km or 12 mi/day. Peter Horn User talk 23:03, 5 October 2014 (UTC)

• In general, use {convert/f} or {convert/per} for denominator conversions: There have been so many combinations of units, and hence inserting the literal "/day" with Template:Convert/f is the easiest general solution. Also, for conversions in the denominator, then the Template:Convert/per is the general solution to the thousands of various possibilities. Examples:

• {convert/f |20|km|mi|x2=/day|x5=/day}} - Template:Convert/f
• {convert/f |140|km|mi|x2=/week|x5=/wk}} - Template:Convert/f
• {convert/per|4|stops|km|mi}} - Template:Convert/per
• {convert/per|1|dog|km2|sqmi|out=dogs}} - Template:Convert/per

There is no feasible alternative to all the myriad combinations. -Wikid77 (talk) 16:26, 6 October 2014 (UTC)

or use {{convert|20|km/d|mi/d|abbr=on}} Frietjes (talk) 17:37, 6 October 2014 (UTC)

• Well, km/d works, but beware problems such as "USgal/d" whereas Template:Convert/f can show USgal to litres in the same manner as km to mi. Compare:

• {convert|20|km/d|mi/d|abbr=on}} - 20 km/d (12 mi/d)
• {convert|33|USgal/d|abbr=on}} - 33 US gal/d (1.4×10⁻⁶ m³/s)
• {convert/f |33|USgal|L|x2=/day|x5=/day}} - Template:Convert/f

Convert has been showing 33 USgal/day as "1.4×10⁻⁶ m³/s". In general, {convert/f} allows more flexibility for other units per day. -Wikid77 (talk) 16:13, 13 October 2014 (UTC)

Template:Convert/numdisp

Template:Convert/numdisp (edit | talk | history | links | watch | logs)

Resolved

 – Template deprecated; old code continues at {{hands}}, outside of {convert}

-DePiep (talk) 11:25, 18 October 2014 (UTC)

it looks like this template is used in under 500 articles (about half are from the {{hands}} template). I suggest we move it to a more generic name, since it's not used by {{convert}}. another option would be to expose this sub-feature in the LUA module? Frietjes (talk) 14:53, 15 October 2014 (UTC)

IMO: First we should replace instances with {convert} where possible in content space (articles, maybe WP-ns).

Then, if all its features are covered by {convert} then it should be deprecated (and kept alive for archives, harmless). But remaining article transclusions indicate features that are not (yet) in {convert}'s module. These can either be left alone (with continued full support by the template) or turned into hardcoded text. In this case of potential article usage, documentation must be (brought) up to standard quality.

I don't think this we should rename/move. There are more similar templates #like {convert/text2} with uncovered features, albeit exotic or zero in usage. It is good for overview & recognition if their names fit a pattern. -DePiep (talk) 15:48, 15 October 2014 (UTC)

Complication. In horse, the template is used but indirectly: {{Hands}} calls this one (and maybe others in the article too). So {Hands} is relying on those subtemplates.Maybe it makes more sense to turn {hands} into a {convert}. Anyway, renaming a template in such a spaghetti calling requires some analysis first. -DePiep (talk) 15:59, 15 October 2014 (UTC)

Frietjes already wrote this, my bad - sorry. Adding: also used by {{convert/per}}, see rocket. -DePiep (talk) 16:10, 15 October 2014 (UTC)

yes, in theory, {{hands}} can be replaced by convert in about 95% of the cases. however, in practice, any changes to horse articles will be swiftly reverted. Frietjes (talk) 16:20, 15 October 2014 (UTC)

I see. Ouch. Still, I think renaming is not a good idea. [3] /numdisp is used all over the old wikicode convert scheme. My preference is to keep the name pattern (we'll notice the warning it has), and keep them in check from this page (reduce need & usage whenever possible). Should we create a "Category:convert/xxx subtemplates that are (potentially) used in mainspace"? I expect a dozen or two. -DePiep (talk)

Category:Subpages of template:convert that are potentially used in mainspace. - A more serious cat name suggestion. Is this the way to keep an eye on them? -DePiep (talk) 20:01, 15 October 2014 (UTC)

I'd been meaning to deal with that one but it slipped my mind. Yes, {{hands}} could be replaced by {{convert}} but if the attitude is that we should keep our hands off, it probably isn't worth pushing for. I think I recall noticing that there were only a very small number of articles which seem to be be using {{convert/numdisp}} without going through {{hands}} and that those could probably be standardised to use the normal {{convert}}. Here's what I'm suggesting. Move {{convert/numdisp}} to {{hands/numdisp}} (along with its subpages) leaving redirect and let {{hands}} call {{hands/numdisp}} instead of {{convert/numdisp}}. Then we be able to clearly see what is calling {{convert/numdisp}} via channels other to {{hands}} and decide whether {{convert/numdisp}} is worth even keeping. If it is and this I doubt, we could duplicate it. Then we could do a bit of tidying up (the full {{convert/numdisp}} as it is is a bit of an overkill for what's required by {{hands}} anyway). Jimp 00:25, 16 October 2014 (UTC)

Sounds good. This /numdisp is also in article-grade templates (i.e., with features not in {covert}): {{Convert/f}}, {{Convert/per}}, {{convert/flip2}} (series, see top section), and maybe more. Given that tranc numbers are low, the move & copycode plan can be done. -DePiep (talk) 01:30, 16 October 2014 (UTC)

;-) I'm glad you followed my advice even before I wrote it [4]. -DePiep (talk) 15:44, 16 October 2014 (UTC)

• {{convert/numdisp}} deprecated.

Content page has been moved to {{hands/numdisp}} (an active subtemplate in non-Lua wikicode serving {hands}), here remains {{convert/numdisp}} for old convert usage; a redirect. However, this one is not used at all, and so is deprecated. -DePiep (talk) 11:21, 18 October 2014 (UTC)

Spelling out numbers and units

Currently {{convert|10|mi|m|spell=on}} is giving us "ten miles (sixteen thousand m)". Besides just looking wrong MOSNUM says it is wrong: "Do not spell out numbers before unit symbols ..." spell=on should apply to the unit as well and give us "ten miles (sixteen thousand metres)". We shouldn't expect users to have to go to the trouble of adding the abbr=off just to get something sensible. Jimp 05:15, 16 October 2014 (UTC)

Looks like Template:Convert/words (edit | talk | history | links | watch | logs) is active in this area. -DePiep (talk) 23:15, 18 October 2014 (UTC)

{{Convert/words}} is another thing altogether but no less dodgy. It wants its own section. Jimp 02:43, 19 October 2014 (UTC)

Rounding the input

As I've mentioned a few times in the past, the structure of the old version made it difficult to add new parameters which meant that new functions were often added using (or abusing) the existing ones. This resulted in a whole bunch of counter-intuitive codings. Here are three of them: adj=ri1, adj=ri2 and adj=ri3. These had nothing at all to do with adjectives verses nouns but were for rounding the input. This is a useful option but doing it this way is less than ideal. Besides being counter-intuitive we limited to rounding to 1, 2 or 3 decimal places. Perhaps we could create a new parameter for rounding the input to allow any precision we choose then we could eliminate this particular set of odd balls. Jimp 05:51, 16 October 2014 (UTC)

I support getting the three mentioned replaced.

Currently, output can be rounded by |round=5, |round=25, |round=each (each is for ranges). Can we allow more integers rounding for output too, and with similar pattern (same for editor)?

New parameter name |roundin=? Add another parameter that rounds both in and out (which would be redundant but easifying; |roundall=)? signed, late: -DePiep (talk) 19:23, 18 October 2014 (UTC)

No comma

Whilst I'm at it, I'd like to mention abbr=comma, disp=nocomma and adj=nocomma. Here we have another feature which was forced to use inappropriate parameters (note how disp=nocomma is not opposite to but entirely different to disp=comma). The reason that there were three ways of getting no commas was in case users wanted to combine this with another function of one of these parameters. We don't have to do things like this with the new version. Let's introduce the more logical and consistent option of comma=off (c.f. comma=gaps, comma=5, comma=gaps5, etc.) and eliminate these misuses. Jimp 06:06, 16 October 2014 (UTC)

In the documentations, I did this one for being counter-intuitive: "abbr=comma is deprecated. Use adj=nocomma instead". Discussion about |adj=nocomma can continue. -DePiep (talk) 10:10, 16 October 2014 (UTC)

Missing gaps

It seems that comma=gaps is failing to add gaps after the decimal point. Compare {{convert|12.3455467|in|comma=gaps}} to {{val|12.3455467|u=in}}. Jimp 06:12, 16 October 2014 (UTC)

Pluralisation override

MOS:DECIMAL says "Nouns following a number expressed as a decimal are plural" so wouldn't it make sense to ditch adj=1? Jimp 06:25, 16 October 2014 (UTC)

Deprecated: disp=2, disp=u2

I have just deprecated these two options:

• disp=2 is deprecated. Use disp=output only instead
• disp=u2 is deprecated. Use disp=unit2 instead

An alternative is available, and their coding is not fit for memorizing. No need to load documentation with these clueless redundancies. -DePiep (talk) 00:01, 17 October 2014 (UTC)

I agree. disp=2 and disp=u2 may be short but they are unclear. What we really need now is someone with a bot which could go through and remove these deprecated codings from transclusions and once this is complete they sould be removed altogether. Jimp 05:27, 18 October 2014 (UTC)

Thanks for the support (btw, "their coding" is to say that they are code-words, not English words; nothing with lua code; e.g., we use "out" not "2").

As for the bot task, this would be an non-disruptive way: as param options, eight now are declared deprecated in documentation. I suggest we wait some weeks or months until that red list is fleshed out and complete, (via this talkpage or by sandbox). Better to have strong and stable statements about deprecation first. Then, a bot can do a single run (650k pages) for all these param changes. And then within day someone puts the prepared sandbox code into live (with option support removed). -DePiep (talk) 06:55, 18 October 2014 (UTC)

More deprecations

As a matter of interest, I once saw a statement that a reason for choosing options like "2" or even "u2", apart from brevity, is that if convert is copied to another Wikipedia, they don't like using English names for the options. That consideration no longer applies because the module can be customized to use whatever localized names are wanted, so deprecate away. I don't see why we would inflict disp=output only on users when disp=out does the job, and where "out" is similar to usage such as lk=out. If we do remove unwanted options, we'll have to think what to do with non-article pages. For example, would a bot "fix" a convert on an archive of this page? I'll catch up with other points on this page later. Johnuniq (talk) 09:16, 18 October 2014 (UTC)

I'd be happy to deprecate more of these, but these two were the easy, low hanging fruit. For me it also had the benefit of getting rid of specific Irish music associations (how low can fruit be?!).

For other deprecations like disp=output only, we'd have to take a look at the whole set of showing the result partially (units-in, number-in, measurement-in; ditto -out; all units only; all numbers only, ...). Their resulting (future) option names should be systematic to be editor-friendly. Extra confusion (and bugging me on how to document this well) is that order=flip mixes "input" with "left-hand output". -DePiep (talk) 10:29, 18 October 2014 (UTC)

Without examples: I have the impression that "out" is used both meaning 1. "output" as in full template-result, and 2. "outcome" of the core calculation. -DePiep (talk) 10:32, 18 October 2014 (UTC)

Johnuniq, I am thinking about proposing new parameter(s). Are there any reasons beforehand that would make even a proposal useless ("won't happen at all")? If so I don't need to spend time on it. Of course, after I've written a proposal a talk outcome can be that it is not a good idea, but at least shouldn't be doa. -DePiep (talk) 09:51, 22 October 2014 (UTC)

Old templates in quarantine

• About Category:Old subpages of template:convert that are potentially used in mainspace

I have created this category, for old {convert/...} subpages that may appear in mainspace ('old' = in non-Lua code). That is, they have features that are not covered by Lua-{convert}. This is to keep an eye on these. It does not claim any intention with these templates (incorporate into module:convert, deprecate, TfD, don't touch, move outside {convert} space, ...).

These old templates should not enter the {convert} documentation - full stop. Their documentation is below standard anyway (missing, wrong, outdates, incomplete).

Recently old templates {{convert/spell}} and {{convert/numdisp}} were on this list, but these have been deprecated successfully. DePiep (talk) 11:57, 18 October 2014 (UTC)

Nomination for deletion of Template:Convertx

Template:Convertx has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Frietjes (talk) 17:56, 18 October 2014 (UTC)

Old templates cleanup

I have asked a botoperator here to produce this list: Template:Convert... pages used in mainspace. The numbers shown may be a bit outdated.

I suggest that if you have worked on a template, you add a note to this list. No Red tape needed.

Warning: The numbers seem to be incorrect. To be researched first, more will follow. Table is updated. -DePiep (talk) 22:38, 18 October 2014 (UTC)

The corrected table 15:32, 19 October 2014 (UTC):

Template	Mainspace pages transcluding
{{Convert}}	658760
{{Convert/CwtQtrLb_to_kg}}	35
{{Convert/E}}	2
{{Convert/TonCwt_to_t}}	286
{{Convert/numdisp}}	1
{{Convert/per}}	1
{{Convert/words}}	12
{{ConvertAbbrev}}	40086
{{ConvertAbbrev/ISO_3166-1/alpha-2}}	40086
{{ConvertAbbrev/ISO_3166-1/alpha-3}}	629
{{ConvertAbbrev/ISO_3166-2/US}}	39457
{{ConvertAbbrev/ISO_639-1}}	629
{{ConvertAbbrev/ISO_639-2}}	1
{{ConvertIPA-hu}}	372

List of Template:Convert.. (sub)templates used in mainspace - Incorrect numbers, outdated}

Template	Mainspace pages transcluding	Cleanup note
{{Convert}}	658728	OK, Lua
{{Convert/And1}}	1
{{Convert/CwtQtrLb_to_kg}}	36
{{Convert/Dual/Loff}}	1
{{Convert/Dual/LoffAoffDbSoff}}	1
{{Convert/Dual/rnd}}	1
{{Convert/E}}	2
{{Convert/LoffAoffDbSoff}}	3
{{Convert/LoffAoffDbSon}}	1
{{Convert/LoffAonDbSoff}}	3
{{Convert/LoffAonDbSoff2}}	2
{{Convert/LoffAonSoff}}	5
{{Convert/LoffAonSon}}	1
{{Convert/LonAonDbSoff}}	1
{{Convert/LonAonSoffAnd}}	1
{{Convert/LonAonSoffMinp}}	1
{{Convert/TonCwt_to_t}}	286
{{Convert/and/fra2}}	2
{{Convert/and/in}}	2
{{Convert/ft}}	4
{{Convert/hp}}	1
{{Convert/in}}	1
{{Convert/kW}}	1
{{Convert/kg}}	2
{{Convert/kg_stlb}}	1
{{Convert/km}}	2
{{Convert/km/h}}	2
{{Convert/lb}}	3
{{Convert/lengthcalc}}	1
{{Convert/m}}	4
{{Convert/mi}}	2
{{Convert/mi/h}}	1
{{Convert/mm}}	1
{{Convert/mph}}	2
{{Convert/multi2LonAonSoff}}	1
{{Convert/numdisp}}	3
{{Convert/numdisp/a}}	1
{{Convert/outAnd}}	1
{{Convert/outsep}}	3
{{Convert/pround}}	3
{{Convert/rand}}	1
{{Convert/round}}	4
{{Convert/rund}}	1
{{Convert/runtime}}	6
{{Convert/test/A}}	1
{{Convert/test/Aon}}	3
{{Convert/time}}	6
{{Convert/to}}	1
{{Convert/to/AoffSoff}}	1
{{Convert/to/AonSoff}}	1
{{Convert/words}}	23
{{Convert3}}	1
{{Convert30}}	1
{{Convert385}}	1
{{Convert709}}	1
{{ConvertAbbrev}}	40078
{{ConvertAbbrev/ISO_3166-1/alpha-2}}	40078
{{ConvertAbbrev/ISO_3166-1/alpha-3}}	629
{{ConvertAbbrev/ISO_3166-2/US}}	39449
{{ConvertAbbrev/ISO_639-1}}	629
{{ConvertAbbrev/ISO_639-2}}	1
{{ConvertIPA-hu}}	372
{{Convert_178.3}}	1
{{Convert_3800}}	1
{{Converty}}	1

• Cause 1: First pipe missing. Some redlinks in the lsit are cause by a forgotting first pipe (right after "{{convert". That way, instread of intended "{{Convert|3800|...}}" template "{{Convert 3800|...}}" is used (non existing of course). That made a red template link on the article page!: Template:Convert 3800. See [5], [6], [7]. Funny, we'd never see these red errors. Those are edited by now. -DePiep (talk) 23:09, 18 October 2014 (UTC)

• Cause 2: subtemplate won't be in module soon. {{Convert/runtime}} and {{Convert/time}} were moved out of {convert} space by Jimp.

See section below. I propose same for Template:Convert/TonCwt to t (edit | talk | history | links | watch | logs) and Template:Convert/CwtQtrLb_to_kg (edit | talk | history | links | watch | logs).They need a swap with their redirect. (Or did I miss a talk outcome here?). -DePiep (talk) 09:36, 19 October 2014 (UTC)

• {{Convert/TonCwt to t}} and {{Convert/CwtQtrLb_to_kg}} don't really belong here. I was thinking of merging them both into a new template separate from {{convert}}. Jimp 05:36, 22 October 2014 (UTC)

Indeed. This plan is mentioned discussed two sections below. -DePiep (talk) 09:30, 22 October 2014 (UTC)

Using {convert/per} and singulars

Template:Convert/per (edit | talk | history | links | watch | logs)

• The single use of {{convert/per}} was added recently. {{convert|1|PD/km2}} which gives "1 inhabitants per square kilometre (2.6 /sq mi)" was replaced by {{convert/per|1|person|km2|out=persons|abbr=on}} which gives "1 person/km² (2.6 persons/sq mi)". Unfortunately, neither are really adequate: "inhabitants" should be singular, there should be no space before the slash and "person/km²" and "2.6 persons/sq mi" should be spelt out. Jimp 05:51, 22 October 2014 (UTC)

No one has noticed the plural problem before:

• {{convert|1|PD/km2}} → 1 inhabitant per square kilometre (2.6/sq mi)

That needs fixes at the definitions: per unit area units. I can do that later (I have made a to do note) if no one beats me to it. Johnuniq (talk) 08:42, 22 October 2014 (UTC)

Convert/words

Template:Convert/words (edit | talk | history | links | watch | logs)

{{Convert/words}} has a few somewhat dubious outputs. Here are some examples from articles.

• {{convert/words|few|inches}} → few inches (half-dozen centimetres)
• {{convert/words|few hundred|meters|ft|-2}} → few hundred metres (1,000 ft)
• {{convert/words |several|feet}} → several feet (a few metres)
• {{convert/words|few|meters}} → few metres (half-dozen feet)
• {{convert/words|several|miles}} → several miles (dozen km)
• {{convert/words|several|m|adj=on}} → several-metre (15-30 feet)
• {{convert/words|one-third|mile}} → one-third mile (0.54 km)
• {{convert/words|several|square kilometers}} → several square kilometres (a few square miles)

Claiming, for example, that "few inches" and "half-dozen centimetres" or that "few hundred metres" and "1,000 ft" are equivalent strikes me as not really valid. It seems that there is a significant problem with false precision here. Does it even make sense to define how many fews there are in a several? Jimp 03:24, 19 October 2014 (UTC)

Indeed, they should be treated as words not as numbers. The acting article editor should take care that the resulting sentence makes sense. Hardly possible by template (a few cm = 1/3th-of-a-few inches lol). If {convert} does not cover the desired wording structure, the editor can hardcode it (maybe after a {subst:convert}). The {convert/words} template should be hardcoded in the articles, with corrections, and be deprecated for giving plain incorrect results. -DePiep (talk) 09:42, 19 October 2014 (UTC)

Move Convert/TonCwt and Convert/CwtQtrLb_to_kg out of {convert} space

Template:Convert/TonCwt to t (edit | talk | history | links | watch | logs) (286 transc's)

Template:Convert/CwtQtrLb_to_kg (edit | talk | history | links | watch | logs) (36 transc's)

I propose to move them to outside {convert}-space. I note that targets Template:TonCwt to t and Template:CwtQtrLb to kg now are their redirects, so this would need a swap.

These conversions have not been incorporated in module:convert. Whenever Lua-{convert} has these, they can be deprecated. Now, they are addressed directly from mainspace while being subtemplates, that is confusing. They are stand-alones. -DePiep (talk) 14:41, 19 October 2014 (UTC)

yes, good idea. Frietjes (talk) 17:15, 19 October 2014 (UTC)

To research this kind of issues, I've added the Search Archives box in the top of this page. For example, I discovered that in Cwt the two sub-talkpages contain discussions too. -DePiep (talk) 08:23, 20 October 2014 (UTC)