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.


 * → "10 stone 5 pounds (66 kg; 145 lb)"
 * → "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,  would let us link stone without also linking the more mundane pounds and   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. Jimp 02:22, 26 October 2014 (UTC)
 * For this, I was thinking about exotic 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:
 * → 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 . This is to be detected (set a flag) and stripped early in the parsing. That unit then is linked. ,  ,  . -DePiep (talk) 10:27, 26 October 2014 (UTC)
 * That's a nice idea, how about this, though? Rather than adding   add   and  .  So that  would link stone and  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  or  . Johnuniq (talk) 10:48, 27 October 2014 (UTC)
 * True, how about single brackets (e.g. { })? 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. 1 m3 currently expands to '1 cubic metre (1.0 m3)'.

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.

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  in the options, and is the default setting. Examples:
 * → 12 m
 * → 12 m
 * → 12 m
 * → 12 m
 * → 12 m
 * → 12 m
 * 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 :
 * → 1 m3
 * Johnuniq (talk) 22:08, 30 October 2014 (UTC)


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


 * 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. -[[User:DePiep|DePiep]] (talk) 18:53, 31 October 2014 (UTC)


 * This discussion is continued at Wikipedia_talk:Manual_of_Style/Dates_and_numbers. -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


has a few somewhat dubious outputs. Here are some examples from articles. 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)
 * → few inches (half-dozen centimetres)
 * → few hundred metres (1,000 ft)
 * → several feet (a few metres)
 * → few metres (half-dozen feet)
 * → several miles (dozen km)
 * → several-metre (15-30 feet)
 * → one-third mile (0.54 km)
 * → several square kilometres (a few square miles)
 * 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 6 x, the output unit is repeated twice, like 6 x. I don't think this is ideal, and it does not occur when using the "by" parameter to separate the dimensions, like 6 by. Is there a particular reason for the discrepancy? I discovered it at September Morn. Graham 87 13:09, 20 September 2014 (UTC)
 * , some like it, some don't, try 6 * instead, and if that doesn't work for you, see Help:Convert. Frietjes (talk) 14:44, 20 September 2014 (UTC)
 * Thanks, that works. Graham 87 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 . A physicist will always always write, correctly:
 * 1 m × 3 m ✅ or 1 × 3 m2 (but this is not MOS) ✅
 * {convert} does not (I use mm, because ft-in would be confusing) :
 * 1x3 m &rarr; 1x3 m
 * However, {convert} also has this old mos trick:
 * 1x3 m &rarr; 1x3 m (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  operator, the MOS says it is OK (that would reflect speaking language):
 * 1by3 m &rarr; 1by3 m
 * 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  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 has the alternatives:   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. 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 : 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  as a new way to break the rule. Is this what we really want: a which ignores the MOS, which caves in to some user's whim regardless of extensively debated community consensus? I propose we get rid of  and   once and for all. Note that  was removed early last year (if I remember correctly and so was ,   and  ) 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 "&times;" in both sides (input/output) of a range conversion (where previously the option "x" would show "by" with "&times;" 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 "&times;" (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 below: the slash as separator is misleading (creating  a common fraction).
 * Maybe we need to control exceptions through canvas, slash, 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  for a range, and 220 use  . 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   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   as non-linear, and I spend wearing a keyboard for the tabular Track gauge).
 * 2. But really, parameter 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 slash below. This thread can continue about "by" range multi-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:, mos, on, Multiple dimension indicators  ,  ,  ,  , and MOS:UNITS).

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

For scientific and technical context, option 1 (1m &times; 3m &times; 6m) is OK (as is the non-MOS option 4: 1 &times; 3 &times; 6m3; 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  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 mos. Demos (for simplicity, I'll use two-dimensional examples, that is an area still not a length; so an m &times; m is required, for m2):
 * x
 * &rarr; 1 x ❌ -- See also issue #2 below.
 * &rarr; 1 x ❌ -- Note that setting |abbr=off changed unit pattern, and "x" (= &times;) changed into "by" (with a different MOS rule!)
 * &rarr; 1 x ✅


 * &rarr; 1 x ✅


 * by
 * &rarr; 1 by ✅
 * &rarr; 1 by ✅
 * &rarr; 1 by ✅


 * &rarr; 1 by ❌ -- See also issue #2 below.


 * xx
 * &rarr; 1 xx ❌
 * &rarr; 1 xx ❌
 * &rarr; 1 xx ❌


 * &rarr; 1 xx ❌ -- See also issue #2 below.
 * Note: In  abbr is overwritten, and so is not considered (mos can not set off and v.v.). Same for on.
 * Note: The  as in   is always a spacing variant only of , with or without mos, and so does not add to this issue.

Issue #1. [added later; issue has shifted] It appears that on combined with  answers my need: a correct scientific presentation. Remaining point: 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  is always shown as "&times;", no changes into "by" or whatever ( in input, in output in LH, in RH).
 * 2. Parameter  always repeats units, following MOS (example 1 m &times; 2 m &times; 3 m) (in LH, in RH)
 * 3. Parameter  is "by" always. Follows MOS about "by". (no changes?) (in LH, in RH)
 * 4. Deprecate mos, after all this is done (no loss of options)
 * 5. Parameters  and  : if kept, they produce &times; and so must  comply with changes 1 and 2 ("&times;" 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 "&times;" 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 "&times;"-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 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:
 * &rarr; 1 metre &times; 3 metres (1,000 mm &times; 3,000 mm) -- MOS, "&times;"
 * &rarr; 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:
 * &rarr; 1 metre&times;3 metres (1,000 mm&times;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 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 "&times;" 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":
 * &rarr; 1 x ❌ -- current. Uses both "by" and "x" forms (although each one is correct)


 * x - projected
 * &rarr; 1 x -- (to compare; current live version)
 * &rarr; 1 metre × 2 metres (1,000 mm × 2,000 mm) ✅ -- proposed above, hardcoded here
 * &rarr; 1 x ✅
 * &rarr; 1 metre × 2 metres (1,000 millimetre × 2,000 millimetres) ✅ -- proposed above, hardcoded here

This is a variant derived from "x", by mentioning units differently:
 * xx
 * &rarr; 1 x -- (to compare; current live version)
 * &rarr; 1 xx ❌ -- Not MOS. Both "x" and single-unit in one measurement!
 * &rarr; 1 xx ❌ -- 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 option  does the same as "xx", but with spaces removed:
 * Asterisk ( * )
 * &rarr; 1 * ❌ -- Not MOS.
 * &rarr; 1 * ❌ -- 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 "&times;" is not MOS any time, too (two MOS breaches).

Outcome. Once the proposed changes for  are applied (see section above), there is no need for "xx" and "*" variants or exceptions any more. However, if the above  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 &times; 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:  &rarr;  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 &times; 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 &times; 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 &times; sign to be used: "2.6×106 z" (currently through option  in ). 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
Above, proposed to deprecate the option slash (and its synonyms /, s). (See here)
 * &rarr; 10 km ❌

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  or   or   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: . 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  in place of   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 km2/19 sq mi/3.3 km3/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  has made much more sense.  Jimp 11:11, 8 October 2014 (UTC)
 * Re : 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  and   from the documentation, and move   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: Consequences tbd. (Delete from source code, hardcode to show " or " right away, ...). -DePiep (talk) 18:29, 18 October 2014 (UTC)
 * disp=slash, disp=s, disp=/ are deprecated. Use disp=or instead
 * . I think this deprecation can be pushed into code (make 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 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.
 * 1 km &rarr; 1 km
 * &rarr; -- " 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 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 table and tablecen. It produces numbers only, with table pipes and styles added. Additional setting of on adds a hidden sorting key. For example:

align="right"| 7000100000000000000 1
 * 1 km &rarr;
 * align="right"|0.62

align="center"| 7000100000000000000 1
 * 1 km &rarr;
 * 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  column in the demo). Solution: add a sortkey to the second column too (derived from that number).


 * Detail 1: there also exist options in, out. These are meaningful outside of 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 table/tablecen and any on/in/out is set, all numeric columns should get their own sorting key.


 * Detail 2: the span tag now sets . But for example sort uses tags this way:  . Should {convert} use these classes? -DePiep (talk) 15:21, 1 November 2014 (UTC)

Yes, this needs fixing, and I suppose the css bloat from 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: hello → 1234&amp;#32;! hello hello → 1234&amp;#32;! hello
 * 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 . 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: . 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
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).

2 ft → 7001300000000000000 2 ft 6 in (76 cm)

2 ft → align="right"| 7001300000000000000 2 ft 6 in
 * align="right"| 7001300000000000000 76 cm

76.2 cm → align="right"| 7001300000000000000 76.2 cm
 * align="right"| 7001300000000000000 2 ft 6.0 in
 * align="right"| 7001300000000000000 30.0 in

76 cm → 7001300000000000000&amp;#32;! 76 cm

I would be pretty reluctant to add the  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. Jimp 13:08, 13 November 2014 (UTC)
 * I have confirmed that using  with convert/sandbox in the above examples gives exactly the same sort key. When using , the module uses the first input value to generate the sort key, regardless of flip. It uses the first output value when   is used. The word "first" is used in case there is a range of inputs, like  . 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 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 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, Section (United States land surveying) 4+3/4 section 4+3/4 section. Peter Horn User talk 18:50, 12 November 2014 (UTC)
 * Is defined as one square mile. So we can write:
 * $4 3/4$ sections (4+3/4 sqmi) &rarr; $4 3/4$ sections (4+3/4 sqmi). -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, 133 e9L 133 e9L "spell=us" does not yet work here. Peter Horn User talk 16:25, 14 November 2014 (UTC)
 * , see Help:Convert, you want us not us: 133 e9L 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 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 133 e9L 133 e9L. Change that to 1.33 e11hL 1.33 e11hL or 1.33 e11hl 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
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 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:
 * &rarr; 1 ozt
 * &rarr; 1 troy ounce
 * The pound:
 * &rarr; 1 troy pound
 * &rarr; 1 lbt

Maybe unit name  can be added. troy ounce is quite common. -DePiep (talk) 19:37, 3 November 2014 (UTC)
 * I formally request that  be added and as a recognised name.   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  -DePiep (talk) 12:29, 13 November 2014 (UTC)
 * Are you saying that there should be an alias: ? 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;  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: (by U template this time, not &lt;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.

The changes are:
 * Options,  ,   are now equivalent to   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  because the tilde meant that the symbol is never used; see use name (I found this while investigating the previous issue).
 * Conversions like  can use an alternative currency symbol such as the euro  per discussion above.
 * Conversions for a sortable table ( or   with   or  ) 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  added to replace traditional   and   per discussion.

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

The following is from Help:Convert 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.

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  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 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)
 * Version 1 December 2013
 * Version 2 January 2014
 * Version 3 April 2014
 * Version 4 July 2014
 * Version 5 September 2014
 * Version 6 November 2014

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:
 * → 12.3 $/acre
 * → 12.3 $/mi
 * → 12.3 $/kg
 * → 12.3 $/m3
 * → 12.3 £/acre

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 ; )  THE PROMENADER  ✎ ✓ 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.
 * → £12.3 per acre (£30/ha)
 * → €12.3 per mile (€7.6/km)
 * Jimp 12:05, 26 October 2014 (UTC)
 * Great minds... ; )  THE PROMENADER  ✎ ✓ 12:07, 26 October 2014 (UTC)
 * (son of edit conflict) Wait, is that a suggestion, or does it exist already?  THE PROMENADER  ✎ ✓ 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 ; )  THE PROMENADER  ✎ ✓ 12:16, 26 October 2014 (UTC)

Doh. I just tested for fun. Jimp's idea would be the simplest across-the-board solution.  THE PROMENADER  ✎ ✓ 19:07, 26 October 2014 (UTC)
 * The general currency sign in typography is . 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 &rarr; ha, that is converted by both number & unit). Can the code be more general, and allow &lt;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 note that in the examples, the currency always has value=1 (while it is the denominator, like acre &rarr; ha, that is converted by both number & unit). Can the code be more general, and allow &lt;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. 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!  THE PROMENADER  ✎ ✓ 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:
 * → 12.3 $/acre
 * → 12.3 £/acre
 * → 12.3 £/nmi
 * The list of units is limited (todo: find & document this list.  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:
 * → -- 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 ; )  THE PROMENADER  ✎ ✓ 15:45, 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 ; )  THE PROMENADER  ✎ ✓ 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.  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.  THE PROMENADER  ✎ ✓ 09:28, 28 October 2014 (UTC)
 * But I digress.  THE PROMENADER  ✎ ✓ 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.  THE PROMENADER  ✎ ✓ 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 [//en.wikipedia.org/w/index.php?title=Special%3AWhatLinksHere&target=Template%3AConvert%2Fsandbox&namespace=0 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:
 * &rarr; --default
 * &rarr; --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   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.  THE PROMENADER  ✎ ✓ 13:52, 13 November 2014 (UTC)
 * Hello again - is this still active, activated?  THE PROMENADER  ✎ ✓ 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
❌ Incorrect punctuation. -DePiep (talk) 11:02, 18 November 2014 (UTC)

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


 * 750,000 imperial gallons; 3,400,000 L -- [hardcoded example]
 * 24,000 GL &rarr; 24,000 GL -- Using current option (soft space is nicely kept)

Semicolon is already used (by default) with multiple output units:
 * 100 km &rarr; 100 km
 * 100 km &rarr; 100 km --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@undefined. -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.


 * → 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:

is a formal shortcut for, in
 * &rarr; 3 to(-) -- The standard range separator
 * &rarr; 3 to- -- The shortcut does the same

But the shortcut can not be used in simple input (single-parameter range):
 * &rarr; 3to(-)6 m -- OK
 * &rarr; 3to-6 m ❌ -- 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:  and  . 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 " " is regarded as " " (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 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 " &times; " to follow MOS
About ranges using "&times;" or "by" as separator. These are used in multi-dimensional measurements, for example for a cubic measurement. I propose a change of behaviour, in just two rules (two options).

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


 * MOS:UNITS says:

We note:
 * The "&times;" option (a.k.a. "times" option, ):
 * 1. Requires repetition of unit (in the first example; we can forget about (1 &times; 3 &times; 6) m3 in for this topic).
 * 2. Is spaced ("1 m &times; 3 m" not "1 m&times;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 &times; 4 by 5 m.


 * Proposal:
 *  can produce by option each of these two MOS-compliant forms.
 * A conversion shall use one separator in all conversions (input, outputs)
 * "&times;": 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)

today produces these two main formats
 * "&times;"  &rarr; 2 x ❌ Error: uses "by" and "times" separator format in one conversion (inconsistent style); "by" is not asked for.
 * "&times;", on:  &rarr; 2 x ✅ Per MOS and per SI-standard
 * "by"  &rarr; 2 by ✅


 * Basic implementation:
 * parameter  (lc letter x) shall produce the spaced times separator: " &times; " in all output.
 * parameter  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)

Later in the process, I discovered this parameter influence: When  is entered, the output depends on the abbr setting.
 * Update on parameter interaction
 * When abbr is not set (default), first unit is in name and the separator is changed into "by":
 * &rarr; 3 x


 * When on, all units are in symbol and "&times;" is used:
 * &rarr; 3 x


 * When off, all units are in name and separator "by" is used:
 * &rarr; 3 x

All individual measurements are following the two MOS rules. Must say, writing "3 meter &times; 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  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 (as '  sets 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:  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  produces:
 * &rarr; 2 xx ❌ non-MOS
 * xx will be deprecated. Is not MOS-compliant. When used, the parameter should produce the new |x| outcome.


 * Issue: Parameter  produces unspaced &times; separator:
 * &rarr; 2 * ❌ non-MOS
 * will be deprecated. Is not MOS-compliant. When used, the parameter should produce the new |x| outcome.


 * Issue: Parameter mos:
 * &rarr; 2 x ❌ non-MOS
 * &rarr; 2 by ❌ non-MOS
 * The examples are not(!) MOS-compliant.
 * 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.  and   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, 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,  and
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 "&times;" formatting), these three options do not follow MOS:UNITS. See above for demonstrations. So they can be deprecated right away. Current "by" and "&times;" 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  and   so they are equivalent to , and to ignore  . 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 15 p.s.i.g → 15 psig → 15 psi(?) 15 psig 15 psig instead of 15 psi 15 psi, 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 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:
 * Pressureg = 15 psi (103 kPa)
 * not Pressure = 15 psig (103 kPag)
 * 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)

Proposal to add parameter option no
From the October archive, Jimp: No comma.

We have parameter comma dedicated to thousand-separation. Already working OK for 5, gaps, gaps5:
 * → 123456789 m -- default
 * → 1234 m ✅
 * → 12345 m ✅
 * → 123456789 m ✅
 * → 1234 m ✅
 * → 12345 m ✅
 * → 123456789 m ✅
 * All fine.

Adding no (or,  , ...) would make the job set complete. Its function now is made through nocomma (which is not related to the adjective; but this was a necessity back in 2010). 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)
 * → 123456789 m
 * → 123456789 metres (405041959 ft) -- proposed; construct here
 * I added  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:
 * → 123456789 m -- default
 * → 123456789 m -- expected OK when gone live.
 * → -- default, unchanged
 * → ✅ change.

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

Request to add gaps in &lt;1 values
-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 : If I understand this well, it should happen automatically with gaps and gaps5. -DePiep (talk) 03:30, 9 November 2014 (UTC)
 * &rarr; $12.346 in$. always has gaps.
 * &rarr; $12.346 in$. There is a treshold for lone figures.
 * &rarr; 12.3455467 in
 * 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  is being used. One site (nowiki) is using &amp;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)

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 ( [//en.wikipedia.org/w/index.php?title=Special%3AComparePages&page1=Module%3AConvert%2Ftext&page2=Module%3AConvert%2Ftext%2Fsandbox diff] )

Range separators
The & (ampersand) is formally available as an alternative for
 * Conclusion:
 * Range separator &amp; is deprecated. Use and instead
 * Request
 * 3 & &rarr; 3 &
 * 3 and 6 m &rarr; 3 and 6 m

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

My opinion: if it can not be in the  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 ). Top note added here. ✅ -DePiep (talk) 11:57, 18 November 2014 (UTC)

Range words
Range_words are accepted as single-parameter range separator:
 * 3to(-)6 fm &rarr; 3to(-)6 fm

Compared to the full list of separators (that are used with pipes: ) 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 ± &amp;plusmn; &amp;ndash; &

Possibilities? . -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 &amp;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 &plusmn; might introduce issues, and so should be rejected for this list, all fine. But I see no problem with the, and maybe   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 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:
 * → 123 kg/ha
 * → 123 kg/ha
 * → 89 - 109 kg/ha
 * → 99 +/-
 * → 99 +/-
 * 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)