Template talk:Convert

For the Lua module see the Module:Convert Convert tagged articles are in Category:Convert error categories

More on range separator: _words and &

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

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

Range separators

Conclusion:

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

Request

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

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

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

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

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

Range words

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

Range_words are accepted as single-parameter range separator:

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

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

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

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

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

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

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

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

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

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

What happened with abbr=~ ?

Technically, we can |abbr=~ to have both name and symbol returned:

• {{convert|100|Mm|nmi|abbr=~}} → 100 megametres [Mm] (54,000 nmi)

Document or deprecate? -DePiep (talk) 14:40, 18 November 2014 (UTC)

It's a strange option and I don't see how it helps. In May 2014 it was used in the following.

• Chupaca Province {{convert|297|km|0|sp=us|abbr=~}} → 297 kilometers [km] (185 mi)
• Constant linear velocity {{convert|18.96|m/s|abbr=~}} → 18.96 metres per second [m/s] (62.2 ft/s)
• Dots per inch {{convert|0.22|mm|in|abbr=~}} → 0.22 millimetres [mm] (0.0087 in)
• Festuca porcii {{convert|0.7|–|1.2|mm|abbr=~}} → 0.7–1.2 millimetres [mm] (0.028–0.047 in)
• Mariner 1 {{convert|1.04|m|ft|2|abbr=~|sp=us}} → 1.04 meters [m] (3.41 ft)
• Pell City, Alabama {{convert|27.2|sqmi|km2|abbr=~}} → 27.2 square miles [sq mi] (70 km²)
• Puerto Errado {{convert|30|MW|hp|-2|abbr=~}} → 30 megawatts [MW] (40,200 hp)
• Road signs in New Zealand {{convert|10|km/h|mph|1|abbr=~}} → 10 kilometres per hour [km/h] (6.2 mph)
• Sarnia Photovoltaic Power Plant {{convert|247|MW|-2|abbr=~}} → 247 megawatts [MW] (331,200 hp)
• Wolverine (train) {{convert|110|mph|0|abbr=~}} → 110 miles per hour [mph] (177 km/h)

Someone (Jimp?) may like to check those and decide whether they are useful. I would deprecate. Johnuniq (talk) 02:42, 19 November 2014 (UTC)

I'd like to use it as a debug-option (return both to explain what happens). -DePiep (talk) 11:25, 19 November 2014 (UTC)

I s'pose I get the idea behind it but you'd have to admit that it just doesn't look right. It'd be pretty hard to figure out what these are trying to say unless you already know ... and in that case there's no point. I can only assume that the lack of use is a reflexion of its undesirability. I'm not going to miss abbr=~. Jimp 07:32, 23 November 2014 (UTC)

Deprecated in the /docs then. (Jimp, I think Johnuniq suggested you take a look at the list & code it out. Better not me). -DePiep (talk) 21:13, 24 November 2014 (UTC)

Conclusion

• abbr=~ is deprecated. Use abbr=on/off/in/out. (|abbr=out is default behaviour)

DePiep (talk) 21:13, 24 November 2014 (UTC)

Update I just noticed the hidden Category:Pages using duplicate arguments in template calls on this page and have edited the above to remove the cause (the convert in Mariner 1 had sp=us duplicated). I was going to remove the duplicate from the article as well while removing the strange abbr=~, but looking at the article I can now see the point of the option: it's in a sentence saying:

Mariner 1 consisted of a hexagonal base, 1.04 meters (m, 3.41 ft) across and 0.36 m thick (1.2 ft)

and omitting abbr=~ wouuld give:

Mariner 1 consisted of a hexagonal base, 1.04 meters (3.41 ft) across and 0.36 m thick (1.2 ft)

which might cause readers to wonder why the first value says "meters" but the second says "m"—are they different? At any rate, I fixed the duplicate argument on this page and will leave the article for another time. Johnuniq (talk) 10:25, 25 November 2014 (UTC)

Looks like this enters the MOS/style area of "spell in full at first mentioning, after that use the symbol". A neighbouring area, not limited to wiki, is: "Always introduce the abbreviation/symbol together with its full name". With lesser-known units this looks like good editorship. An example sentence:

"The engine had a capacity of 1,000 horsepower [hp] (0.75 MW), later upgraded to 1,200 hp (0.89 MW)."

Punctuation could be improved, maybe into:

"1,000 horsepower [hp] (0.75 MW)"

For now, I think we should keep it deprecated and first redesign its styles & workings. Let's try to get the style advice first (documentation/MOS text on usage). -DePiep (talk) 13:26, 25 November 2014 (UTC)

I think the sentence would read a whole lot better if either both were spelt out in full or both were abbreviated (i.e. "1.04 meters across and 0.36 meters thick (3.41 by 1.2 ft)" or ""1.04 meters across and 0.36 m thick (3.41 by 1.2 ft)"). Were aren't in the business of accommodating bad style (and using bad style to do so is a dubious improvement). I don't believe "spell in full at first mentioning, after that use the symbol" was ever meant as a strict rule never to be bent or broken and in this case I'd argue that clarity trumps this. "1,000 horsepower [hp] (0.75 MW)" would be an improvement. Jimp 11:56, 27 November 2014 (UTC)

Within one sentence - OK, but that misses my point. Let me refine my example: think the two instances sentences apart, maybe even in a different section. For that an editor would like to have the option to introduce a lesser known symbol/abbreviation. (Sort of the 'link once at first mentioning' habit; this one textual only).

Eh, {convert} is accomodating styles isn't it? What bad style do you mean wrt introducing the abbreviation/symbol? Please explain.

I do not propose adding a strict rule or obligation. I do propose too introduce a style-based option. For cases an editor wishes to use one. For that, I first want us to describe that style (instead of setting code for it). -DePiep (talk) 13:04, 27 November 2014 (UTC)

I would treat spelling out of unit names as inelegant. Common units like m and kg are familiar enough to even Americans. Some of them may not know exactly how long or heavy it is but at least they know we are talking about length and weight. And since there is a nice familiar mile/foot/inch or ton/pound/oz figure right next to it, there should be no confusion. For units that are more obscure to the layman (e.g. P for Pascals) we can use links.  Stepho  talk  13:43, 27 November 2014 (UTC)

Yes, and no changes in this.

The topic is: can an editor add an introduction of the symbol? Note that the link (to exemplary Pascal, horsepower here) does not serve this purpose. Question: should {convert} make possible to introduce the symbol with the name? (symbol = 'abbreviation' in {convert} speech). That is, allow {convert} to write

• "1,000 horsepower [hp] (0.75 MW)" ?

Consider this primarily a textual issue (like one could meet in print). It is not the question "what is Pascal", but "written 'Pascal' here, further it will be written as symbol P". -DePiep (talk)

I hope it would be written as "Pa" ;) Archon 2488 (talk) 18:56, 27 November 2014 (UTC)

Correct, I should have said "Pa" for Pascals.  Stepho  talk  22:17, 28 November 2014 (UTC)

Yes, we should be accommodating but up to a point. There should be no need to accommodate that which is undesirable. The bad first style I was referring to here is spelling a unit out in full in one part of the sentence and then abbreviating it in another. The second bad style is the confusing system of putting both the abbreviation and conversion(s) inside the same set of brackets. Of course, if you're introducing a lesser know unit which you'll be using later on, then you'll want something like this, but "1,000 horsepower [hp] (0.75 MW)" or "1,000 horsepower (hp) (0.75 MW)" is better than "1,000 horsepower (hp, 0.75 MW)".

I wonder, though, whether using abbr=~ is the best way to do this. Perhaps it would be better to have (a) parameter(s) to insert text into the output (like was done with {{convert/f}}). We could use the parameter not only to add the abbreviation but to add anything, e.g. "wide" or "per year". Jimp 01:08, 30 November 2014 (UTC)

please' stop talking about spelling out/not spelling out. That has nothing to do with |abbr=~.

I object to adding such text manually. {Convert} has the right symbol available! Leaving it to the editor as free text allows unchecked mistakes. Also the formatting will not be alike. -DePiep (talk) 12:38, 1 December 2014 (UTC)

Need opinions on abbr=~

As an experiment, I have put Jimp's above idea in the sandbox (the possibility of having a more general syntax will have to wait). Examples:

Convert	convert output	convert/sandbox output
{{convert|1.04|m|ft|2|abbr=~|sp=us}}	1.04 meters [m] (3.41 ft)	1.04 meters [m] (3.41 ft)
{{convert|9|kPa|abbr=~}}	9 kilopascals [kPa] (1.3 psi)	9 kilopascals [kPa] (1.3 psi)
{{convert|9|kPa|disp=sqbr|abbr=~}}	9 kilopascals [kPa] [1.3 psi]	9 kilopascals [kPa] [1.3 psi]

Should this change be permanent? Also, please see #Singular bug fixes below for a question regarding singular/plural. Johnuniq (talk) 03:15, 1 December 2014 (UTC)

• So, bring the symbol outside of the brackets: yes. (Guess that is the core proposal).

However, I do not appreciate the brackkets being the same for [symbol] and [number * other symbol]. In measurement values, they are not the same. Simply, use "[]" always or, less simple, use the opposite of the chosen brackets (use "(Hp)" when editor asks for sqbr).

The inverse order "9 kPa [kilopascals] [1.3 psi]" is not possible (because abbr is used already). Just noting.

I propose to drop the unconnected |abbr=~ and add parameter option |abbr=intro for this. -DePiep (talk) 12:46, 1 December 2014 (UTC)

The use of disp=sqbr is very rare (118 instances out of 1.8 million converts in May 2014, none of which used abbr=~), so let's forget about optimizing its appearance. It would be easy to always use square brackets, so the question is which of the following is better:

Mariner 1 consisted of a hexagonal base, 1.04 meters (m) (3.41 ft) across and 0.36 m thick (1.2 ft)

Mariner 1 consisted of a hexagonal base, 1.04 meters [m] (3.41 ft) across and 0.36 m thick (1.2 ft)

The first balloon burst at pressure 9 kilopascals (kPa) (1.3 psi) and the second at 12 kPa (1.7 psi)

The first balloon burst at pressure 9 kilopascals [kPa] (1.3 psi) and the second at 12 kPa (1.7 psi)

I'm happy with either, although perhaps inclining towards [...]. Johnuniq (talk) 01:31, 2 December 2014 (UTC)

I prefer "[ ]" too, because of the alternation with the "( )" brackets for the regular converted output. And indeed no need to alter.

Then I stumbled upon this in WP:MOS#Units_of_measurement: "Potentially unfamiliar unit symbols should be introduced parenthetically at their first occurrence in the article, with the full name given first: for example, Her initial betatron reached energies of 2.3 megaelectronvolts (MeV), while subsequent betatrons achieved 300 MeV." (and in slightly different words in WP:UNIT). So MOS already supports the point of introduction. However, it uses round brackets, in absence of any conversion value. This would be against my reasoned preference, so I think I'll have to talk with MOS. -DePiep (talk) 06:47, 2 December 2014 (UTC)

• @Johnuniq:, did you consider the suggestion for |abbr=intro (or another option value) for |abbr=~? -DePiep (talk) 12:32, 5 December 2014 (UTC)
  • Yes, I thought about it, but I can't see something that would really fix the problem. We agree that abbr=~ is peculiar and uninformative. Perhaps abbr=intro is an improvement, but I think it would still be puzzling to people looking at the wikitext, so it's not a perfect solution. The code calls it "also symbol", but as mentioned, I don't like long options such as abbr=name and symbol or abbr=also symbol, and abbr=+sym or abbr=namsym are too weird. On principle I think we should avoid adding an option which seems to be merely better because if someone got used to it, we would cause trouble if we ever find a "perfect" solution (like when we decided to use order=flip). I don't oppose adding intro, but I'm not sure we should. Anyone want to offer an opinion? Johnuniq (talk) 02:49, 6 December 2014 (UTC)

1. Only just read that you have postponed these topics, not denied. OK. No hurry then.

Postpone, we have time

2. Indeed, no long (spaced!) option names, nor uncommon code-like shortcuts. 3. I respectfully disagree about "let's skip Better until we have Perfect". Simple: if a more dedicated solution would occur, the habit must change whatever. So it's a change needed from |abbr=~ too; the problem is there already. 4. An editor looking in wikicode seeing "|abbr=intro" is more puzzled then when seeing "|abbr=~"? 5. If you have plans to make it a dedicated parameter as you suggest, please tell us. -DePiep (talk) 10:28, 6 December 2014 (UTC)

(I fold & postpone, to reduce time pressure this might introduce). -DePiep (talk) 18:01, 7 December 2014 (UTC)

Crop yields

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

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

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

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

Odd lack of pluralisation – bug?

I recently discovered that some combinations of options can produce singular unit names in contexts where that is not appropriate. For example, {{convert|600|mi|km|order=flip|sigfig=1}} produces this output: "1,000 kilometres (600 mi)" (it should obviously read "1,000 kilometres"). But if I change the unit order manually to {{convert|1000|km|mi|sigfig=1}} then it's fine: 1,000 kilometres (600 mi). Archon 2488 (talk) 14:20, 24 November 2014 (UTC)

Archon 2488, the funny quirk is that {{convert|600|mi|km|order=flip|sigfig=1|adj=1}} fixes it, but shouldn't really do anything in this case since the values are greater than 1. Frietjes (talk) 21:31, 24 November 2014 (UTC)

Interesting bug—this is the first example of broken code that I recall so thanks for reporting the problem. It occurs when the output is not abbreviated and sigfig causes the value to sort-of overflow. These examples use foot/feet to show it is nothing to do with km:

• {{convert|999|ft|ft|abbr=off|-1}} → 999 feet (1,000 feet) [good: output is plural "feet"]
• {{convert|999|ft|ft|abbr=off|sigfig=2}} → 999 feet (1,000 feet) [good: output is plural "feet"]
• {{convert|999|ft|ft|abbr=off|sigfig=1}} → 999 feet (1,000 feet) [bad: output is singular "foot"]

I'll have to examine the history of the code that determines whether the value is singular/plural because at the moment I can't see how it would ever work with sigfig. I'll slowly ponder that soon. Using adj=1 forces different code to be used; that code uses the singular unit name when the value v satisfies:

(−1 <= v and v < 0) or (0 < v and v <= 1)

The adj=1 code works independently of sigfig so it does not suffer from the bug. The standard code (when adj=1 is not used) inspects the rounded output and only regards "1" or values like "1.00" to be singular. The bug occurs with sigfig because it regards "1000" as "1" with an exponent, and stupidly uses the "1" to conclude it is singular. Johnuniq (talk) 01:36, 25 November 2014 (UTC)

While examining the code, I see it is also possible to trigger the bug like this:

• {{convert|9|ft|ft|abbr=off|-1}} → 9 feet (10 feet) [bad: output is singular "foot"]

The cause is exactly as described above—this unusual rounding also gives a result regarded as "1" with an exponent. The fix is easy but I'll take a while pondering it. Johnuniq (talk) 06:39, 25 November 2014 (UTC)

Singular bug fixes

I found another problem with how singular unit names work with output fractions and have put fixes for all the problems in the sandbox. I also implemented a change suggested by Jimp at #What happened with abbr=~ ? above (where I will put an example). Examples of the singular/plural issue follow (these use the live convert and convert/sandbox templates and so will change when the modules change). The example using 1+1/2 is just to show that "feet" is used when fraction > 1 (same for old and new code).

Convert	convert output	convert/sandbox output
{{convert|1/2|ft|ft|frac=2|abbr=off}}	1⁄2 foot (1⁄2 foot)	1⁄2 foot (1⁄2 foot)
{{convert|1/2|mi|mi|abbr=off|frac=2|spell=on}}	one-half mile (one-half mile)	one-half mile (one-half mile)
{{convert|1+1/2|ft|ft|abbr=off|frac=2}}	1+1⁄2 feet (1+1⁄2 feet)	1+1⁄2 feet (1+1⁄2 feet)
{{convert|999|ft|ft|abbr=off|sigfig=1}}	999 feet (1,000 feet)	999 feet (1,000 feet)
{{convert|9|ft|ft|abbr=off|-1}}	9 feet (10 feet)	9 feet (10 feet)
{{convert|1.0|ft|ft|abbr=off|sigfig=2}}	1.0 foot (1.0 foot)	1.0 foot (1.0 foot)

@Jimp: Is there a reason that −1 uses a plural name while 1 uses singular? The question is purely academic because I don't think the issue arises, however it may as well be fixed, if wanted. The following shows what convert (and convert/sandbox) do:

• {{convert|1|ft|ft|abbr=off}} → 1 foot (1.0 foot) (singular foot)
• {{convert|-1|ft|ft|abbr=off}} → −1 foot (−1.0 foot) (plural feet)

Around 2000 converts in articles use negative temperatures (where singular/plural does not arise because symbols are used), and another 400 use negative values with other units. That's more than I expected, but none of them involve −1 with a unit name so the issue does not matter. However, should the module be changed so the second example above uses "foot" for input and output? Johnuniq (talk) 03:14, 1 December 2014 (UTC)

I can't think of any good reason fort −1 to use a plural name. It must be an error. Jimp 22:22, 2 December 2014 (UTC)

Singular by unit name

I ran into these examples:

• {{convert|2|foot|m}} → 2 foot (0.61 m) -- ? Singular by input name
• {{convert|2|feet|m}} → 2 feet (0.61 m)
• {{convert|2|ft|m}} → 2 feet (0.61 m)

• {{convert|2|metre|cm}} → 2 metres (200 cm) -- Into plural
• {{convert|2|metres|cm}} → 2 metres (200 cm)
• {{convert|2|m|cm}} → 2 metres (200 cm)

The first example appears to be singular because of the input name only ('foot' is singular). This may be a feature not a bug (and so we better document it). But I find it unexpected, and does not work consistently seeing the metre demo. I remember we discussed this earlier this year, but I thought I'd mention it. Especially since I really was wrongfeeted when writing about these plurals in HELP:Convert. -DePiep (talk) 07:45, 2 December 2014 (UTC)

The foot unit is specifically intended to give "foot" as the plural name. I forget where I saw it mentioned, but apparently there are situations where that usage is followed. There are several other "foot" units where the same rule applies, examples: board foot and cufoot and foot/s. There are hundreds of converts using these, although it is hard to know if they are intentional (perhaps an editor used "foot" without realizing what it would do). Johnuniq (talk) 09:28, 2 December 2014 (UTC)

So there is a grammatical background for this? To cover intentional/unintentional use (as I ran in to), the singular form better be covered by |adj=1. Reduce exceptions in documentation. -DePiep (talk) 09:37, 2 December 2014 (UTC)

These were introduced (as Johnuniq mentions) to handle the fact that some use "foot" as a plural. This is a different situation to what |adj=1 was introduced for. There are a couple of problems with using |adj=1 here.

• |adj=1 applies to all units (input and output).
• |adj=1 only applies to number between −1 and +1.
• |adj=1 contravenes MOSNUM and should be ditched.

Jimp 22:13, 2 December 2014 (UTC)

So, let me check:

1. In the outside world, "foot" can be used as plural (equal to: "feet")
2. This is correct by English language
3. This is correct for writing measurements
4. This is valid for all English variants (ENGVAR: en-US, en-GB, ...)
5. There is no restriction (like: when sourced only, or in era X–Y only)
6. This wiki accepts that as being correct (though not written in a MOS)
7. {{convert}} uses the word spelling 'foot' to implement this

-DePiep (talk)

Deprecation of adj=1

|adj=1 makes the unit name singular when number is 1 or less, but not zero. This is in conflict with MOSNUM which states "Nouns following simple fractions are singular ... Nouns following mixed numbers are plural ... Nouns following a number expressed as a decimal are plural". Let's deprecate it and get rid of it. Jimp 03:24, 3 December 2014 (UTC)

Deprecate. I understand that the applicable MOS-prescription can be derived from the actual number, in a complete algorithm. No need for manual exceptions then. -DePiep (talk) 11:11, 3 December 2014 (UTC)

Will change documentation after a Johnuniq response on this. -DePiep (talk) 12:35, 5 December 2014 (UTC)

Looking at the converts used in May 2014, there are only four places where omitting adj=1 would make a difference. In each of the following, omitting adj=1 would make the input unit plural:

• Hunter Mountain (New York) {{convert|0.5|mi|km|1|adj=1}}: Eventually, 0.5 mile (0.8 km) from the trailhead
• Thunderstorm {{convert|0.5|in|mm|adj=1}}: When hail stones exceed 0.5 inch (13 mm) in diameter
• Balsam Lake Mountain Fire Observation Station {{convert|0.1|mi|km|adj=1}}: to a junction with the Balsam Lake Mountain Trail 0.1 mile (0.16 km) south of the fire tower
• Red Hill Fire Observation Station {{convert|0.3|mi|km|adj=1}}: about 0.3 mile (0.48 km) from the tower via a short path

I'm inclined to think that singular is correct in the first two converts, although a justification would be difficult. The second two probably should be plural. I guess that means I'm sitting on the fence again. However, deprecation is fine as (last May) it was only needed twice out of 1.8 million converts, and now that I look again, perhaps the first two would be fine with plural. Johnuniq (talk) 03:11, 6 December 2014 (UTC)

How do I put (the same) text before both input and output units?

Is there a way to put the adjective before both the input and output units?

e.g. {{convert|3.5|ha|acre|million|adj=pre}} produces:

3.5 million hectares (8.6 acres)

Which is patently not the right conversion. I of course want:

3.5 million hectares (8.6 million acres)

(I realise this is a little contrived but there are real examples when I want to do similar things, and this is a simple example of the general problem.)

It was probably not a good idea to shoehorn this "add arbitrary text" feature into the adj= parameter; but we have what we have (and I for one am glad that we have it and use it a lot, bless all who sail with her: if this is any recommendation, when I translate articles from other Wikipedias that are in metric, I can totally rely on convert giving me the right answer and all I ever need to do is knock the precision or something trivial like that to make it read nicer). Si Trew (talk) 15:55, 4 December 2014 (UTC)

I tried adj=both but that didn't work. It would be cool if it did, though. Si Trew (talk) 16:10, 4 December 2014 (UTC)

A problem you introduce is that part of the number is turned into an (ineffective) word. "million" has a meaning in the measurement (to compare: use "cultivated" hectare). This next one would keep the maths right, but does no allow you to control-format the result:

{{convert|3.5|e6ha|e6acre}} → 3.5 million hectares (8.6×10^⁶ acres)

-DePiep (talk) 16:16, 4 December 2014 (UTC)

Nice to see you DePiep.

Oh I'm "introducing" problems ? I was trying to solve them! :) (Or rather, moan about them and let someone else solve them...)

But I don't want engineering units of ten to the power of six. Yes, I understand those. Yes, they make no sense in a general article: I want "million".

Take your example "cultivated": I might still want "cultivated hectares" and "cultivated acres", to be absolutely clear that I am not talking about cultivated hectares but then about run-to-seed (or general-purpose) acres, but a specific kind of acre. As it stands, I rescan the sentence to "he cultivated {{convert|whatever|acres}}", but that is not quite the same thing if the "cultivated hectare" or "cultivated acre" is a well-known unit of measure in the field of cultivation.

This is not the same kind of qualifier as "long ton" or a "light year" where these are just compound adjectives for the units and are inseparable words (in many languages they would be just one word, I would argue they are one word that happens to have a space in the middle, but that's a linguistic argument).

Let's pretend that a banana ton is the weight/mass of a crate of bananas, including the weight of the crate but minus the monkey. A banana pound, banana kilo etc are defined with the ratios to the SI kilo, etc. So there is no point in us generating a whole series of banana unit conversions when we can prefix each with "banana" to mean "add crate, remove monkey, whichever unit you use". It is not so much "ineffective" but "descriptive", and presumably we could link (in the descriptive text where "million" goes above) [[Banana units of measurement|Banana]] which would describe how a banana ton differed from a ton or tonne.

It just seems like Occam's razor not to have to clutter {{convert}} with these kind of derived "descriptive" units, which are very common. Si Trew (talk) 16:54, 4 December 2014 (UTC)

1. With "ineffective" I meant to say "has no effect on the measurement value" (as "cultivated" has not). 2. You can define a "banana ton" that way, but are we supposed & allowed to convert that to "banana stone", as if that one is defined? 3. Within SI, the rule is: don't alter the value (number nor unit) with qualifiers, but add it to the quantity: "Weight_{banana Trew's way without Trew's pet monkey} = x ton (y stone)". 4. A "million hectare" is still not equal to "Trew's hectare_{without the monkey}", for the number/definition difference. 5. think the issue is not within {{convert}} per se, but what you intend to write even without {convert}. Nothing of this all answers your question. -DePiep (talk) 17:19, 4 December 2014 (UTC) (don't edit this post. -DePiep (talk) 12:14, 5 December 2014 (UTC))

Excuse me for putting my answers inline, hope that is OK with you. No, I don't think it does answer it. I hope you take it as a compliment that I rarely come here now because convert does a great job. I have not put this tiny niggle I have with it very well, but I think it is easily fixed if I could express myself better. Si Trew (talk) 17:38, 4 December 2014 (UTC)

Inline answering didn't work so here goes:

1. Fair enough, I agree with that.
2. Deliberately I made up a definition. There are others in real life but I have terrible trouble finding examples when I need them. You have to take my word for it, it crops up a lot.
3. Wikipedia is not SI. It depends. If the article is technical, sure, SI units and so on are the way to go: in a general purpose article that is not metrological or scientific, to put it in "human" units is more important. Sometimes I say "about a kilometre, or half a mile", for that reason. You and I both know that a statute mile is 1609 metres by definition, but it doesn't help to say so.
4. No idea what you mean here. I want a million Trew's hectares (banana hectares), and a million Trew's acres, to be in the same ratio as an SI hectare to an SI-derived acre.
5. It's difficult to give a concrete example, because I rescan the sentences to avoid jumping out of the frying pan, into the fire, as Fowler has it (odd that it is not mentioned there; I may add it; if nothing else some good has come of this!)

Si Trew (talk) 17:51, 4 December 2014 (UTC)

Rather than adding a |adj=both, perhaps |adj=pre should be deprecated and |prefix= & |suffix= added? -- WOSlinker (talk) 18:57, 4 December 2014 (UTC)

The documentation for this is at Help:Convert#Extra words. DePiep had it right, but you want abbreviation off.

• {{convert|3.5|ha|acre|disp=preunit| cultivated |banana }} → 3.5 cultivated hectares (8.6 banana acres)
• {{convert|3.5|e6ha|e6acre|abbr=off}} → 3.5 million hectares (8.6 million acres)

Johnuniq (talk) 21:46, 4 December 2014 (UTC)

Module version 7

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

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

The changes are:

• Singular/plural names: Fix bug generating correct name when abbreviation is off with certain rounding that gives a value which the code regards as 1 times a power of ten, per discussion above.
• Singular/plural names: Remove some compatibility with the old templates in order to give more consistent results. For example, −1 (as well as 1) is now regarded as singular, and the "use name" units such as acre do not have unusual exceptions to the singular/plural rules.
• Show input unit name and symbol (abbr=~): Give a result more consistent with WP:UNIT, although convert uses square brackets (that could be reconsidered after we try the new code for a while), per discussion above.
• Change html generated by disp=table and disp=tablecen per Module talk:Convert#Obsolete HTML (permalink).

Module version history

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

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

Convert	Version 6 output	Version 7 output
{{convert|1/2|ft|ft|frac=2|abbr=off}}	1⁄2 foot (1⁄2 feet)	1⁄2 foot (1⁄2 foot)
{{convert|1/2|mi|mi|abbr=off|frac=2|spell=on}}	one-half mile (one-half miles)	one-half mile (one-half mile)
{{convert|999|ft|ft|abbr=off|sigfig=1}}	999 feet (1,000 foot)	999 feet (1,000 feet)
{{convert|9|ft|ft|abbr=off|-1}}	9 feet (10 foot)	9 feet (10 feet)
{{convert|1.0|ft|ft|abbr=off|sigfig=2}}	1.0 foot (1.0 feet)	1.0 foot (1.0 foot)
{{convert|0|sqyd|acre}}	0 square yards (0 acre)	0 square yards (0 acres)
{{convert|-1|acre|sqyd|abbr=out}}	−1 acres (−4,800 sq yd)	−1 acre (−4,800 sq yd)
{{convert|0.1|ha|acre}}	0.1 hectares (0.25 acre)	0.1 hectares (0.25 acres)
{{convert|1.04|m|ft|2|abbr=~|sp=us}}	1.04 meters (m, 3.41 ft)	1.04 meters [m] (3.41 ft)
{{convert|9|kPa|abbr=~}}	9 kilopascals (kPa, 1.3 psi)	9 kilopascals [kPa] (1.3 psi)
{{convert|9|kPa|disp=sqbr|abbr=~}}	9 kilopascals [kPa, 1.3 psi]	9 kilopascals [kPa] [1.3 psi]
{{convert|2.3|MeV|abbr=~}}	2.3 megaelectronvolts (MeV, 0.37 pJ)	2.3 megaelectronvolts [MeV] (0.37 pJ)
{{convert|12|m|ft|disp=table}}	align="right"|12 |align="right"|39	style="text-align: right;"|12 |style="text-align: right;"|39
{{convert|12|m|ft|disp=tablecen}}	align="center"|12 |align="center"|39	style="text-align: center;"|12 |style="text-align: center;"|39

I was hoping to do something about a couple of other recently discussed issues, but it looks like they will have to wait. Please speak up if you think there is a problem! Johnuniq (talk) 03:50, 5 December 2014 (UTC)

• Done: The module has been updated. Johnuniq (talk) 06:01, 10 December 2014 (UTC)

Formatting of deprecated examples

I recently made a series of edits to some of the templates which are transcluded in the documentation to adjust the formatting of deprecated options from the {{!xt}} template (red serif text) reserved for incorrect examples of style to the {{xtd}} template (grey serif text) reserved for deprecated examples; I then tried the {{bxtd}} template (boldface grey text) to avoid the serif font which obscures the <code> mono-spaced formatting. I have subsequently created {{mxtd}} (mono-spaced grey text) and then found {{deprecated code}} (grey text with hidden <del> markup and optional red formatting).

DePiep reverted my changes and helpfully explained why on my talk page. I explained my position but have not received a reply there, so I thought I would open it up to wider discussion here.

By way of comparison, I present these various formatting options below:

Wikitext	Renders as	Notes
{{!xt|1=abbr=comma}}	abbr=comma	Current formatting
{{xtd|1=abbr=comma}}	abbr=comma
{{bxtd|1=abbr=comma}}	abbr=comma
{{mxtd|1=abbr=comma}}	abbr=comma
{{dc|1=abbr=comma}}	abbr=comma
{{dc2|1=abbr=comma}}	abbr=comma
{{dcr|1=abbr=comma}}	abbr=comma	My proposed format

Of these, I propose that the {{dcr}} template is the neatest and correct format as it: (1) renders in red; (2) preserves mono-spaced formatting; (3) uses the correct <del> markup intended for deprecated text (although the strikethrough is hidden, it helps for accessibility reasons).

Similarly, it seems that the {{xt}} template (green serif text) is inappropriate and unnecessary and should simply use <code> formatting to indicate correct options, as with the rest of the documentation. For example:

abbr=comma, adj=nocomma, disp=nocomma are deprecated. Use comma=off instead

—sroc 💬 00:28, 8 December 2014 (UTC)

First response: no; Red/green says it all. I'll be back for a 2nd impression. (I really don't know what grey font means, and I can't ever read it as a significance). -DePiep (talk) 00:33, 8 December 2014 (UTC)

I admit: a second, better reading is needed. DePiep (talk) 00:41, 8 December 2014 (UTC)

See here for how this would look. Simple: red means no, default colour means yes. (Note: for accessibility reasons, colour alone should not be used to convey meaning, per WP:COLOR.) —sroc 💬 00:47, 8 December 2014 (UTC)

Please stop. The {{convert/doc}} and Help:Convert are build up by serious and consistent background. If you want to promote any other version, do so from a /sandbox version. -DePiep (talk) 00:59, 8 December 2014 (UTC)

Sorry, I won't persist while the discussion continues, but please engage in the issue on the merits, not I don't like it reasoning. —sroc 💬 01:25, 8 December 2014 (UTC)

"I admit: a second, better reading is needed." I'm not sure what you mean. Do you have any objections to the proposed formatting? If so, why? —sroc 💬 01:27, 8 December 2014 (UTC)

Convert and its documentation are big and complex, so let's proceed slowly. I'll try to examine the issue and offer some opinions later, but we're not talking about fixing a WP:BLP violation so let's take due time. Johnuniq (talk) 01:54, 8 December 2014 (UTC)

Yes, of course, there's no need to rush, but remember this is only a proposed change in formatting the documentation to use the appropriate templates, not substantive changes to the text nor any change to the operation of {{convert}} itself. —sroc 💬 02:17, 8 December 2014 (UTC)

re, short. The old version is OK to me. For changes: convince me. The red/green diff supports MOS page style (the way MOS is written). Using grey font or bold font for deprecated options I bark against. {convert} documentation is build up well and consistently. -DePiep (talk) 01:24, 9 December 2014 (UTC)

At the moment I'm just trying to document the issue because I have not paid any attention to the convert documentation for a long time as DePiep handles all that. The proposed edits are to three documentation templates:

• Template:Convert/doc/deprecations list (edit | talk | history | links | watch | logs) • proposal
• Template:Convert/doc/parameter list (edit | talk | history | links | watch | logs) • proposal
• Template:Convert/doc/range separator list (edit | talk | history | links | watch | logs) • proposal

Currently, each of the above is as it was prior to Sroc's edits. The first seems to involve using <code> and {{dcr}} and removing two MOS links (while leaving one). The second and third involve changing {{!xt}} → {{bxtd}} and {{xt}} → {{mxt}}.

These documentation templates are used at:

• Template:Convert/doc
• Help:Convert

The first of these uses them like this:

==Ranges of values==
...
{{Convert/doc/range separator list}}

==Parameter list==
{{convert/doc/parameter list}}

==Deprecated options==
{{Convert/doc/deprecations list}}

My first impression is that the issue is not sufficiently important to fuss over. DePiep is maintaining the documentation, so unless there is a significant problem it would be best to leave it to him. The only firm opinion I have other than that is that the gray coloring is too subtle to show a deprecated option, particularly when the list is sorted. Re the MOS links: it is overlinking, but I guess DePiep's reasoning is that someone would be looking for a specific option (perhaps by searching the page), rather than reading it through, so a link on the line of interest might be valuable. We could debate that but it does not seem important.

I have not examined the convert documentation for quite a while, but on skimming it now the only thing that I noticed was that {{navbox convert}} perhaps should have "(area ∙ energy ... volume)" moved so it does not appear after "Full list of units" because as it is, the "area" link should show the full list of units for area. Johnuniq (talk) 02:41, 9 December 2014 (UTC)

Do not misrepresent me: I'm no longer proposing grey or bold fonts. I propose the use of {{dcr}} for deprecated options, which renders as plain red text. This is appropriate for several reasons:

1. It renders in red to indicate "wrong" (although colour should not be "the only method used to convey important information" and the fact that options are deprecated are indicated by the text in any case);
2. When used with <code>, it preserves mono-spaced formatting (like this) as used for code, rather than substituting a serif font (like this), which is inconsistent with the formatting used for code throughout the documentation;
3. It uses the correct <del> markup intended for deprecated text (although the strikethrough is hidden), so the documentation is correctly formatted for accessibility reasons.
4. The {{xt}} and {{!xt}} templates are the wrong templates to use in this instance, as they are intended for examples, not code or template parameters. The documentation for those templates states:

   For cases where the serif typeface is not desirable (e.g. in blocks of computer code), use {{bxt}}, which substitutes boldfacing, or {{mxt}}, which substitutes a mono-spaced font.

   However, the documentation also explicitly states:

   The {{xtd}} template exists for deprecated examples. Its alias {{xtg}} (for "grey") can be used to indicate uncertain, unavailable, disabled, lorem, etc., examples without implying deprecation. The bold, sans-serif equivalent is {{bxtd}} (and {{bxtg}} alias). The mono-spaced equivalent is {{mxtd}}.

   So you are, in fact, advocating to maintain templates which are considered incorrect within their own documentation.

Other than a vague sense of "red, bad; green, good", what is your reasoning to buck the correct formatting? —sroc 💬 04:18, 9 December 2014 (UTC)

Quick & short: not only do did I rewrite the documentations, I did that with a coherent philosophy (ongoing). For the reader (that is: the editor who is using {{convert}} at that moment), the documentation should be crisp. As I wrote it, the deprecations follow MOS-style (style in which MOS is written. red=bad, green=good). I do not see any problem with that, and I don't know what is "vague" about that. Next, I did not make the "color only" error: in b/w print the text (sentence) says the same. My aim is to get the documentation right for the editor. (In detail: I can not accept the !-less template name(s), because I can not memorize it). I think the solution you are looking for is: class=deprecated. -DePiep (talk) 22:54, 9 December 2014 (UTC)

Does MOS actually state to use {{xt}} (green is good) and {{!xt}} (red is bad), or is it only by convention? More particularly, are these templates expressly advocated for use in code, and if so, why do the other template variations exist?

Why are you adamant that these templates using serif fonts should be used for code which is ordinarily presented in mono-spaced font? "I can not accept the !-less template name(s), because I can not memorize it" seems lazy ({{dcr}} is only three letters standing for "deprecated code red") and, more troublingly, a symptom of WP:OWN and WP:IDONTLIKEIT, neither of which justifies using the correct formatting. With all due respect for the work that you have done, that should not mean that others cannot question why things are the way you have done them. —sroc 💬 10:03, 10 December 2014 (UTC)

Don't know about MOS-about-MOS guidelines. I use them because of that convention, as I want to convey the same thing as MOS conveys. With this, I have don't need to contemplate why other templates exist.

Parameter switches making an alphabet soup don't work (with me, and in general), because the abbreviation is arbitrary and it mixes format & semantic (font & 'deprecated') meaning. It is not a memorisable setup. (I have made thousands of edits in template discussions, and I still do not know the list that should be clarified in {{tl/doc}}; for these reasons).

I note that you have not presented an alternative for the green=good format (you write it plain b/w). Leaving the red/green & bad/good juxtaposition does not help the reader IMO. Must say, since we write parameter names & options in <code> often, I assume the red/green values should strive to do that too. (In this, {{dcr}} is an improvement versus {{!xt}}).

As I said, there could be a class for such deprecated parameters (<del> means deprecated?). Still, I'd expect a helpful format with that. I don't expect an improvement for the documentation when using class only. -DePiep (talk) 14:41, 11 December 2014 (UTC)

Adding: If I understand it well, <del> tag is meant for deleted text (usually shown stricken). I'm not sure this is what we want to say in these {{convert}} deprecations; MOS-emulation looks better to me. -DePiep (talk) 14:46, 11 December 2014 (UTC)

Thanks for clarifying that when you referred to red/green being "MOS-style" you were not indicating that these are actually advocated by MOS for use throughout Wikipedia but rather that they are used for examples in MOS. Because {{xt}} and {{!xt}} are intended for example text (say this, not that) and they do not respect the monospaced fonts given by <code>, they are neither applicable nor ideal for use in code.

You accept that {{dcr}} is an improvement over {{!xt}} for use in deprecated parameters. I have not proposed a specific alternative for the {{xt}} format precisely because none is needed: the correct options should simply be given by plain <code> formatting just as they are throughout the documentation. What could be simpler or more intuitive than using the same format already used throughout the documentation? We don't need to pander to users by not only saying "abbr=commais deprecated, use comma=off instead" but having to put the correct version in green (as if to imply they cannot understand the words "use... instead"). Once again, it is necessary to use words to indicate where an option is deprecated rather than relying on colour alone, so it is redundant to insist on green being used in this instance where additional markup (that is, in addition to <code>) is not required. (Colours and serif fonts are used by the {{xt}} template to set it apart from the surrounding text; this is unnecessary when <code> already uses colours and fonts, and adding more colour/font combinations is unwieldy.)

I don't understand why you would suggest using a class to mark deprecated examples (and having to remember all of the code that goes with it) instead of simply using one of the templates provided for the specific purpose. For one thing, using templates makes it easier to update formatting uniformly in the future when required; having rogue classes is not as easy to deal with and, I dare say, would not be as easy for other contributors to use as templates. (By the way, the templates often mark formatted text with specific classes, which allows users to customise their appearance using CSS; using classes unexpectedly instead of using the proper templates for their intended purpose may have unintended consequences and undermine users' ability to control formatting on their screen.) —sroc 💬 15:25, 11 December 2014 (UTC)

Proposed new units

Richie765 has added several new units to Module:Convert/data/sandbox and Module:Convert/documentation/conversion data/doc. New units:

• ls : light-second
• lm : light-minute
• lh : light-hour
• ld : light-day
• lw : light-week
• m/year : metre per year
• km/year : kilometre per year

New aliases:

• m/y = m/year
• m/yr = m/year
• km/y = km/year
• km/yr = km/year

There are currently 680 units plus 420 aliases (many of which are unused) and I think we should proceed slowly before adding more. Is there a need to convert the above units? In which articles? There are hundreds of units that could be added, but I think we should stick to units that will be used. The quick way to add a unit that will be used now is in Module:Convert/extra (but please only add units that are needed). Johnuniq (talk) 01:48, 8 December 2014 (UTC)

As you write, Jonuniq: only when used. I don't see any mentioning of these in light-year. -DePiep (talk) 11:54, 8 December 2014 (UTC)

Light seconds are often used in relativity theory as the basic unit of distance because they make the speed of light numerically equal to 1. The others are probably very uncommon.GliderMaven (talk) 17:00, 8 December 2014 (UTC)

That makes sense but it sounds unlikely that convert would be useful. Unless something firm clarifies, I'll remove these when I next update the modules. Johnuniq (talk) 01:40, 9 December 2014 (UTC)

• Done: I removed the proposed changes. Johnuniq (talk) 06:00, 10 December 2014 (UTC)