Template talk:Convert

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

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

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

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

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

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

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

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

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

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

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

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

Notes

- Even when usage is zero, the functionality is not present in current {convert}.

- The current 28 articles in here, are the result of a manual cleanup by me (where possible, modern {convert} was used). The remainning situations are the real differences.

- There may be other wikicode {convert/...} subtemplates in the same situation. I did not check. {{convert/spell}} is deprecated.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• About hardcoded conversion numbers (to allow more complicated grammatical constructions).

I have documented the subst:-solution for this (do {subst:convert} and then edit the plain code for grammar). see Convert/doc. Took the example from Fort McHenry:

The American defenders had 18-, 24- and 32-pounder (8, 11 and 15 kg) cannons.

• In the process I discovered this edit that changed the input (38 pound to 32 pound) but left the conversion unchanged (17 kg). Lesson: subst: and any hasrdcoded conversion can go unchecked. -DePiep (talk) 13:43, 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}} - Template:Convert/old
• {convert/old |2|xx|6|ft|m}} - Template:Convert/old

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

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

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

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

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

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

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

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

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

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

Break to subtopic: repetition of the unit

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

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

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

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

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

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

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

x

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

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

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

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

by

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

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

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

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

xx

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

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

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

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

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

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

• A possible solution.

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

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

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

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

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

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

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

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

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

disp=mos deprecated and not needed.

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

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

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

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)

Deprecated: disp=2, disp=u2

I have just deprecated these two options:

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

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

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

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

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

More deprecations

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

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

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

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

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

That's interesting, as that is the second time in recent days that I've seen what looks like a correct post for which I did not see a notification. In your next comment, please test: [[User:Johnuniq|Johnuniq]]

Some parameters are easy to implement, and some may require major refactoring. I'm still a bit burnt out, but am happy to look at anything. Perhaps if you would outline one proposal I would let you know what might be involved. The main problem you would face with me is that I favor simplicity—what people are used to is simple, even if, in retrospect, it would have been better done a different way. Johnuniq (talk) 10:12, 22 October 2014 (UTC)

OK, I'll write a broad outline before spending too much time. And I'll slow tha pace (last week a lot of posts/topics were added here).

Here is the ping (I learned that a ping only is sent if it is saved together withe a ~-signing):

pingtest 1: Hello Johnuniq -DePiep (talk) 21:38, 22 October 2014 (UTC)

Thanks, that ping worked (I was notified shortly after you posted, but haven't got around to responding until now). Your previous ping (diff) used {{U|Johnuniq}} and seemed to have a signature, and per WP:ECHO, {{U}} is supposed to ping, so I don't know what happened.

I suggest a quick outline just to give the flavor—I don't want to comment on how I'd feel about new options without some idea of the plan. Details can come later. Johnuniq (talk) 02:45, 24 October 2014 (UTC)

Using {convert/per} and singulars

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

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

No one has noticed the plural problem before [update: the following now works]:

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

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

I updated Module:Convert/documentation/conversion data/doc and Module:Convert/data with the new units and with fixes to "inhabitants" as mentioned by Jimp above. Are you saying that there should be no space before the "/sq mi" in the above? It probably works like that for compatibility with the old template, but I haven't looked. Should it be changed? Johnuniq (talk) 09:45, 23 October 2014 (UTC)

The old version put the space in simply because it was too much trouble to get rid of but it doesn't belong there. Jimp 03:39, 24 October 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)

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

Resolved

 – Both have been moved out of {convert} sphere. See {{Long ton}}. -DePiep (talk) 19:44, 26 October 2014 (UTC)

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

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

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

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

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

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

I've moved them out merging them both to {{long ton}}. Jimp 08:02, 24 October 2014 (UTC)

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)

E notation

{{Convert/E}} handles input using e-notation (it converts it into normal scientific notation). Could this function be added to the main template? Jimp 05:58, 26 October 2014 (UTC)

That's tricky. I explained in one of the archives that the module should be more modular, but it is extremely complex and doing everything "properly" would have made it quite a bit longer, more complex and slower. My main concern was to get it working efficiently while being very close to what the old templates did for compatibility. I can look at translating e notation into something properly formatted, and I agree it should be done. But, can we please make a wish list because I won't get around to serious work on some items (like this one) for quite a while. Johnuniq (talk) 07:02, 26 October 2014 (UTC)

Don't let yourself be hurried. These talkpage archives are patient. -DePiep (talk) 10:30, 26 October 2014 (UTC)

I understand where you're coming from. There's always been more work to be done on this template than was humanly possible and this is one of the less urgent issues. Jimp 12:11, 26 October 2014 (UTC)

Postpone this a year: code change for deprecated options. Once decided "deprecated", an option is marked such in the documentations (red text + the alternative). Any code consequences can be postponed years without any damage. -DePiep (talk) 19:25, 26 October 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 Template:Currency/Type  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)

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)

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)

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)

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 • same content
• Module:Convert/wikidata • Module:Convert/wikidata/sandbox • same content
• Module:Convert/wikidata/data • Module:Convert/wikidata/data/sandbox • same content

The changes are:

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

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

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

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)

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)

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

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

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)