Template talk:Convert/Archive November 2014

A more specific linking option

We have three linking options, which is nice, but how about something more specific? Wouldn't it be nicer if we could ask for a specific to be linked? Take the following for example.

• {{convert|10|st|5|lb}} → "10 stone 5 pounds (66 kg; 145 lb)"
• {{convert|150|e9m|mi}} → "150 billion metres (93,000,000 mi)"

Something I had been working on was a more versatile linking parameter which could allow us to link a particular word. For example, lk=st would let us link stone without also linking the more mundane pounds and lk=billion would let us link billion without metres. I had got this working in a sandbox version but this was using the old template coding; I'd imaging, though, that it wouldn't be too hard with Lua. If this were done, we could replace {{miles-chains}} (used on only about a dozen pages) with {{convert}}. Jimp 02:22, 26 October 2014 (UTC)

For this, I was thinking about |link=exotic |lk=exotic (or so) that links specially marked units only. The marks would be in a the unit database (or in a separate, more simple listing data page). -DePiep (talk) 02:27, 26 October 2014 (UTC)

Yes, that seems useful, although it's likely that only a very small number of editors would ever know about or use the option. It may be good that anyone asking about linking could be shown how to do special cases. I'll see what's involved while I'm looking at removing the space before symbols that start with a slash (which looks do-able) as mentioned above (search for "/sq mi"). A quick workaround would be to define a special unit, say chain-lk, which has the same properties as chain but which has a link as part of the symbol and name. That would be a bit ugly because the input multiples would need to be updated to include the new unit.

DePiep's idea should be investigated, although people want a lot of flexibility and a predefined list might not suit.

I wonder why my wikilink which I tried to use did not work:

[[#Using {convert/per} and singulars|mentioned above]] → [[#Using {convert/per} and singulars|mentioned above]]

[[#Using and singulars|mentioned above]] → mentioned above (this links, but there is no such anchor)

Johnuniq (talk) 04:05, 26 October 2014 (UTC)

Another idea: allow each unit entered to have suffix -lk. This is to be detected (set a flag) and stripped early in the parsing. That unit then is linked. nmi-lk, hands-lk, st-lk. -DePiep (talk) 10:27, 26 October 2014 (UTC)

That's a nice idea, how about this, though? Rather than adding -lk add [[ and ]]. So that {{convert|10|[[st]]|5|lb}} would link stone and {{convert|150|[[e9]]m|mi}} would link billion. Jimp 09:41, 27 October 2014 (UTC)

I see the logic of using normal link syntax to show that a link is wanted, but that may confuse editors—they may think they are typing wikitext and start putting stuff like [[stone (unit)]] or [[st|stones]]. Johnuniq (talk) 10:48, 27 October 2014 (UTC)

True, how about single brackets (e.g. {convert|10|[st]|5|lb})? Jimp 10:56, 27 October 2014 (UTC)

Single brackets are not intuitive, but that should not prevent us from implying this principle in some form. -DePiep (talk) 12:06, 1 November 2014 (UTC)

SI notation uses unit symbols not unit names

The convert macro handles SI units in a non-standard and inconsistent manner.

If the SI-unit appears as the input (from) unit, then it is expanded to the unit name, and when it appears as the output (to) unit, then it is expanded to the unit symbol, e.g. {{convert|1|m3|m3}} currently expands to '1 cubic metre (1.0 m³)'.

This is inconsistent and non-standard. SI-notation uses the unit symbol (which is read out aload using the unit name, but that is another story).

Since the English wikipedia can be said to be relevant especially for US wikipedians and readers I offer as a source for the above the SI-brochure published by NIST, NIST Special Publication 811, section 7.6 'Symbols for numbers and units versus spelled-out names of numbers and units'.

Wikipedia describes and links to it here: International_System_of_Units#SI_Brochure_and_conversion_factors.

Please modify the convert macro to always expand a SI-unit using its symbol. Thank you. Lklundin (talk) 21:28, 30 October 2014 (UTC)

Convert has always followed the principle that, by default, the main unit should be given by name to improve clarity for general readers, while the converted output should be given as a symbol for brevity, on the basis that someone who needs the conversion will know the symbol for the unit they are familiar with. Therefore, the template defaults to "abbreviate the output but not the input" which is |abbr=out in the options, and is the default setting. Examples:

• {{convert|12|m|ft}} → 12 metres (39 ft)
• {{convert|12|m|ft|abbr=out}} → 12 metres (39 ft) (default)
• {{convert|12|m|ft|abbr=in}} → 12 m (39 feet)
• {{convert|12|m|ft|abbr=on}} → 12 m (39 ft)
• {{convert|12|m|ft|abbr=off}} → 12 metres (39 feet)
• {{convert|12|m|ft|abbr=off|sp=us}} → 12 meters (39 feet)

It might be argued that general readers should not need "metre" (or "meter") spelled out, but that is not true for lots of other units for even simple measurements like ha (hectare) or kW (kilowatt). Therefore, convert defaults to giving the name of the input unit in full, including its SI prefix, if present. If that is not wanted, use |abbr=on:

• {{convert|1|m3|m3|abbr=on}} → 1 m³ (1.0 m³)

Johnuniq (talk) 22:08, 30 October 2014 (UTC)

(edit conflict) This is a brochure "SI Brochure: The International System of Units (SI) [8th edition, 2006; updated in 2014"], but I do not see an "811" id nor any section 7.x. -DePiep (talk) 22:13, 30 October 2014 (UTC)

From that brochure, chapter 5 section, "unit symbols": "one must neither use the plural [of symbols; DP] nor mix unit symbols and unit names within one expression, since names are not mathematical entities."

I don't think the two output results are one single expression. The bracketed one is another expression, and so may be written in units (but each of then individually it is: don't use units & names together). It does forbid to write like "100 m/hour": using both unit and name in one expression. -DePiep (talk) 22:18, 30 October 2014 (UTC)

'Convert has always followed the principle that, by default, the main unit should be given by name to improve clarity for general readers'. Yes, that is the problem, this principle goes against the recommendation of the SI-standard. Let me quote from the above-mentioned section 7.6 of the SI-brochure from NIST: 'to promote the comprehension of quantitative information in general and its broad understandability in particular, values of quantities should be expressed in acceptable units using the Arabic symbols for numbers, that is, the Arabic numerals, not the spelled-out names of the Arabic numerals; and the symbols for the units, not the spelled-out names of the units'. The use of the SI-notation has to be done in accordance with the SI-standard, so the SI-convention for notation takes precedence over Wikipedia's convert-template convention. It is not enough to point to a non-default setting that can be modified, this will not ensure a standardized SI-notation in wikipedia. We really have to change how the default convert-template displays a quantity in SI. Thank you. Lklundin (talk) 08:58, 31 October 2014 (UTC)

PS. The normative standard I refer to above is this one. Lklundin (talk) 09:03, 31 October 2014 (UTC)

References

I mentioned the history to show that a fair bit of inertia would have to be overcome—there are over 700,000 converts in articles. Also, the inertia is based on a good principle (use full name of units to avoid confusion for general reader; can use symbols if repeated). If you want a change, I think the first step would be to check WP:UNIT because it starts with "200 kilometres (120 mi)" as an example, and mentions the principle I outlined at a couple of places. Ultimately, convert follows the manual of style, so MOS would need to change first. Johnuniq (talk) 10:11, 31 October 2014 (UTC)

I agree, I am pointing out the need for an extensive change - which is therefore important. Thank you for your guidance. I will prepare and open a discussion at WP:UNIT. Lklundin (talk) 17:35, 31 October 2014 (UTC)

NIST is a U.S. institute. The publication mentioned "811" is not called "brochure". OTOH, the BIPM is the intergovernmental organization. They publish the ["SI-brochure" (2014). Of course both guidelines make sense as a standard, but I am not convinced that the US standard (from which Lklundin quoted & concluded an error in MOS) should be the rule. -DePiep (talk) 18:53, 31 October 2014 (UTC)

• This discussion is continued at Wikipedia_talk:Manual_of_Style/Dates_and_numbers#Need_to_observe_SI-standard_when_using_SI-notation. -DePiep (talk) 13:24, 1 November 2014 (UTC)

@Rhialto: I moved your comment on the currency sign from here to the previous section because I think that's where you intended it. Johnuniq (talk) 05:04, 3 November 2014 (UTC)

Convert/words

Resolved

 – Is deleted. -DePiep (talk) 07:29, 3 November 2014 (UTC)

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)

I've put it up for deletion. Jimp 04:20, 24 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) {{aye}} (corrected: this is not following MOSNUM. -DePiep (talk) 05:15, 6 November 2014 (UTC))

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}} -
• {convert/old |2|xx|6|ft|m}} -

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)

Formed into a proposal, see this. -DePiep (talk) 18:05, 3 November 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 by 2 metres (1,000 mm × 2,000 mm) -- (to compare; current live version)
• {{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|x|2|m|mm}} → 1 by 2 metres (1,000 mm × 2,000 mm) -- (to compare; current live version)
• {{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.

Asterisk (*)

The asterisk option |*| 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)

I withdraw the idea to allow unspaced × sign to be used: "2.6×106 z" (currently through option |*| in {{convert}}). It is not MOS, and not following SI. It also allows awkward punctuated texts like "2.6 m×106 m". The option should be deprecated. -DePiep (talk) 11:43, 1 November 2014 (UTC)

Formed into a proposal, see this. -DePiep (talk) 18:06, 3 November 2014 (UTC)

Deprecation of "/" (slash) join

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)

Johnuniq. I think this deprecation can be pushed into code (make |disp=slash to show "_or_"). IMO it does not require any article checking (instances will change to "_or_" without breaking anything; these are only post-November 2013 instances anyway). Maybe Jimp can check & confirm this thread/me. -DePiep (talk) 11:49, 1 November 2014 (UTC)

I'm unsure whether convert should enforce a rule that slashes are not used but am happy to try it and see if there are any complaints in the coming weeks. It's a very simple change and I have made a to-do note for the next release. I was hoping to recover from some distractions soon and do a couple of minor things that have been noted recently, then present it all for a release in about a week. Johnuniq (talk) 09:54, 2 November 2014 (UTC)

"whether convert should enforce a rule" -- I thought that rule was the outcome/consensus of this thread: replace slash with "or" (deprecate slash uses). Code change would implement that outcome.

• {{convert|1|km|mi|disp=slash}} → 1 kilometre (0.62 mi)
• {{convert/sandbox|1|km|mi|disp=slash}} → 1 kilometre (0.62 mi) -- " or " expected

-DePiep (talk) 10:41, 2 November 2014 (UTC)

From the health department: I am asking these questions without any consideration re your agenda and priorities. Best is that you decide for yourself, harshly, what to spend time on. If you take a short or long wikibreak from convert: good. Or only do edits that are fun: good. We'll all survive. But I cannot enact that for you. (I am just posting thoughts and questions; there is no obligation. This is how we do wiki). -DePiep (talk) 10:41, 2 November 2014 (UTC)

Things are ok, thanks. I have done what is needed so that the next upload will include the change such that disp=slash will be equivalent to disp=or. Johnuniq (talk) 11:05, 2 November 2014 (UTC)

The {{convert/sandbox}} three rows up shows old effect. But maybe it's a different route. Fine with me. -DePiep (talk) 17:40, 2 November 2014 (UTC)

The sandbox convert now makes disp=slash equivalent to disp=or. Johnuniq (talk) 04:47, 3 November 2014 (UTC)

Table sorting

Currently, we can produce output in table form by using |disp=table and |disp=tablecen. It produces numbers only, with table pipes and styles added. Additional setting of |sortable=on adds a hidden sorting key. For example:

* {{convert|1|km|mi|sortable=in|disp=table}} →
align="right"|<span style="display:none">7000100000000000000</span>1
|align="right"|0.62

* {{convert|1|km|mi|sortable=in|disp=tablecen}} →
align="center"|<span style="display:none">7000100000000000000</span>1
|align="center"|0.62

• Problem: the sort key is only added to the first column. The second column has no sortkey, and in general will not sort correctly (the |0.62 column in the demo). Solution: add a sortkey to the second column too (derived from that number).

• Detail 1: there also exist options |sortable=in, |sortable=out. These are meaningful outside of |disp=table/tablecen (i.e., all {convert} output is in one column only). I see no need to apply this subtlety to sortable table columns. In other words: once |disp=table/tablecen and any |sortable=on/in/out is set, all numeric columns should get their own sorting key.

• Detail 2: the span tag now sets style="display:none". But for example {{sort}} uses tags this way: <span class="sortkey">...</span><span class="sorttext">...</span>. Should {convert} use these classes? -DePiep (talk) 15:21, 1 November 2014 (UTC)

Yes, this needs fixing, and I suppose the css bloat from {{sort}} should be used. There are two issues: the output syntax, and what text to use for the sortkey. Re the syntax, following is from Special:ExpandTemplates:

{{sort|1234|hello}} → <span class="sortkey">1234&#32;!</span><span class="sorttext">hello</span>
{{sort|1234|hello}} → <span style="display:none;" class="sortkey">1234&#32;!</span><span class="sorttext">hello</span>

Updated above by adding the second line to show what the edited template does now. First line = what it did yesterday. Johnuniq (talk) 09:35, 3 November 2014 (UTC)

What is " !"? See talk1 and talk2. I haven't had time to digest it—the space enables wrapping? HTML Tidy damages a simple space? Does convert need all that?

The second issue is the text for sortkey. I suspect convert can cheat and use the same sortkey for both the input and the output. Johnuniq (talk) 11:01, 2 November 2014 (UTC)

1. The missing sortkey in the second column is an error wrt user expectation. That should be corrected asap. Code can be a dumb copy of the 1st column code, even using style="display:none". Because that solves the error! (If it is easy, it would be good to give that column its own sort number, because editors may want to manipulate the convert output number [e.g., setting a rounding effect], so that 2nd number may be different for sorting purposes).

2. The sortkey class needs more time & thinking indeed. It has changed much last years, a 2010 discussion is not useful. There are many variants in Category:Sorting templates, and for example {{Hidden sort key}} has a more simple span tag: <span class="sortkey">{{{1}}}</span>. This subtility can wait for a later code change. -DePiep (talk) 09:31, 3 November 2014 (UTC)

As noted below, I have implemented the fix in the sandbox. Thanks for pointing out the problem. Johnuniq (talk) 10:27, 5 November 2014 (UTC)

Thank you. Writing good reports helps me thinking better :-) . -DePiep (talk) 11:22, 5 November 2014 (UTC)

Sort key syntax

@Redrose64: You made a confident edit at {{sort}}. Can you help to explain what wikitext convert should output when using a hidden sort key? Here are some examples of what {{convert/sandbox}} and {{sort}} currently output (convert/sandbox uses some new code which inserts the sortkey in each table cell, if any—the current convert only outputs one sort key in each of the following).

{{convert|2|ft|6|in|cm|abbr=on|sortable=on}} →
<span style="display:none">7001300000000000000</span>2 ft 6 in (76 cm)

{{convert|2|ft|6|in|cm|abbr=on|sortable=on|disp=table}} →
 align="right"|<span style="display:none">7001300000000000000</span>2 ft 6 in
|align="right"|<span style="display:none">7001300000000000000</span>76 cm

{{convert|76.2|cm|ftin in|abbr=on|sortable=out|disp=table}} →
 align="right"|<span style="display:none">7001300000000000000</span>76.2 cm
|align="right"|<span style="display:none">7001300000000000000</span>2 ft 6.0 in
|align="right"|<span style="display:none">7001300000000000000</span>30.0 in

{{sort|7001300000000000000|76 cm}} →
<span style="display:none;" class="sortkey">7001300000000000000&#32;!</span><span class="sorttext">76 cm</span>

I would be pretty reluctant to add the <span class="sorttext">...</span> which {sort} puts around the displayed text, but it would be easy to change the wikitext around the sort key. Doing nothing would be my preference, but if there is a good reason that convert should be outputting something else, I'll give it a go. I have no idea how  ! helps. Johnuniq (talk) 10:27, 5 November 2014 (UTC)

The same sort key in each column

This could be a problem if not all rows use the template. If it turns out to be impractical to base each sort key on the number in that cell, then we should at least make a note of this. Also we would have to make sure we're using the correct key when we have order=flip. Jimp 13:08, 13 November 2014 (UTC)

I have confirmed that using order=flip with convert/sandbox in the above examples gives exactly the same sort key. When using sortable=on, the module uses the first input value to generate the sort key, regardless of flip. It uses the first output value when sortable=out is used. The word "first" is used in case there is a range of inputs, like |12|to|34|. I guess that should be documented. Johnuniq (talk) 01:25, 14 November 2014 (UTC)

Ton of refrigeration

What? No conversion for Ton of refrigeration? I wanted to use this in Burj Khalifa, which cites a source that gives the capacity of the cooling plant in this obscure unit. Kendall-K1 (talk) 19:42, 13 November 2014 (UTC)

Would that be helpful? I suspect that the article text would have to spell out what it meant, in which case a conversion would not be needed. The source you gave says "Cooling the glass tower in the desert heat requires the equivalent of 10,000 tons of melting ice; the air-conditioning system installed by the Voltas partnership has a capacity of 13,000 tons." That was written by someone unaware of what power is because they should have said something like "a capacity of 13,000 tons of melting ice per day". At any rate, before a unit can be defined, we would need to agree on its symbol (when abbreviation is on) and name (when abbreviation is off), and whether there is a difference for US and imperial.

Air conditioning#Energy transfer says "A ton of refrigeration is approximately equal to the cooling power of one short ton (2000 pounds or 907 kilograms) of ice melting in a 24-hour period. The value is defined as 12,000 BTU per hour, or 3517 watts." Note the defined—we would need to know if that is correct (it seems likely), and is sort-of confirmed at http://physics.nist.gov/Pubs/SP811/appenB9.html. However, Ton of refrigeration says it is "approximately equivalent to 12,000 BTU/h". Conversion of units#Power or heat flow rate claims there is a "ton of refrigeration (imperial)" and a "ton of refrigeration (IT)".

And, we would need a unit code (the name of the unit typed into the convert template). Johnuniq (talk) 01:28, 14 November 2014 (UTC)

I'm not sure how helpful it would be. I've been editing WP for years and this is the first time I've needed it. I could come up with many reliable sources for the definition, which is 1 ton of cooling = 12,000 Btu/h. The name is "ton of cooling" and the only symbol I know of is "ton" which is of course ambiguous. I very much doubt there is any such thing as an Imperial ton of cooling, I'd want to see a source for that. It's a ridiculous unit, but apparently still commonly used in the US. Kendall-K1 (talk) 03:15, 14 November 2014 (UTC)

Direct conversion of sections (land area)

Dominion Land Survey, Qu'Appelle, Saskatchewan#Settlement colonies, Section (United States land surveying) {{Convert|4+3/4|section|sqmi km2}} 4+3⁄4 section. Peter Horn User talk 18:50, 12 November 2014 (UTC)

Is defined as one square mile. So we can write:

{{frac|4|3|4}} sections ({{convert|4+3/4|sqmi|km2|disp=comma}}) → 4+3⁄4 sections (4+3⁄4 square miles, 12 km²). -DePiep (talk) 22:09, 12 November 2014 (UTC)

I had already resorted to that. Peter Horn User talk 16:14, 14 November 2014 (UTC)

spell=us

Brewing#Brewing industry, {{convert|133|e9L|USgal impgal|abbr=none|spell=us}} 133 billion liters (3.5×10¹⁰ U.S. gallons; 2.9×10¹⁰ imperial gallons) "spell=us" does not yet work here. Peter Horn User talk 16:25, 14 November 2014 (UTC)

@Peter Horn:, see Help:Convert, you want |sp=us not |spell=us: 133 billion liters (3.5×10¹⁰ U.S. gallons; 2.9×10¹⁰ imperial gallons) Frietjes (talk) 19:22, 14 November 2014 (UTC)

No about the "billion" then? BTW, isn't beer given in hL (hectoliters) usually? -DePiep (talk) 19:38, 14 November 2014 (UTC)

The page Brewing#Brewing industry gives it in liters, perhaps we could correct that. And thanks for the reminder "sp=us". I'm sleep deprived. Peter Horn User talk 19:57, 14 November 2014 (UTC)

So {{convert|133|e9L|USgal impgal|abbr=none|sp=us}} 133 billion liters (3.5×10¹⁰ U.S. gallons; 2.9×10¹⁰ imperial gallons). Change that to {{convert|1.33|e11hL|USgal impgal|abbr=none|sp=us}} 1.33 e11hL or {{convert|1.33|e11hl|USgal impgal|abbr=none|sp=us}} 1.33 e11hl. Fun and games for all, neither hl nor hL appear to be supported yet. Peter Horn User talk 20:16, 14 November 2014 (UTC)

Don't let me wake you. But engineering notation is by 3: e3L, e6L, e9L etc. So e11 won't work. Also, best is to keep the unit the source says. -DePiep (talk) 20:23, 14 November 2014 (UTC)

I believe large quantities of beer in the US are measured in barrels, which is 31 gallons. Kendall-K1 (talk) 23:50, 14 November 2014 (UTC)

The source quoted gives it in terms of liters, not in terms of barrels. Peter Horn User talk 02:57, 15 November 2014 (UTC)

Troy pound

{{resolved}}

Over at talk:MOSNUM#Troy pound, I have noted a hiccup wrt "troy" and "troy pound". I conclude that the MOS is in error, and that {{convert}} is correct (and so beaching the (bad) MOS, today). Please discuss there. -DePiep (talk) 13:57, 1 November 2014 (UTC)

Solved already. -DePiep (talk) 15:29, 1 November 2014 (UTC)

• While we are in troy:

{{convert|1|ozt|g|abbr=~}} → 1 troy ounce [ozt] (31 g)

{{convert|1|troy ounce|g|abbr=~}} → 1 troy ounce

The pound:

{{convert|1|troy pound|g|abbr=~}} → 1 troy pound [troy pound] (370 g)

{{convert|1|lbt|g|abbr=~}} → 1 troy pound [troy pound] (370 g)

Maybe unit name troy ounce can be added. troy ounce is quite common. -DePiep (talk) 19:37, 3 November 2014 (UTC)

I formally request that troy ounce be added and as a recognised name. ozt is not used in the output, and is not the formal unit symbol. In other words, "troy ounce" is the (more) common name. I did not edit any code page (/extra nor /sandbox). -DePiep (talk) 12:28, 13 November 2014 (UTC) ping @Johnuniq: -DePiep (talk) 12:29, 13 November 2014 (UTC)

Are you saying that there should be an alias: troy ounce = ozt? There are probably lots of units that could be made more consistent, but what is the point if they are not used? If adding one alias would satisfy an itch, fine, let's do it. But let's not add many more that are unused. As we discussed recently, the "add a ping" edit did not notify me...strange. Johnuniq (talk) 01:09, 14 November 2014 (UTC)

Yes that alias isd what I meant. POer MOSNUM, it's always spelled out. Also, "troy ounce" is the known id; ozt is not -- it's a code, not an official unit. Having to use 'ozt' could require a search in the units list (which, inversely, might explain why it isn't used).

Having said this, I'll leave it to you. Here is a fresh ping: Johnuniq (by {{U}} template this time, not <small> and directly with my signing). -DePiep (talk) 20:40, 14 November 2014 (UTC)

Yes, I got that ping thanks. I'll look at the rest of this page another time. Johnuniq (talk) 03:48, 15 November 2014 (UTC)

Module version 6

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

• Module:Convert • Module:Convert/sandbox • same content
• Module:Convert/data • Module:Convert/data/sandbox • same content
• Module:Convert/text • Module:Convert/text/sandbox • same content
• Module:Convert/extra • Module:Convert/extra/sandbox • different (diff)
• Module:Convert/wikidata • Module:Convert/wikidata/sandbox • same content
• Module:Convert/wikidata/data • Module:Convert/wikidata/data/sandbox • same content

The changes are:

• Options disp=slash, disp=s, disp=/ are now equivalent to disp=or per discussion above.
• Omit separator (space or non-breaking space) before a unit which starts with a slash per discussion above ('1/ha' not '1 /ha').
• The tilde has been omitted from the symbol for unit ~/acre because the tilde meant that the symbol is never used; see use name (I found this while investigating the previous issue).
• Conversions like {{convert|1|$/ha|$/acre}} can use an alternative currency symbol such as the euro ({{convert|1|$/ha|$/acre|$=€}}) per discussion above.
• Conversions for a sortable table (disp=table or disp=tablecen with sortable=on or sortable=out) will output a hidden sort key before each table cell per discussion above. The same key is used for each cell as that will work in almost all cases and is fastest. To do: Think about the syntax and whether to make convert's output similar to that of {{sort}}.
• New option comma=off added to replace traditional abbr=comma and adj=nocomma per discussion.

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

Convert	Version 5 output	Version 6 output
{{convert|55|mi|km|disp=slash}}	55 miles / 89 kilometres	55 miles or 89 kilometres
{{convert|28|C|F|disp=s}}	28 °C / 82 °F	28 °C or 82 °F
{{convert|564|mph|km/h kn|disp=/|abbr=on}}	564 mph/908 km/h; 490 kn	564 mph or 908 km/h or 490 kn
{{convert|1|/ha}}	1 per hectare (0.40 per acre)	1 per hectare (0.40/acre)
{{convert|1|/ha|abbr=on}}	1 /ha (0.40 per acre)	1/ha (0.40/acre)
{{convert|1|/ha|abbr=off}}	1 per hectare (0.40 per acre)	1 per hectare (0.40 per acre)
{{convert|1|PD/ha}}	1 inhabitant per hectare (0.40 inhabitant per acre)	1 inhabitant per hectare (0.40/acre)
{{convert|1|PD/ha|abbr=on}}	1 /ha (0.40 inhabitant per acre)	1/ha (0.40/acre)
{{convert|1|PD/ha|abbr=off}}	1 inhabitant per hectare (0.40 inhabitants per acre)	1 inhabitant per hectare (0.40 inhabitants per acre)
{{convert|1|/l}}	1 per litre (3.8 /gal)	1 per litre (3.8/gal)
{{convert|1|/l|abbr=on}}	1 /l (3.8 /gal)	1/l (3.8/gal)
{{convert|1|/l|abbr=off}}	1 per litre (3.8 per gallon)	1 per litre (3.8 per gallon)
{{convert|1|/acre|lk=on}}	1 per acre (2.5 /ha)	1 per acre (2.5/ha)
{{convert|1|/acre|abbr=on}}	1 per acre (2.5 /ha)	1/acre (2.5/ha)
{{convert|1|/acre|abbr=off}}	1 per acre (2.5 per hectare)	1 per acre (2.5 per hectare)
{{convert|1|/ha|lk=on}}	1 per hectare (0.40 per acre)	1 per hectare (0.40/acre)
{{convert|1|$/ha|$/acre}}	$1 per hectare ($0.40/acre)	$1 per hectare ($0.40/acre)
{{convert|1|$/ha|$/acre|$=US$}}	$1 per hectare ($0.40/acre)	US$1 per hectare (US$0.40/acre)
{{convert|1|$/ha|$/acre|$=€}}	$1 per hectare ($0.40/acre)	€1 per hectare (€0.40/acre)
{{convert|123456789|m|km|comma=off}}	123,456,789 metres (123,456.789 km)	123456789 metres (123456.789 km)

The following is from Help:Convert#Sortable table but uses convert/sandbox. The new version correctly sorts the "ft in" column, whereas the previous version did not have a sort key, so used an alpha sort instead of a numeric sort.

	Length		Weight
	metres	ft in	kg	lb
Lorem ipsum	28.1	92 ft 2 in	47.5	105
Dolor sit amet	9.9	32 ft 6 in	74.1	163
Consectetur	38.2	125 ft 4 in	31.5	69
Adipisicing elit	18.7	61 ft 4 in	52.7	116

Are there any other minor issues that might be attended to for this release? Johnuniq (talk) 07:02, 3 November 2014 (UTC)

• Updated: Sortable table fix has been added. Johnuniq (talk) 23:10, 4 November 2014 (UTC)
• Updated: New option comma=off has been added. Johnuniq (talk) 05:13, 10 November 2014 (UTC)

I'm not sure if this is minor enough, but these three deprecations deserve encoding. -DePiep (talk) 15:53, 5 November 2014 (UTC)

Module version history

• Version 1 December 2013
• Version 2 January 2014
• Version 3 April 2014
• Version 4 July 2014
• Version 5 September 2014
• Version 6 November 2014

The module has been updated to the new version and all instances where convert/sandbox were used in articles (only in Paris) have been updated to plain convert. I've added the above list for future historians, although the last link won't work until this section is archived. Johnuniq (talk) 00:15, 18 November 2014 (UTC)

Add euro as a currency symbol

A question was raised at my talk, but I'll answer it here so other people see the discussion. The issue is that some units allow conversion between "costs" as in these examples:

• {{convert|12.3|$/acre}} → $12.3 per acre ($30/ha) cost $ per unit area
• {{convert|12.3|$/mi}} → $12.3 per mile ($7.6/km) cost $ per unit length
• {{convert|12.3|$/kg}} → $12.3 per kilogram ($5.6/lb) cost $ per unit mass
• {{convert|12.3|$/m3}} → $12.3 per cubic metre ($0.35/cu ft) cost $ per unit volume
• {{convert|12.3|£/acre}} → £12.3 per acre (£30/ha) cost £ per unit area

Note that the currency symbol is placed in the correct position for currency. That uses a trick built into the module, and the trick requires that the module be told which symbols are currency. The request is for some new units using euro (€). That can be done, but not until after the module is updated to define the euro as a currency symbol. As a matter of interest, that is at the end of Module:Convert/text where it defines a currency table.

Sorry, but euros will have to wait for a couple of weeks. Meanwhile, ThePromenader might like to post here with what units are proposed. Please don't think of all possible places where euro might be used—there are far too many unused units already, and I think we should only add units which are going to be used. Johnuniq (talk) 11:07, 26 October 2014 (UTC)

(edit conflict) Thanks so much for forwarding this, Johnuniq.

Come to think of it, wouldn't it be helpful to make a unique (addition to the) script that would convert all currencies? All that's changing is the currency symbol shown (since the x to x calculation stays the same), and it would seem unseemly to repeat the same script for every currency symbol. Just my two cents, cheers ; ) THEPROMENADER ✎ ✓ 12:06, 26 October 2014 (UTC)

How about not adding any new units? Instead just use the existing ones with a parameter to substitute any symbol for the dollar sign.

• {{convert|12.3|$/acre|$=£}} → £12.3 per acre (£30/ha)
• {{convert|12.3|$/mi|$=€}} → €12.3 per mile (€7.6/km)

Jimp 12:05, 26 October 2014 (UTC)

Great minds... ; ) THEPROMENADER ✎ ✓ 12:07, 26 October 2014 (UTC)

(son of edit conflict) Wait, is that a suggestion, or does it exist already? THEPROMENADER ✎ ✓ 12:16, 26 October 2014 (UTC)

What are the chances? Jimp 12:13, 26 October 2014 (UTC)

We tripped over the same silly question? But I tripped over my own ; ) THEPROMENADER ✎ ✓ 12:16, 26 October 2014 (UTC)

Doh. I just tested for fun. Jimp's idea would be the simplest across-the-board solution. THEPROMENADER ✎ ✓ 19:07, 26 October 2014 (UTC)

(edit conflict)

• The general currency sign in typography is U+00A4 ¤ CURRENCY SIGN. That is, this placeholder is to be replaced by any real currency symbol. However, it is not on keyboards so better not use it as a parameter name. Using |$=£ confused me when I just saw it first time here (and even surrests their exchange rate is 1).
• I note that in the examples, the currency always has value=1 (while it is the denominator, like acre → ha, that is converted by both number & unit). Can the code be more general, and allow |$=<any input> to be reproduced untouched: 1 week/acre (2.5 week/ha). IIRC, this was pointed out I think a month ago here by Wikid77. Name suggestions: |nom=, |denom=. -DePiep (talk) 19:12, 26 October 2014 (UTC)

I found Jimp's idea to not add new units very appealing, and as it was simple I have put a new version in the sandbox.

• {{convert/sandbox|12.3|$/acre}} → $12.3 per acre ($30/ha)
• {{convert/sandbox|12.3|$/m3}} → $12.3 per cubic metre ($0.35/cu ft)
• {{convert/sandbox|12.3|$/acre|$=€}} → €12.3 per acre (€30/ha)
• {{convert/sandbox|12.3|$/m3|$=€}} → €12.3 per cubic metre (€0.35/cu ft)
• {{convert/sandbox|12.3|$/acre|$=euro}} → €12.3 per acre (€30/ha)
• {{convert/sandbox|12.3|$/m3|$=euro|sp=us}} → €12.3 per cubic meter (€0.35/cu ft)
• {{convert/sandbox|12.3|$/acre|$=₫}} → ₫12.3 per acre ()
• {{convert/sandbox|12.3|$/acre|$=¥}} → ¥12.3 per acre (¥30/ha)
• {{convert/sandbox|12.3|£/acre|$=€}} → €12.3 per acre (€30/ha)
• {{convert/sandbox|12.3|£/acre|$=Test }} → Test 12.3 per acre ()
• {{convert/sandbox|12.3|$/acre|$=[[Vietnamese dong|₫]]}} → ₫12.3 per acre ()

The last three examples show that the currency symbol is replaced with whatever text is specified. The above also shows that "$=euro" is accepted for the euro symbol. That is built-in and is the only name accepted. If a link is wanted, it has to be entered manually and will be linked in the input and the output. I added some more tests showing the available "cost" units; they can be seen in the bottom half at Template talk:Convert/testcases/sandbox4. Johnuniq (talk) 06:23, 27 October 2014 (UTC)

(waving pom-poms) Great, thanks! I'll try it out today in a page I'm translating (actually the reason I asked about this). Thanks! THEPROMENADER ✎ ✓ 08:21, 27 October 2014 (UTC)

To explain this to myself, as a documentation:

A. The units $/acre and £/acre are already available. Live version:

• {{convert|12.3|$/acre}} → $12.3 per acre ($30/ha)
• {{convert|12.3|£/acre}} → £12.3 per acre (£30/ha)
• {{convert|12.3|£/nmi}} → £12.3 per nautical mile ()

The list of units is limited (todo: find & document this list. $/nmi is not in).

B. Now "the replace with another currency" option is added (in the sandbox for now).

1. The |$= parameter value (sign) entered replaces the $-sign without calculation effects.

2. The parameter is placed as a unspaced prefix to the numbers:

• {{convert/sandbox|12.3|$/acre|$=''ABCD''}} → ABCD12.3 per acre ()
• {{convert/sandbox|12.3|$/nmi|$=£}} → £12.3 per nautical mile () -- unchanged, and erroneous number!

C. The nominator (parameter |$=...) is a unit with scale 1. It is not related to any exchange rate. -DePiep (talk) 09:46, 27 October 2014 (UTC)

-DePiep (talk) 09:46, 27 October 2014 (UTC)

They are documented at the "cost" units, starting here. Each has to be defined as a "per" unit (see "Per units" on that page), and each has to have a known currency symbol ($ or £) as the numerator. As you say, there are no exchange rates involved—the calculation is just saying that if something costs a certain number of dollars per acre, then it will cost some other number of dollars per hectare, and in fact the dollars could be any currency. Johnuniq (talk) 10:44, 27 October 2014 (UTC)

Yes, it's only logical to use the article-specific currency, and Wikipedia is not an exchange-rate tracking entity as far as I know ; ) THEPROMENADER ✎ ✓ 15:45, 27 October 2014 (UTC)

You might want to consider the {{currency/Type}} template (a helper for the {{currency}} template). It takes the ISO 4217 currency code (eg USD, GBP, JPY) and generates currency symbols and links to the correspond article. E.g. {{currency/Type|JPY}} produces ¥  Stepho  talk  22:35, 27 October 2014 (UTC)

The problem with {{currency/Type}} is that it links everything. This could be fixed, of course, but how does a Lua module use a template not written in Lua? Jimp 08:17, 28 October 2014 (UTC)

Levels of complication: of course, the change already in the sandbox can go live right now. Making it generic for any curency-id (the list with AUD =Australian dollar is an ISO one) could be considered later (but why? What is added? Better do not imo. Adding a specific link or any text as the demo shows is nice!). Even more later, with a structural change in the code I think, the "any input goes" can be extended into the unit name (nominator, denominator, prefix, suffix, format?, all scale-factor 1 by definition). Then, in 2025, we could think of adding currency conversion to it. -DePiep (talk) 09:10, 28 October 2014 (UTC)

I know wiki doesn't do this (currency conversion) but the idea -is- an awesome one. But remember that there are two types of currency conversion: a template shouldn't affect (or concern) historical currency conversion (value at time of event, values contributed (with reference to exchange rates at the time); an automatic conversion would only concern more general "the cost of a beer in x" topics. THEPROMENADER ✎ ✓ 09:28, 28 October 2014 (UTC)

But I digress. THEPROMENADER ✎ ✓ 09:30, 28 October 2014 (UTC)

Yes (let me digress too). The template now does $/acre into $/ha (good); in sandbox is €/acre into €/ha (good). In other words, the sign itself has value "1" always. But we do not expect €/acre into $/acre (one can not enter two signs even; btw and no one asked for this!). -DePiep (talk) 11:21, 28 October 2014 (UTC)

(waving) Hello, just a question - is this active yet? Thanks to you-all for all your help and input, by the way. THEPROMENADER ✎ ✓ 21:37, 1 November 2014 (UTC)

No, it is in the sandbox for testing. Usually some more edits are added before making the change into live. -DePiep (talk) 22:14, 1 November 2014 (UTC)

@ThePromenader: Please use the sandbox template for now. We can replace it with the main template when the change is live in a week or two. What-links-here can list articles using convert/sandbox (none at the moment). @DePiep: I guess you made that useful comment just above—it needs a signature. Johnuniq (talk) 10:04, 2 November 2014 (UTC)

Rather than using the "$" or the "€" sign to indicate that a sign is a currency symbol, why not use the actual character that is designated as the currency symbol - "¤"? Rhialto (talk) 06:56, 2 November 2014 (UTC)

The signs $ or € are entered as the actual currency symbol, the one that should be shown (we don't want "¤/acre" visible on the page). Maybe you meant to say that "¤/acre" is the generic data format (the unit in the data list), and the editor should provide the sign as desired |¤=$. That is formally correct too, but 1. the sign "¤" is not on a keyboard ("$" is easier to type) in |$=€, and 2. This way "$" is the default sign, which is no problem at all. I think this is easy to grasp and enter for an editor:

• {{convert/sandbox|10|$/acre|$/ha}} → $10 per acre ($25/ha) --default
• {{convert/sandbox|10|$/acre|$/ha|$=€}} → €10 per acre (€25/ha) --parameter is "$" -DePiep (talk) 10:23, 2 November 2014 (UTC) (signed late)

You're right in that the currency sign ¤ is not on the keyboard. However, wikipedia's default editbox interface includes a tool for entering non-keyboard characters, such as ¤ and even ¢ or € (none of which are on my keyboard). I was not suggesting that the currency symbol appear on the rendered page, only that it be used in the wiki mark-up code. Saying £=$ in the code is non-intuitive and liable to put off new editors from using the template, as well as cause people to "correct" it through not realising that such apparently counter-factual code is actually by design. What I am saying is rather than build counter-factuals into the system, use the tools that already exist to avoid counter-factuals from being built into the code. Rhialto (talk) 10:23, 2 November 2014 (UTC)

It is true that |$=€ is strange syntax, but the alternative would be something like |currency symbol=€ because not many editors would find ¤ helpful. DePiep's comment above at 10:23, 2 November 2014 shows the logic behind |$=€ as it means that the dollar symbol is replaced with the euro. Experience shows that very few editors want to convert euro-per-something to euro-per-something-else (ThePromenader is the first to ask for it), and because it is so rare such editors will probably need to ask how it is done here (or possibly find an example in the documentation, when it's updated). They won't care if the syntax looks a little odd so long as it is reasonably short and does the job. Johnuniq (talk) 05:04, 3 November 2014 (UTC)

If I can add my two cents, I think "$=€" (or whatever) is pretty instinctive... as long as it doesn't conflict with any other similar parameter. THEPROMENADER ✎ ✓ 13:52, 13 November 2014 (UTC)

Hello again - is this still active, activated? THEPROMENADER ✎ ✓ 20:29, 14 November 2014 (UTC)

@ThePromenader: The module is now live. I edited Paris to replace the only usages of convert/sandbox. Things move slowly, but we get there in end! Johnuniq (talk) 00:19, 18 November 2014 (UTC)

The semicolon as joiner

Rejected Incorrect punctuation. -DePiep (talk) 11:02, 18 November 2014 (UTC)

Please consider: add option |disp=semicolon (or with another name) to produce the spaced semicolon ;  as the joiner:

• 750,000 imperial gallons; 3,400,000 L -- [hardcoded example]
• {{convert|24,000|GL|km3|disp=x|; }} → 24,000 gigalitres; 24 km³ -- Using current option (soft space is nicely kept)

Semicolon is already used (by default) with multiple output units:

• {{convert|100|km|mi nmi}} → 100 kilometres (62 mi; 54 nmi)
• {{convert|100|km|mi nmi|disp=x|; }} → 100 kilometres; 62 mi; 54 nmi --to the extreme

I have no claim on priority or next version for this. If there are internal problems involved, just postpone/skip. ping by @ Johnuniq. -DePiep (talk) 21:44, 14 November 2014 (UTC)

It's an idea but I'm not sure why you'd want to use a semicolon for this. That it's already used I would hesitate to call a strong argument for it. In fact, as I've mentioned before, it's not so much used as misused. A semicolon has a specific grammatical function and this isn't it. I don't remember who it was that decided on the semicolon for this (all I remember is being glad that it was better than the slash it replaced). I reckon getting rid of the misused semicolon should be on the to-do list in favour normal English (i.e. commas and "or"), e.g.

{{convert|120|psi|kPa atm Torr}} → 120 pounds per square inch (830 kPa, 8.2 atm or 6,200 Torr)

Jimp 15:36, 17 November 2014 (UTC)

Aha. I too remember you mentioning it, which is partly why I wrote this, but I could not reproduce that from the archives. Now I understand you actually oppose it, and it was related to the slash-or(or /)-or discussion. If I loose you --your argument that is-- I better stop :-). -DePiep (talk) 11:02, 18 November 2014 (UTC)

• Conclusion: withdrawn. Given the points mentioned by Jimp (possible misuse, grammatically not correct, improper English) I withdraw the proposal, once and for all. And 'self-rejected' is stronger. -DePiep (talk) 11:02, 18 November 2014 (UTC)

Range separator "to-" deprecated; use "to(-)"

• Range separator to- is deprecated. Use to(-) instead

Background:

t- is a formal shortcut for t(-), in range_aliases

• {{convert|3|to(-)|6|m|ft}} → 3 to 6 metres (9.8–19.7 ft) -- The standard range separator
• {{convert|3|to-|6|m|ft}} → 3 to- -- The shortcut does the same

But the shortcut can not be used in simple input (single-parameter range):

• {{convert|3to(-)6|m|ft}} → -- OK
• {{convert|3to-6|m|ft}} → N -- error(?) without warning

The shortcut (saving two keystrokes) leaves any next editor with a question ('what does this mean?'). The simple-input option produces an error without warning. Also, its twin sister option "and-" does not exist.

All this would require exception & warning notes in the documentation, against little or no gain for any editor. So I deprecated this one. Code changes are deferred. -DePiep (talk) 20:59, 14 November 2014 (UTC)

I'm going a bit off the magic ranges as they may be too mysterious for general editors, and they save very little. Compare: {{convert|3-6|m|ft}} and {{convert|3|-|6|m|ft}}. There is not much benefit from the former. As you know, the motivation for the syntax was to make it easy for a template that calls convert and which sometimes needed to pass a single value, and sometimes a range.

I guess you realize that "|3to-6|" is regarded as "|3|to|-6|" (from plus 3 to minus 6), and that's why there is no warning. Johnuniq (talk) 09:23, 15 November 2014 (UTC)

I don't read an oppose of this individual deprecation (of to-). So it stays red in documentation.

"I'm going a bit off" is a bit vague, I guess it means: "I'm opposed, or not interested"?. Either the option set is supported & documented, or it is deprecated. The documentation, and the editor's experience in general, is no place for maybe's. For now, I have not read a deprecation request, so we support it - full heartedly. (And I do think there is serious benefit for the single parameter option). -DePiep (talk) 11:26, 15 November 2014 (UTC)

"Going a bit off" probably has its origins in the fact that fresh milk is great, but after it stands around its initial appeal declines because it turns sour. What I meant is that I was initially very happy about the change to make the ranges illustrated above work, but on second thoughts I'm not sure we should encourage its use. That is, I used to like it, but I like it less now. The feature is not going to be removed, but I don't think adding more range words to the allowed list is needed. I'm happy for to- to be deprecated on the basis that it is unnecessarily mysterious for other editors. Johnuniq (talk) 02:14, 16 November 2014 (UTC)

Deprecation of to- sustained. Wider discussion in the below sections too. (My setup with subsections did not help overview). -DePiep (talk) 12:15, 18 November 2014 (UTC)

Proposal: " by "and " × " to follow MOS

About ranges using "×" or "by" as separator. These are used in multi-dimensional measurements, for example for a cubic measurement. I propose a change of {{convert}} behaviour, in just two rules (two options).

Earlier inroads in this topic are here (and its subsections 1 and 2).

MOS:UNITS 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

We note:

• The "×" option (a.k.a. "times" option, ×):

1. Requires repetition of unit (in the first example; we can forget about (1 × 3 × 6 ) m³ in for this topic).

2. Is spaced ("1 m × 3 m" not "1 m×3 m")

3. This MOS rule complies with the BIPM SI-standard, and with US standard NIST 811 for measurements in SI. This is the preferred format for scientific quantities.

4. SI-standard requires that symbols are used, not names (this also helps text length on this wiki).

• The "by" option:

1. Does not require repetition of unit

2. Is spaced ("1 by 3" not "1by3")

3. This rule does not follow SI-rules from BIPM or NIST (linked above). However, as reflecting spoken language it is deemed acceptable outside of scientific domains.

• Both MOS options are not excluding full names explicitly. Writing full names is acceptable. This difference (write unit symbol or name) is of no consequence in this issue, as long as the measurement does not mix using units and names: not 3 × 4 by 5 m.

Proposal

{{convert}} can produce by option each of these two MOS-compliant forms.

A conversion shall use one separator in all conversions (input, outputs)

• "×": 2 m × 3 m (2,000 mm × 3,000 mm)
• "by": 2 by 3 m (2,000 by 3,000 mm)

Unit names can be used instead of symbols, when appropriate.

Template:Convert workings

(See also Update below on parameter interaction)

{{Convert}} today produces these two main formats

"×" {{convert|2|x|3|m|mm}} → 2 by 3 metres (2,000 mm × 3,000 mm) N Error: uses "by" and "times" separator format in one conversion (inconsistent style); "by" is not asked for.

"×", |abbr=on: {{convert|2|x|3|m|mm|abbr=on}} → 2 m × 3 m (2,000 mm × 3,000 mm) Y Per MOS and per SI-standard

"by" {{convert|2|by|3|m|mm}} → 2 by 3 metres (2,000 by 3,000 mm) Y

• Basic implementation:

• parameter |x| (lc letter x) shall produce the spaced times separator: " × " in all output.
• parameter |by| shall produce the spaced ' by ' separator: " by " in all output
• Using unit names instead of symbols (|abbr=) is not part of this MOS guideline implementation. It should be decided elsewhere, e.g. by the article editor.

-DePiep (talk) 18:03, 3 November 2014 (UTC)

Update on parameter interaction

Later in the process, I discovered this parameter influence: When |x| is entered, the output depends on the |abbr= setting.

• When |abbr= is not set (default), first unit is in name and the separator is changed into "by":

{{convert|3|x|4|m|ft}} → 3 by 4 metres (9.8 ft × 13.1 ft)

• When |abbr=on, all units are in symbol and "×" is used:

{{convert|3|x|4|m|ft|abbr=on}} → 3 m × 4 m (9.8 ft × 13.1 ft)

• When |abbr=off, all units are in name and separator "by" is used:

{{convert|3|x|4|m|ft|abbr=off}} → 3 by 4 metres (9.8 by 13.1 feet)

All individual measurements are following the two MOS rules. Must say, writing "3 meter × 4 meter" is not defined wrong by MOS rules. One can rethink whether it is sound that the template changes the separator (for the scientist this means an extra step to the documentation to get it right). Writing |x| when it is entered, with symbols or names, can be acceptable too. (or, option 3 mirroring the default: turn all units into symbols, automatically). -DePiep (talk) 16:29, 13 November 2014 (UTC)

Other issues

Once we have agreed on the proposal, there are these issues of later concern.

• Issue: "times" format and unit names

When using the "times" format, the SI-standard does not allow writing unit names (MOS does allow this), symbols should be used. This could be hardcoded in {{convert}} (as '|x| sets |abbr=all as default'), or it can be mentioned in the documentation.

• Issue: cross-defined parameter

To complicate matters: the parameter |x| value is cross-defined now: |x| produces separator " by " in the input measurement. The process of change is to be considered. (Enforce once in a code change? Check & edit usages somehow?)

• Issue: Parameter |xx| produces:

|xx| {{convert|2|xx|3|m|mm}} → 2 × 3 metres (2,000 × 3,000 mm) N non-MOS

|xx| will be deprecated. Is not MOS-compliant. When used, the parameter should produce the new |x| outcome.

• Issue: Parameter |*| produces unspaced × separator:

|*| {{convert|2|*|3|m|mm}} → 2×3 metres (2,000×3,000 mm) N non-MOS

|*| will be deprecated. Is not MOS-compliant. When used, the parameter should produce the new |x| outcome.

• Issue: Parameter |abbr=mos:

{{convert|2|x|3|m|mm|abbr=mos}} → 2 by 3 metres (2,000 mm × 3,000 mm) N non-MOS

{{convert|2|by|3|m|mm|abbr=mos}} → 2 by 3 metres (2,000 by 3,000 mm) N non-MOS

The examples are not(!) MOS-compliant.

abbr=mos will be deprecated. It is not MOS-compliant. Also, it is non-intuitive and incorrect wording. When this parameter is set, it should be ignored in the code. |x| and |by| will do the job.

• Issue: topical exceptions

There might be topics (countries, cultures, professions) where a variant format is used. If such a variant should be supported by {{convert}}, there should be an "exception" route. In now way it can force the MOS-adherance to be compromised. I have not seen such cultures, by the way.

-DePiep (talk) 18:03, 3 November 2014 (UTC)

Deprecation of parameters |xx|, |*| and abbr=mos

Deprecated parameters, not compliant with MOS:UNITS:

• Range separator |xx| is deprecated. Use |x| instead
• Range separator |*| is deprecated. Use |x| instead
• Range formatting by abbr=mos is deprecated (will be ignored). Use |by| or |x| instead

Irrespective of the main proposal above ("by" and "×" formatting), these three options do not follow MOS:UNITS. See #Other issues above for demonstrations. So they can be deprecated right away. Current "by" and "×" formattings are not ideal, but they do produce correct individual formats. -DePiep (talk) 15:46, 5 November 2014 (UTC)

I would like to defer on this. I take it that the plan is to change |xx| and |*| so they are equivalent to |x|, and to ignore abbr=mos. Style guides and uniformity are good, but the issues seems rather inconsequential—just preferences that people could reasonably argue about. At the minimum I would want to examine current usage in articles and try to work out if there is a reason these options are used, and what might happen as a result of the proposed changes. To do that I would want to download a current database dump (I had planned to do that in the near future) rather than use my six-month old list. The options can be deprecated in the documentation, and that should be enough for now. Johnuniq (talk) 03:16, 6 November 2014 (UTC)

OK with me. Deprecated in documentation they are, and a look at their usage is careful.

The big combing action can wait (and could be combined with other combing actions on that same actual dump, so putting it on ice is good). -DePiep (talk) 05:10, 6 November 2014 (UTC)

Comments

I'm in favour of these proposals. Jimp 13:26, 13 November 2014 (UTC) There is no need to cater to the handful of editors who refuse to follow MOS just because they don't like it but, yes, let's have a look at where (and by whom) the template is being used to contravene MOS, if some special exception warrants being brought up at WT:MOSNUM, let's do so, and when the issue is solved, we could proceed with the proposals put forth or with whatever other action seems appropriate. Jimp 15:50, 17 November 2014 (UTC)

Yep. These non-MOS options are marked "deprecated" in the /doc & have an alternative, so any new use is an editors responsibility. For a next step, Johnuniq said they want to: 1. In a fresh enwiki dump, check all current usages; there might be situations found that require a deprecated option. That deprecation is then to be reconsidered. 2. Asap after that dump check and a article cleanup sweep, the dozen deprecated options should be removed from code. These steps can wait. Could be summer 2017, or later. -DePiep (talk) 14:01, 18 November 2014 (UTC)

2017 isn't too long to wait. This is an ongoing project. There's still a lot to do. I remember about seven years ago thinking something like "Yeah, a couple of weeks should be enough to get this template in order.". Jimp 14:42, 18 November 2014 (UTC)

15 p.s.i.g (15 psig)

For Boilermaker#Boilermaking 15 p.s.i.g → 15 psig → 15 psi(?)
{{convert|15|psig|bar kPa|sigfig=3|abbr=on}} 15 psig instead of {{convert|15|psi|bar kPa|sigfig=3|abbr=on}} 15 psi (1.03 bar; 103 kPa), if that is even necessary. Peter Horn User talk 13:54, 5 November 2014 (UTC)

I do not think convert should handle psig. Pounds per square inch appears to be correct, and it says that psi = psia (psi absolute) = pressure relative to a vacuum, whereas psig (psi gauge) = pressure relative to a standard atmosphere. However, what would psig be converted to? kPag (kPa gauge)? In common usage, psi means psig as 30 psi pressure in a car tire means the air inside is at a pressure 30 psi above the air outside. Johnuniq (talk) 00:24, 6 November 2014 (UTC)

So 15 psia</nowiki> 15 psia does not work either. Peter Horn User talk 00:16, 7 November 2014 (UTC)

General readers will have no idea what psig or psia are, and text in the article should be used to say that such-and-such a pressure is with respect to a vacuum or a standard atmosphere, if necessary. Pressure includes the view that "any modifiers be instead applied to the quantity being measured rather than the unit of measure" (that is, "psig" and "kPag" should not be used). I do not think that text like "15 psig (1.03 barg; 103 kPag)" or "15 psia (1.03 bara; 103 kPaa)" would be desirable. Johnuniq (talk) 01:04, 7 November 2014 (UTC)

Yes, a specification belongs to the quantity, not the unit. One is supposed to write, for example:

Pressure_g = 15 psi (103 kPa)

not Pressure = 15 psi_g (103 kPa_g)

Now this is "only" an SI-rule, so the pounds & inches could claim an escape, but I don't think we should go that route. -DePiep (talk) 02:35, 9 November 2014 (UTC)

I'm much inclined to agree with you, DePiep; it could be an escape but it's an escape from a logical principle. It's no surprise that those in favour metric are in favour of logic nor vice versa but giving concessions to those who use customary units (whilst they allow us to go metric) doesn't mean that we aught to allow unclear usage. No, clarity is paramount; such stuff as "psig" and "psia" just get in the way of clarity. Jimp 16:02, 18 November 2014 (UTC)

Thousand separator (comma)

Proposal to add parameter option |comma=no

From the October archive, Jimp: No comma.

We have parameter |comma= dedicated to thousand-separation. Already working OK for |comma=5, |comma=gaps, |comma=gaps5:

{{convert|123456789|m|ft}} → 123,456,789 metres (405,041,959 ft) -- default

{{convert|1234|m|ft|comma=5}} → 1234 metres (4049 ft) Y

{{convert|12345|m|ft|comma=5}} → 12,345 metres (40,502 ft) Y

{{convert|123456789|m|ft|comma=gaps}} → 123456789 metres (405041959 ft) Y

{{convert|1234|m|ft|comma=gaps5}} → 1,234 metres (4,049 ft) Y

{{convert|12345|m|ft|comma=gaps5}} → 12,345 metres (40,502 ft) Y

{{convert|123456789|m|ft|comma=gaps5}} → 123,456,789 metres (405,041,959 ft) Y

All fine.

Adding |comma=no (or =none, =off, ...) would make the job set complete. Its function now is made through |adj=nocomma (which is not related to the adjective; but this was a necessity back in 2010).

• {{convert|123456789|m|ft|adj=nocomma}} → 123,456,789 metres (405,041,959 ft)
• {{convert|123456789|m|ft|comma=no}} → 123456789 metres (405041959 ft) -- proposed; construct here

After this, adj=nocomma can be deprecated in documentation. (abbr=comma already is deprecated for being a very bad option name). -DePiep (talk) 03:30, 9 November 2014 (UTC)

I added comma=off to the sandbox because "off" is consistent with other options. While "no" and "none" are logical, I think consistency is better. Johnuniq (talk) 04:05, 9 November 2014 (UTC)

Great. -DePiep (talk) 05:35, 9 November 2014 (UTC)

Basic tests, sandbox:

{{convert|123456789|m|ft}} → 123,456,789 metres (405,041,959 ft) -- default

{{convert|123456789|m|ft|comma=off}} → 123456789 metres (405041959 ft) -- expected OK when gone live.

{{convert/sandbox|123456789|m|ft}} → 123,456,789 metres (405,041,959 ft) -- default, unchanged

{{convert/sandbox|123456789|m|ft|comma=off}} → 123456789 metres (405041959 ft) Y change.

-DePiep (talk) 18:50, 9 November 2014 (UTC)

Request to add gaps in <1 values

{{thrown out}} -DePiep (talk) 12:23, 10 November 2014 (UTC)

From the October archive, last month, Jimp: Missing_gaps. Compare thousands-gaps in decimal fractions, by {{val}} and by {{convert}}:

• {{val|12.34554678|u=in}} → 12.34554678 in. {{Val}} always has gaps.
• {{val|12.3455467|u=in}} → 12.3455467 in. There is a treshold for lone figures.
• {{convert|12.3455467|in|comma=gaps}} → 12.3455467 inches (313.57689 mm)

If I understand this well, it should happen automatically with |comma=gaps and |comma=gaps5. -DePiep (talk) 03:30, 9 November 2014 (UTC)

The code for that is quite difficult and my lazy nature makes me want to see some real examples where it would be needed. I haven't checked recently, but I don't think comma=gaps is being used. One site (nowiki) is using &nbsp; for their group separator, and they said they did not want them after the decimal mark. I think I mentioned the benefits of gaps, but I didn't push it because the wikitext it generates is horrific, although I suppose the overhead would not be noticed. Johnuniq (talk) 04:05, 9 November 2014 (UTC)

OK, a well-thought rejection is as good as anything else. (And it was no my idea in the first place ;-) ;-) ). -DePiep (talk) 05:35, 9 November 2014 (UTC)

 Pending I always think it better to say "We'll get to it in time." than "No, it's too hard.". (I write "we" but I haven't got my head around Lua yet so I hardly count as one who's working on the template at the moment.) True, gaps might not be being much used at the moment but it's a relatively new option of which people might not yet be aware. There are, though, pages which use this kind of formatting but being restricted to scientific/mathematical/technological/engineering topics (though somewhat unreservedly in my negligible opinion since at least in this country delimiting with spaces is quite normal in any context... that's another fight though ...) there'll be less of a rush to convert SI to mediæval units. Jimp 15:20, 18 November 2014 (UTC)

Johnuniq is still doing the Lua coding, this talkpage receives the regular unit-proposals, and I build the {{convert/doc}}-ation. From my job, I raise questions & issues here to sort things out and to get things clear. At parameter level things can change. However, Johnuniq has noted that a big redesign is not in sight (that could be, my example, about a number handling submodule to accept more formats). tHIG-DePiep (talk) 16:39, 18 November 2014 (UTC)

More on range separator: _words and &

Some notes on range separators. Don't spend too much time on problems, just skip those (no need to make it complicated). These is not priority in here.

• Module:Convert/text • Module:Convert/text/sandbox • different (diff)

Range separators

Conclusion:

• Range separator |&| is deprecated. Use |and| instead

Request

The & (ampersand) is formally available as an alternative for |and|

• {{convert|3|&|6|m|ft}} → 3 &
• {{convert|3|and|6|m|ft}} → 3 and 6 metres (9.8 and 19.7 ft)

I'd like to know if we should support & document the ampersand, or deprecate it.

My opinion: if it can not be in the range_words list (see next subsection), it should be deprecated. I prefer not to have exception notes (in the editors mind, and in documentation). -DePiep (talk) 22:25, 14 November 2014 (UTC)

• Conclusion: this ampersand usage is deprecated (see next subsection, with [1]). Top note added here.  Done -DePiep (talk) 11:57, 18 November 2014 (UTC)

Range words

range_words = { '+/-', 'to(-)', 'xx', 'x', '*', 'to', 'or', 'by', '–' , '-' }

Range_words are accepted as single-parameter range separator:

• {{convert|3to(-)6|fm|ft}} →

Compared to the full list of separators (that are used with pipes: |, and|) this list can not accept for example those with commas and spaces, and not the "+".

However, some additions might be possible, to make usage & documentation more natural. (Ideally the lists are the same as much as possible). I propose to consider adding:

and(-)
and
±
±
–
&<!-- not, is deprecated -->

Possibilities? Johnuniq. -DePiep (talk) 22:25, 14 November 2014 (UTC)

I hate complex options and would prefer to buy a mediocre hotdog than spend five minutes choosing exactly what I want on my perfect sandwich. The only reason to support stuff like ± is that people fiddle and might do a global search-and-replace to their preferred text without noticing they are changing ± inside a template. Using & displays "and" so I would prefer to deprecate ampersand because it does not help. I agree that clean documentation (all range words work everywhere) would be best, but parsing text is an inefficient process so I think we might have to live with the fact that only some items work in magic ranges. For the record, the above notification is another that I did not receive—I recently learned that notifications don't work when a comment includes headings. Johnuniq (talk) 00:36, 18 November 2014 (UTC)

- "that people fiddle and might do a global search-and-replace [with &plusmn;]". I disagree. I use the entity name because I don't have a ± on my keyboard. Probably most other editors too.

- Hard to reason with your aversion. I understand that a character like ± might introduce issues, and so should be rejected for this list, all fine. But I see no problem with the and(-), and maybe and in this. Since you want to keep this list option (and we don't have an alternative yet, for example a convert input analyser), I see no point in leaving it half-baked (and/to being twins). Documentation and editors experience are chaotic this way. -DePiep (talk) 12:11, 18 November 2014 (UTC)

- ± is in |wiki markup= at the bottom of the edit page. Right after ≥

Unbuttered parsnip (talk) mytime= Sun 11:20, wikitime= 03:20, 23 November 2014 (UTC)

Crop yields

What I'd like to do is convert crop yields, e.g. kg / ha to lb / acre. How can I do it, what to do? I looked at, but didn't understand, Module:Convert/documentation/conversion data/doc. Currently I have to do it the hard way (using {{convert|#expr:}} combination(s)). A propos the above, would there be any possibility also of supplying the range as a %age, and the module works out the numbers? E.g. 99|±|10% → 89 – 109 Unbuttered parsnip (talk) mytime= Sun 11:26, wikitime= 03:26, 23 November 2014 (UTC)

Sorry, the docs are overwhelming. However, the usage is straightforward:

• {{convert|123|kg/ha|lb/acre}} → 123 kilograms per hectare (110 lb/acre)
• {{convert|123|kg/ha|lb/acre|abbr=on}} → 123 kg/ha (110 lb/acre)
• {{convert|89|-|109|kg/ha|lb/acre|abbr=on}} → 89–109 kg/ha (79–97 lb/acre)
• {{convert|99|+/-|10|kg/ha|lb/acre|abbr=on}} → 99 ± 10 kg/ha (88.3 ± 8.9 lb/acre)
• {{convert|99|+/-|10|kg/ha|0|lb/acre|abbr=on}} → 99 ± 10 kg/ha (88 ± 9 lb/acre)

There is no method to specify a range as a percentage—you would have to calculate that manually. Johnuniq (talk) 03:45, 23 November 2014 (UTC)