Template talk:Convert/Archive February 2018

Power

In Module:Convert/data, local per_unit_fixups contains ["energy/time"] = { utype = "power", link = "Power" }. This creates links to a disambiguation page, such as the examples on Energen. The link should probably be changed to Power (physics). Certes (talk) 01:54, 31 January 2018 (UTC)

Thanks. I fixed that at Module:Convert/documentation/conversion data/doc#Automatic per units and it will be included in the next version, although that won't occur for quite a while. Johnuniq (talk) 00:14, 1 February 2018 (UTC)

Thanks for the link. From there I see Gradient should be Grade (slope), and we could add links such as Concentration and Linear density.

With apologies for straying off-topic, I'm a bit confused by the "next version...quite a while" comment. Do editors working in the module namespace bundle changes into releases? Modules are more powerful and legible than templates, but if we've abandoned the wiki philosophy and moved on to a software development life cycle then that's something to consider before using templates that require modules. Certes (talk) 01:11, 1 February 2018 (UTC)

Agreed, it's a problem. On the other hand, when the 4,000 templates previously used were active, this talk page saw frequent error reports. Comparatively, things are quiet now. I've been wondering how many links are broken because hundreds of units are defined and I don't think their links have been systematically examined for a long time. I'll make one of the modules output a list of unique links and will post here possibly in a few hours when done. Johnuniq (talk) 01:29, 1 February 2018 (UTC)

A few of the units appear odd. For example, Energen reports in GJ/ks. I'm not sure whether this is industry standard terminology or just a clumsy way of saying "megawatt". Certes (talk) 01:48, 1 February 2018 (UTC)

That is because the unit e3BOE/d is not defined, so convert generates the unit automatically as energy/time (power). For units like that, the convert template should be told what output unit to use rather than relying on the automatic default. Johnuniq (talk) 02:50, 1 February 2018 (UTC)

Thanks, that's a useful tip. In this case I'm no subject expert so I'll leave that change to an editor who knows the industry. I just came to Energen to fix links to dabs, found no obviously wrong wikitext such as [[Power]], and started digging in templates and Lua to find the cause. A current debate at VPP may provide some ideas, though this module is not guilty of the exact behaviour discussed there. Certes (talk) 10:26, 1 February 2018 (UTC)

• From the /doc#Automatic per units page:

Redlinks

sq ft/acre Square foot per acre

cal/g Calorie per gram

kcal/g Kilocalorie per gram

U.S. gal/d U.S. gallon per day

US gal/a US gallon per day -- should be US gallons per year

US gal/d US gallon per day

To a DAB page

kcal/kg Kilojoule per kilogram

dog yr Dog year

~firkin Firkin

I have a gadget working that shows links to a DAB page in orange ;-). -DePiep (talk) 02:08, 1 February 2018 (UTC)

Thanks. I just did something clever at Module:Convert/extra to fix Energen which currently has links to the dab page power. However, convert outsmarted me. I defined unit BOE/d but the code which handles e3BOE/d (which generates the attractive "thousand") uses the "automatic per unit" feature which still has the broken link. I'll ponder that later but will switch my attention to creating a page of links for a final check. Then they can all be fixed. If desperate, I would put the fixes in the sandbox then temporarily use {{convert/sandbox}} in Energen. Johnuniq (talk) 02:50, 1 February 2018 (UTC)

Those red links are a puzzle. For example, Square foot per acre and Calorie per gram were present in April 2013, and that's before the module was first used in December 2013. I forget what happened. Perhaps there was a plan to create the red links as redirects? Johnuniq (talk) 03:06, 1 February 2018 (UTC)

Re Do editors working in the module namespace bundle changes into releases?, yes, some people do this, such as Trappist the monk (talk · contribs) - see for instance Help talk:Citation Style 1 and Template talk:Lang. I won't pick out specific threads because there are rather a lot. --Redrose64 🌹 (talk) 10:28, 1 February 2018 (UTC)

In the days when Module:Citation/CS1 was rapidly changing, we were chastised for rapid-fire tweaks to the live module because every little change dumped millions of articles onto the MediaWiki job queue so we switched to sandboxing and bundled change updates. This has the benefit of allowing interested editors to experiment with changes before they go live. As far as I know there is no 'policy' the prescribes bundling changes for modules with very high transclusion counts but, it seems to me to be good practice. Maintainers of Module:convert may have a different philosophy.

—Trappist the monk (talk) 10:58, 1 February 2018 (UTC)

See Module talk:Convert/show for a list of unique links for units. It's not totally unique because, for example, it includes both Calorie and calorie. I left it at that because due to the way convert handles links, sometimes a link starts with an uppercase letter, and sometimes it doesn't, for example:

{{convert|1|cal|lk=in}}  → 1 [[calorie]] (4.2 J)
{{convert|1|kcal|lk=in}} → 1 [[Calorie|kilocalorie]] (4.2 kJ)

The list of links is not very helpful but I'll try to look through it later and see if the links make sense. Any thoughts about what to do with the problems DePiep noted above? Johnuniq (talk) 04:46, 2 February 2018 (UTC)

Convert in TFA

Sometimes, {{Convert}} is used in a WP:TFA. (Today: Plunketts Creek (Loyalsock Creek tributary), blurb). I just made this {{Convert}} edit to the article. Should we organise a patrol posse ;-) to improve {{Convert}} usage in TFA and Main page? - DePiep (talk) 20:20, 3 February 2018 (UTC)

Is it normal for the main page TFA blurb to be amended following an article edit? --Redrose64 🌹 (talk) 21:59, 3 February 2018 (UTC)

In this particular case, I'd like to see some discussion before making an edit to the current TFA ... and it will be off the Main Page in about 90 minutes. - Dank (push to talk) 22:27, 3 February 2018 (UTC)

Yes. My point is: how can we {{Convert}} (talk) loving editors help TFA (and main page in general). -DePiep (talk) 22:35, 3 February 2018 (UTC)

re Redrose64: yes, TFA blurb follows FA article (esp. its lede). -DePiep (talk) 23:10, 3 February 2018 (UTC)

In the days leading up to the main page appearance, yes I have noticed this. But I thought that once it had appeared on the main page, it was inviolate (apart from legal matters, which will of course have been eliminated from the article a long time earlier). --Redrose64 🌹 (talk) 23:36, 3 February 2018 (UTC)

Alltogether: TFA can & does take care of itself. (close) -DePiep (talk) 01:34, 8 February 2018 (UTC)

adding hyphen to adjectival distance conversion

Hello all- I'm wondering if there's a way to make the distance conversion template, with adj=on, render the conversion result in the adjectival form as it does the "original" distance. For example, I would like to see the following render with 27-km instead of without the hyphen: The 17-mile (27 km) race is one of the most popular fun runs in Switzerland. I don't know how to get into the guts of the template code. Any ideas? Thanks in advance. Eric ^talk 17:54, 8 February 2018 (UTC)

While convert tries to do what editors want, its primary role is to provide uniform WP:MOS styling. MOS:HYPHEN includes the example: Incorrect: 9-mm gap. Convert inserts hyphens when units are not abbreviated in accordance with that guide:

• {{convert|17|mi|adj=on}} → 17-mile (27 km)
• {{convert|17|mi|adj=on|abbr=off}} → 17-mile (27-kilometre)

Johnuniq (talk) 21:41, 8 February 2018 (UTC)

Thanks, Johnuniq. I'd never visited that corner of the MOS before. Eric ^talk 23:42, 8 February 2018 (UTC)

For additional info, SI (SI brochure 8th edition, §5.3.3) mandates no hyphen when symbols rather than names are used, even when it is adjectivally used. So the MoS is not alone in this. —Quondum 03:04, 9 February 2018 (UTC)

Unit links

This is a follow-up from #Power above reported by Certes. I have checked all the links at Module talk:Convert/show. The following unit links need to be fixed.

The master list of units is Module:Convert/documentation/conversion data/doc.

Resolved (red links): Redirects created to remove the red links.

Unit	Link	Should be
cal/g	Calorie per gram	Unchanged, redirect to Food energy
kcal/g	Kilocalorie per gram	Unchanged, redirect to Food energy
sqft/acre	Square foot per acre	Basal area (link for m2/ha used at Angle gauge)
U.S.gal/d	U.S. gallon per day	Unchanged, redirect to Volumetric flow rate
USgal/a	US gallon per day	US gallon per year, redirect to Volumetric flow rate
USgal/d	US gallon per day	Unchanged, redirect to Volumetric flow rate

Resolved (redirects): I propose the following changes. It might be better for ft/min to have link Feet per minute, but that is a redirect to Surface feet per minute and there is no great alternative. The unit ft/min is used in articles but never linked so I think it can be left as follows. I don't mind about ft/min + ft/s but propose "feet per second" rather than the formally correct title of foot per second. Johnuniq (talk) 07:00, 7 February 2018 (UTC)

Unit	Link	Redirects to	Should be
A.h	Ampere-hour	Ampere hour	Redirect target
Å	Angstrom	Ångström	Redirect target
viss	Burmese units of measurement#mass	Myanmar units of measurement#Mass	Redirect target
foot/s	Feet per second	Foot per second	Redirect target
ft/min	Feet per second	Foot per second	Unchanged
ft/s	Feet per second	Foot per second	Unchanged
furlong per fortnight	FFF System	FFF system	Redirect target
kilderkin	Kilderkin	English brewery cask units#Kilderkin	Unchanged
MTON	Measurement ton	Shipping ton	Unchanged
stere	Stère	Stere	Redirect target
gr-f	Pound-force	Pound (force)	Redirect target
grf	Pound-force	Pound (force)	Redirect target
lb-f	Pound-force	Pound (force)	Redirect target
lbf	Pound-force	Pound (force)	Redirect target
lb(f)	Pound-force	Pound (force)	Redirect target
oz-f	Pound-force	Pound (force)	Redirect target
ozf	Pound-force	Pound (force)	Redirect target
lbf/in2	Pounds-force per square inch	Pounds per square inch	Unchanged

Resolved (torque problems): Propose to change these to use link Kilogram metre (torque) which is a new redirect to Torque. There is not much information regarding "kilogram metre" in the target article, but the title of the link ("Kilogram metre (torque)") would be shown as a popup when hovering on the link, and it is helpful.

Unit	Link	Should be
kg.m	Kilogram metre	Kilogram metre (torque)
kgf.m	Kilogram metre	Kilogram metre (torque)
kgm	Kilogram metre	Kilogram metre (torque)
m.kg-f	Kilogram metre	Kilogram metre (torque)
m.kgf	Kilogram metre	Kilogram metre (torque)

Link changes

Unit	Link	Should be
energy/time	Power (DAB)	Power (physics)
length/length	Gradient	Grade (slope)
dog year	Dog year (DAB)	List of unusual units of measurement#Dog year
μin	SI prefix#Non-SI units	SI prefix#Non-metric units
firkin	Firkin (DAB)	Firkin (unit)
kJ/kg	Kilojoule per kilogram (redirects to DAB)	Specific energy
Gly	Light-year#Distances in light-years	Light-year#Definitions
kly	Light-year#Distances in light-years	Light-year#Definitions
Mly	Light-year#Distances in light-years	Light-year#Definitions
CHU-IT	Conversion of units	Conversion of units#Energy
cufootnaturalgas	Conversion of units	Conversion of units#Energy
cuftnaturalgas	Conversion of units	Conversion of units#Energy
th	Conversion of units	Conversion of units#Energy

Any thoughts? I will put what we agree in the sandbox modules and do some testing. Fairly soon after that it might be time to do a new release with only these changes. Johnuniq (talk) 09:55, 5 February 2018 (UTC)

Thanks, that looks good. You may want to leave some redirects such as Measurement ton in case they turn into articles or are pointed elsewhere. Certes (talk) 11:38, 5 February 2018 (UTC)

Will do. I added three units to the tables above after discovering my testing had ignored the Firkin DAB page mentioned by DePiep above. Johnuniq (talk) 04:44, 6 February 2018 (UTC)

I removed m2/ha (link Basal area) which was listed as a problem above. It appears the unit is used only at Angle gauge and Caquetá moist forests which concern forest management. I moved kJ/kg from problems to Link changes with what I think is a solution. I'm recording these details as documentation for the changes that will occur in the modules. Johnuniq (talk) 08:25, 6 February 2018 (UTC)

Some minor opinions:

• It seems to make sense to bypass the redirects for viss, foot/s, ft/min, ft/s, furlong per fortnight.
• While I agree with your handling of "kilogram metre", having {{convert}} accepting the following units seems unnecessary, problematic to me (and should possibly be discouraged): kg.m and kgm (in words, fine, but in units we could insist on kgf.m) and m.kg-f and m.kgf (more ambiguous form of nonstandard units) and are potentially overreach; also they seem to be unused.

It looks good otherwise. —Quondum 04:03, 7 February 2018 (UTC)

• About initial capital for SI names. I see "ampere hour" for A.h. The lc is ok as unit name (and tooltip) but wiki article name spells uc. Any preference, to apply consistently? And what with non-SI names like f/Foot? -DePiep (talk) 04:40, 7 February 2018 (UTC)

Links at the master units list are defined with an initial capital letter. For example, ft has link Foot (unit) and furlong has link Furlong. However, convert removes redundancies to reduce the size of Module:Convert/data. In that module, the link for ft is unchanged but the link for furlong is omitted because it can be derived from the unit's name or symbol. That's why the first of the following links starts with "F" while the second starts with "f".

• {{convert|3.7|m|ft furlong|lk=out}} → 3.7 metres (12 ft; 0.018 furlongs)

The result is 3.7 metres (12 [[Foot (unit)|ft]]; 0.018 [[furlong]]s) but the pop-up on hovering over the link shows an uppercase F for both. Johnuniq (talk) 06:22, 7 February 2018 (UTC)

I'm fine with each and every well-thought situation. - DePiep (talk) 01:18, 8 February 2018 (UTC)

I might have finished although I'll let some time pass before a final check. If no better ideas, I will update the units in the sandbox to reflect the above in a day or two. I agree some of the unit codes such as those mentioned by Quondum are dubious but that's a bit much for me to think about at the moment. I was going to download a new article dump and extract the converts in due course, and I can report with greater confidence regarding what related units are used. Johnuniq (talk) 07:00, 7 February 2018 (UTC)

I updated the master list of units and Module:Convert/data/sandbox. The affected units follow.

Unit	Link
length/length	Grade (slope)
Å	Ångström
sqft/acre	Basal area
A.h	Ampere hour
g/m3	Density
CHU-IT	Conversion of units#Energy
cufootnaturalgas	Conversion of units#Energy
cuftnaturalgas	Conversion of units#Energy
th	Conversion of units#Energy
GJ/kg	Specific energy
J/g	Specific energy
kJ/g	Specific energy
kJ/kg	Specific energy
TJ/kg	Specific energy
USgal/a	US gallon per year
gr-f	Pound (force)
grf	Pound (force)
lb-f	Pound (force)
lbf	Pound (force)
lb(f)	Pound (force)
oz-f	Pound (force)
ozf	Pound (force)
Gly	Light-year#Definitions
kly	Light-year#Definitions
Mly	Light-year#Definitions
μin	SI prefix#Non-metric units
viss	Myanmar units of measurement#Mass
furlong per fortnight	FFF system
foot/s	Foot per second
mm/s	Metre per second
dog year	List of unusual units of measurement#Dog year
kg.m	Kilogram metre (torque)
kgf.m	Kilogram metre (torque)
kgm	Kilogram metre (torque)
m.kg-f	Kilogram metre (torque)
m.kgf	Kilogram metre (torque)
firkin	Firkin (unit)
stere	Stere

Johnuniq (talk) 07:05, 9 February 2018 (UTC)

Let's drop the deprecated ones

This month, Module:Convert is four year old and a great job it did & does.

I propose to get rid of all deprecated parameters and -values. Here they are (as of 2017 Dec 18): {{Convert/doc/deprecations list}}. Sure there could be nuanced processes, but surely Johnuiq can give an oversee and a support. - DePiep (talk) 01:53, 20 December 2017 (UTC)

list

See original permalink (before removals). -DePiep (talk) 09:46, 16 January 2018 (UTC)

This list: 

Deprecated options should not be used. They may produce incorrect or undesired results and there is no guarantee that they will be supported in the future.

• disp=flip is deprecated. Use order=flip instead
• sing= is deprecated in any situation. Use adj= instead
• Range separator |xx| is deprecated (not MOS compliant). Use |x| instead
• Range separator |*| is deprecated (not MOS compliant). Use |x| instead.

-DePiep (talk) 01:56, 20 December 2017 (UTC)

Discussion

Are any of these in use? I seem to remember a bot going around eliminating a bunch of them. Kendall-K1 (talk) 02:34, 20 December 2017 (UTC)

Does not matter. They should be out of Module:Convert code, out of articles, out of documentation. -DePiep (talk) 22:39, 20 December 2017 (UTC)

The following appear to be completely unused in main article space (I'm using Help:Searching with the insource: option.)

• abbr=comma
• adj=1 (not in Johnuniq's list below, because I only just removed the remaining three usages)
• adj=flip
• adj=nocomma
• comma=gaps5
• disp=2
• disp=flip5
• disp=nocomma
• disp=slash
• disp=u2
• near=5

There are also some that are widely used, so removal at this stage might be unwise:

• adj=j
• disp=5
• disp=flip

I still need to work out how to search for the other cases. —Quondum 04:45, 20 December 2017 (UTC)

Does not matter. They should be out of Module:Convert code, out of articles, out of documentation. The only talkable question is: which process to use? Categorisation, code versions. Six months, three module versions: is like nothing. -DePiep (talk) 22:47, 20 December 2017 (UTC)

That might have been me. The following options are deprecated by the module. That means they display a large error message on preview, and an asterisk and tracking category on save. The tracking category is currently empty, so none of these are used in articles.

abbr=comma

adj=flip

adj=nocomma

comma=gaps5

disp=/

disp=2

disp=flip5

disp=nocomma

disp=s

disp=slash

disp=u2

near=5

sortable=in

sortable=out

We should check the effect of removing an option to take care to not unduly damage old revisions of articles and old convert discussions where the deprecated option was once used. In May 2015 I counted 21,588 occurrences of disp=flip in articles. If we ever removed that option, viewing old revisions of some pages would not do a flip. That may not be a problem, I suppose. I have removed a lot of deprecated options from articles, but disp=flip is not yet regarded as deprecated by the module because it would cause too many problems. Johnuniq (talk) 06:53, 20 December 2017 (UTC)

There is no obligation to keep supporting old versions. That would take us hostage. Improvements are just that.

If items are already completely removed from {{Convert}} (and trigger a regular error), then that is fine and they can be removed from the documentation. This would be Johnuniq's list. (?) [Or do I misunderstand? These are actually handled by the code? If that's the case, I suggest complete removal in the end. -DePiep (talk) 12:58, 20 December 2017 (UTC)]

Deprecated items still supported by {{Convert}} (still present in code) could get a hard or a soft removal. Hard: remove from code, will be categorised for editing and have the in-line marker. Soft: keep working in code for now, but do categorise for editing out. After that, it can be removed from code. Because of the huge number, maybe disp=flip could stay (trivial).

Note that each item that is functioning must be documented, because an editor can meet that in article code and so must be able to track it down in the documentation. Taking this load off from documentation is another good reason to proceed.

Priority should be given to the non-MOS options. These must be removed anyway, and likely need a manual edit (editors eye). So categorisation looks best for these. -DePiep (talk) 12:42, 20 December 2017 (UTC)

Johnuniq, you mention "... to take care to not unduly damage old revisions of articles and old convert discussions ...". This seems like a shortcoming in WP rendering. Surely it would make most sense to have old revisions render transclusions as they were at a date that that revision was current (e.g. at the time the revision was committed)? It seems to be insanity to consider all past usages of a template, module or transcluded page when revising these? Perhaps this is a topic for WP:Village Pump? —Quondum 23:50, 20 December 2017 (UTC)

Wikipedia time travel is the aim of mw:Extension:Memento. It would involve a tremendous amount of overhead and I don't know if there are any plans for its use at enwiki. I have occasionally looked through old revisions trying to find something, and have been irritated to see a bunch of non-working templates in revisions that were only (as I recall) a year old. The problem is something to bear in mind. There are possibly no significant issues arising from removing deprecated options, but removing ranges would cause errors in old revisions. I'm not saying that is a blocker, just that it needs to be considered. Johnuniq (talk) 01:46, 21 December 2017 (UTC)

no. Mainspace templates do not have to cover previous versions. Full stop. -DePiep (talk) 02:09, 21 December 2017 (UTC)

I am happy with being able to retrieve historical page source; I do not care about rendering. I'd prefer not to impede development due to complexity of retro rendering support, though. For that, let's rely on Memento and equivalents. —Quondum 03:11, 21 December 2017 (UTC)

Deprecated summary

The options I listed above at 06:53, 20 December 2017 can all be removed: they are not needed and are not used in articles.

The following is a summary of the others, with my quick opinion. ? means I haven't yet examined the situation. OK means I see no problem for convert to be changed to do this, although we should check what convert would actually do when encountering wikitext with the removed option. OK* is OK but there are probably too many occurrences for convert to be changed at the moment.

The "unique convert" number is the result of this process:

• Extract each convert from the wikitext in articles in the 3 November 2017 dump (just {{convert}}; have not looked at {{cvt}}).
• Normalize each convert (lowercase "convert", omit redundant spaces).
• Remove duplicates (often the same convert is used in several places in an article, and/or in several articles).
• The number is the count of the unique converts with this option.

Table: Usage number

Option	Alternative	Johnuniq opinion	Unique convert
abbr=mos	by or x	OK	6 (now removed)
adj=1	(omit)	OK	0
adj=j	(omit)	OK	38 (now removed)
disp=5	round=5	OK	904
disp=flip	order=flip	OK*	13917
sing=x	adj=x	OK*	9224
Range
xx	x	?	374
*	x	?	129
&	and	OK	18 (now removed)
to-	to(-)	OK	67 (now removed)

I'll think about this more in the next few days. Johnuniq (talk) 10:24, 21 December 2017 (UTC)

I created a list of articles (as at 3 November 2017) that have a convert with one of the "?" options/ranges above. The list is in my sandbox (permalink). Johnuniq (talk) 04:51, 22 December 2017 (UTC)

I've removed all instances of adj=j from mainspace. —Quondum 12:32, 22 December 2017 (UTC)

OK, thanks. See my sandbox for "Commodore Nutt" which shows an example using abbr=mos that would be damaged by removing the option. I'm not happy about that, although the other abbr=mos cases are less clear. I'm still wondering about the ranges. Johnuniq (talk) 22:52, 22 December 2017 (UTC)

Thanks for highlighting that instance, which was a misuse of the template. The remainder are simply style choice. I have dealt with (removed) all six instances of abbr=mos that you listed. —Quondum 03:32, 23 December 2017 (UTC)

I wouldn't say "misuse" but your alternative is fine. It looks like everything other than disp=flip, sing=x and ranges xx and * can be removed in January, with more thought about the ranges in due course. Johnuniq (talk) 00:27, 24 December 2017 (UTC)

Yes, "misuse" is too strong a description. It was an example with an unusual meaning: an ordered sequence rather than the range normally intended with {{convert}}, which relied on a coincidence of language. The remaining cases may be a bit more challenging, but support for them need not be removed yet. —Quondum 02:01, 24 December 2017 (UTC)

• I'd say it is OK to keep the two "OK*" situations in code, because it would require thousands of trivial edits to remove them. They will be documented as deprecated still. DePiep (talk) 11:46, 29 December 2017 (UTC)
• I understand that Johnuniq wants to re-discuss the two range notations (xx, *). -DePiep (talk) 11:46, 29 December 2017 (UTC)

The case of disp=5 must be considered. I reduced the number of mainspace articles that use this option from over 1200 to 1000, though it has since increased to 1001. It also appears a few times in the spaces Wikipedia: (mainly relating to featured articles) and Template:. In main article space, it is a good candidate for a bot to substitute round=5 (a simple regex find-and-replace might do due to its uniqueness: it does not seem to occur in any other context, including cvt, but I'd feel more comfortable if it was checked to be a parameter to {{convert}}). I have no experience of bots, and wouldn't know where to start. —Quondum 13:17, 29 December 2017 (UTC)

I could run an AWB semi-bot to edit these 1000 out. Do we agree this is not a trivial edit then? -DePiep (talk) 13:27, 29 December 2017 (UTC)

I do not know what you mean by a "trivial edit". Each edit would be be straightforward, and would reasonably be marked as minor, but the number of edits would make manually changing it tedious: I would probably take most of a day to do them by hand. —Quondum 15:34, 29 December 2017 (UTC)

'Trivial edit': Nor by hand, not by bot (like WP:AWB), we are to make trivial edits, that is edits that have no effect on the rendered page. For example, it would fill watchlists with useless lines. However, when we deem it relevant (such as in this case), such an edit may be declared acceptable. Is why I ask for support. -DePiep (talk) 15:51, 29 December 2017 (UTC)

Ah, I see. Yes, I believe from checking when making this edit by hand that this edit makes makes no change to the rendering at all, and should be regarded as trivial in this sense. In the cases that I checked, the rounding behaved identically and the change made no difference whatsoever in the rendering. In the 200+ articles in which I made this change, of those that were edited in the four days since, three edits related to my change. Of these, two appeared to think that the rounding was inappropriate anyway (Hume Highway and Interstate 696) and one (Hurricane Ioke) was an unexplained revert in conjunction with another edit. So, yes, I support based on observation that this edit is trivial and hence that it is acceptable as a mass edit. —Quondum 17:41, 29 December 2017 (UTC)

1. Of course this edit disp=5 → round=5 has no visual effect, because is is the alternative for a deprecated parameter!

2. Your logic is upside down: "this edit is trivial and hence that it is acceptable": if it is without effect, it is not acceptable.

3. However, we can conclude here that the edit is relevant enough in this situation to be mass-made. That is the support I am asking for. - DePiep (talk) 18:16, 29 December 2017 (UTC)

The closest thing to a prohibition on a "trivial edit" (or perhaps a "dummy edit") that I can find is in Wikipedia:Editcountitis, though I do vaguely remember seeing something about not changing non-rendering whitespace simply to adjust non-rendering whitespace, since this pointlessly clutters edit histories and watch pages. Such "prohibitions" would not apply here. My logic about a non-rendering edit is that this edit is low risk and hence can be automated. That is, I support your conclusion in point 3 above, and that this mass edit should be made. —Quondum 19:21, 29 December 2017 (UTC)

Yes, all fine then. The rule is WP:AWBRULES #4, and ignoring it may have my AWB permission revoked ;-). However, in this case it is not an idle edit. -DePiep (talk) 19:29, 29 December 2017 (UTC)

These days, Quondum is mass-removing those two deprecated, huge-number parameters by AWB (13k and 9k). I support these edits, and note that they are not trivial re the AWB rules, because they fit the larger process to remove deprecated parameter values. -DePiep (talk) 19:24, 6 January 2018 (UTC)

• About the disp=5 usage. In the #Table:Usage number above, it says 904 uses (by the described way counting). OTOH, the Template Parameters tool lists "disp 5 (2583)" uses in articles, per Jan 1st. Is this large difference meaningful, re this issue of removal? Are instances missed in the 904 counting? -DePiep (talk) 19:04, 6 January 2018 (UTC)

Also, Quondum, since you wrote on Jan 5 that "all" disp=5 instances are edited out, what do you think? Did you remove 904 or 2583 of these? -DePiep (talk) 19:14, 6 January 2018 (UTC)

My count was 904 unique converts with disp=5. It is very common for the same convert to be used in several articles, or a few times in one article. That means there may well have been 2583 in total. I look at the unique converts because it makes it easier to find bad parameters. In the 3 November 2017 article dump, there are 2,625,000 converts in 609,000 articles, but only 774,000 unique converts. That does not include {{cvt}} which I haven't got around to including. Johnuniq (talk) 21:45, 6 January 2018 (UTC)

The number of articles that I edited to replace {{convert|...|disp=5|...}} was pretty close to 1250. I did not perform any count of individual replacements, but an average of about two transclusions per page affected is plausible.

Notwithstanding the reasonableness of doing the edits, there is a matter of practicality given the large number (currently 8,263 articles remaining with disp=flip). These change can be made into zero-risk automated edits: just have AWB include a default rule for this substitution, ensuring that it is a {{convert}} or {{cvt}} parameter. Then, when anyone uses AWB with general cleanup enabled, the deprecated cases would reduce progressively without dedicated edits. Does anyone know where this could be discussed? It seems to be a better and more accurate solution than me just increasing my edit rate (by skipping my cursory review of each change). —Quondum 00:41, 7 January 2018 (UTC)

Given this answer, should we first ask for the supported |sing= → |adj= replacement (is it safe)? And would it be reasonable to ask for the module for disp=flip → order=flip? I think the new AWB functionality will have utility for other similar cases. —Quondum 20:15, 7 January 2018 (UTC)

Both at once (why separate at all?). May take months before numbers are down a bit anyway. Meanwhile, they should stay in code as they are today. -DePiep (talk) 20:32, 7 January 2018 (UTC)

Good point. But we must be sure that |sing= is exactly equivalent to |adj= before asking. I am not qualified to answer this (not familiar with {{convert}} implementation). —Quondum 20:51, 7 January 2018 (UTC)

Johnuniq and DePiep, could you (or anyone else familiar with {{convert}}) confirm that all |sing= parameters can safely be replaced with |adj=, so that I may make a request for it to be automatically done through AWB cleanup? —Quondum 00:04, 9 January 2018 (UTC)

@Quondum: Yes, every sing can be replaced with adj. I just added #New version below mentioning that I cleaned up a few broken cases using sing and I think the rest can be bot changed. Johnuniq (talk) 00:39, 9 January 2018 (UTC)

Just for tracking, I added |sing= → |adj=, and as of now a mainspace search with insource:convert insource:"|sing= lists 18,627 articles (a considerable overestimate, but the delta should be informative). —Quondum 03:22, 13 January 2018 (UTC)

wait wait: what |sing= options actually are supported (and so to be transposed to |adj=)? Surely not |sing=x (the table above says; it's a generic of course). - DePiep (talk) 09:27, 15 January 2018 (UTC)

All of them, I assume. During cleanup, AWB is now replacing every instance of |sing= with |adj= for live article space invocations of the {{convert}} and {{cvt}} while keeping the parameter value unchanged. —Quondum 12:49, 15 January 2018 (UTC)

Convert simply replaces sing with adj so they are equivalent. Except, before doing the replacement, convert checks whether both sing and adj are given. If so, the sing is removed if it is the same as the adj; otherwise, a warning is displayed. The following examples use fixed wikitext so they won't change.

• {{convert|12|m|adj=on|sing=on}} → 12-metre (39 ft)
• {{convert|12|m|adj=on|sing=off}} → 12-metre (39 ft)

Holding the mouse over the asterisk shows "Convert: Ignored invalid option "sing=off"". Johnuniq (talk) 21:59, 15 January 2018 (UTC)

Another smart code detail. Hope the AWB parameter replacement checks for double parameter usage (use (|adj= twice). Ho harm, just inconvenience. - DePiep (talk) 08:47, 16 January 2018 (UTC)

I checked the November 2017 dump of articles and there are no remaining cases of a convert with both adj and sing. Johnuniq (talk) 09:36, 16 January 2018 (UTC)

Deprecated proposal

The following options are deprecated by the module and are not used in articles. I propose they be removed in the next release in January.

abbr=comma adj=flip adj=nocomma comma=gaps5 disp=/ disp=2 disp=flip5 disp=nocomma disp=s disp=slash disp=u2 near=5 sortable=in sortable=out

The following options are apparently now unused. I propose they be removed in the next release:

abbr=mos adj=1 adj=j

I propose flagging disp=5 as deprecated so its use will be shown with a large error message on preview and an asterisk and tracking category on save.

I think these proposals should be applied to see what issues arise before tackling others. Regarding ranges, I have seen a wide variety of topics and editors and am not in a position to know that removing some ranges would give a good result. The range options which can show multiply (×) follow. For clarity, these use an underscore (_) where a space would appear and a tilde (~) for  .

Table: "by(x)"

by(x)	_by_ in input	_×~ in output	append unit to all values in output
x	_by_ if unit in full	_×~ if unit abbreviated	append unit to all values if abbreviated
xx	~×~ always
*	× always

The * range is possibly dubious although I would want to examine where it is used and consider alternatives before making an a priori judgment. I have not examined how the xx range is used but it seems likely that such a range would be useful somewhere. Does MOS have an opinion on that? Johnuniq (talk) 02:55, 30 December 2017 (UTC)

Where does the "by(x)" come from? How is that an issue here?

And: "x" is well defined and should be no item. Why mentioned here? Any change?

What does "~×~ always" means? Does the option stay? What output then?

For * what is that?

-DePiep (talk) 03:39, 30 December 2017 (UTC)

Just be clear about what will be kept and gone. I don't like this as it shows now. -DePiep (talk) 03:46, 30 December 2017 (UTC)

I would not remove options from an established and widely used template without carefully examining (1) how those options are used; (2) what alternative would replace them; and, (3) whether the alternative is an improvement. Part of that is understanding the relevant range options and that is why I documented the ranges which can display ×. Johnuniq (talk) 06:56, 3 January 2018 (UTC)

(3) is what I kept reading between the lines: reopening the discussion. -DePiep (talk) 09:29, 4 January 2018 (UTC)

More opinions please Any thoughts on the above proposal to remove the options shown above in the lines starting with abbr=comma and abbr=mos? Is it ok to flag disp=5 as deprecated? What should happen with the xx and * ranges? Johnuniq (talk) 06:56, 3 January 2018 (UTC)

@Frietjes, Huntster, JFG, Kendall-K1, Quondum, Thryduulf, Wikid77, WOSlinker. Sorry to be a nuisance but I'm pinging regulars from the last few months in the hope of getting more opinions on this dull but important issue. Removing options needs more support. Johnuniq (talk) 01:05, 4 January 2018 (UTC)

Applicable MOS: MOS:UNITSYMBOLS on 'ranges'

Earlier discussions: xx|_and_|*|?|#Break_to_subtopic:_deprecate_options_|xx|_and_|*|? (Nov 2014). -DePiep (talk) 09:40, 4 January 2018 (UTC)

• I support removal of the unused, deprecated parameters listed in the two lines you mention (there are a few archive, user and talk pages that will be affected, but I consider that to be acceptable). I'm hesitant to flag disp=5: 1001 articles are affected; a bot substitution seems better. I cannot comment on the ranges. Help:Convert_messages#Deprecated_option should be updated. —Quondum 04:12, 4 January 2018 (UTC)

  Update for disp=5

  Option disp=5 has been replaced in all articles. Removal is probably the way to go now. —Quondum 00:32, 5 January 2018 (UTC)

• Purely my opinion, but I will not ever support the removal of "xx" functionality, regardless of MOS suggestions, because the MOS is stupid beyond belief on this. But I know I'm a lone voice in this, regardless of how it benefits infobox space limitations. Everything else looks good to me. — Huntster (t @ c) 04:43, 4 January 2018 (UTC)

If you could be more specific, beyond saying "stupid", that could be helpful. -DePiep (talk) 09:30, 4 January 2018 (UTC)

The MOS mandating that figures include the unit name beside them (1 km × 2 km × 3 km, for example), even in situations where it is obvious (like in infoboxes), is what I'm referring to as stupid. — Huntster (t @ c) 23:32, 4 January 2018 (UTC)

• Comment This soft-RfC is flawed into confusion. First the undisputed removals (like abbr=mos) are needlessly widening the discussion. Also the semi-disputed ones (like disp=5 being used often) require different arguments and will spoil the flow of argumentation. Then, the table "by(x) ... " above does not mention the MOS vs. non-MOS issues, and does not refer to the "deprecated" status. I may need some time to set the questions straight, at least to explain my opinion. -DePiep (talk) 09:49, 4 January 2018 (UTC)

Early opinions. (later on, I hope to be more specific wrt the 'range' options involved).

Deprecated and unused: remove from code, full stop. Low hanging fruit. We don't need a specific warning system for |disp=foo. They are documented as "deprecated" for years. Also, no need for code complication in this. Up to Johnuniq to choose code change process to this outcome.

Deprecated and >>used (disp=flip, sing=x, 9k and 13k): keep, keep deprecated (with preview warning), do not remove from articles now (too much trivial edits I guess). But we could decide on a long-term removal process btw (allowing those trivials). Quite low fruit too, IMO.

About 'Ranges' (square, cubic, or area, volume: the "by" or "×") issues. See also Table: "by(x)".

Options |xx| and |*| are deprecated, and non-MOS. Usage: 374, 129. Johnuniq reopens this, because it might point to a need for a different form. Also, new forms are proposedmentioned in the Table, involving |abbr=.

I'd say: let's analyse current usage, to distill that need. (Found one: in infoboxes and tables, a short form is needed, but is not MOS-available. I'd propose: MOS-allow and use 3 × 4 × 4 m³. Both short and correct wrt dimensions!).

Also, a priori I am critical and un-enthousiastic about the Table proposalexisting option shown: "when form A, internally set |abbr=yes, when form B, then internally set |abbr=no [and reverse]". This is very complicating for the user, because it adds interacting parameters. Too hard to document, too hard to understand. I would not ask this for those doing module code maintenance too. IIRC, in this topic we already have "implicit parameter change" between input measurement and calculated measurement. To illustrate: as a {{Convert}} user, try to figure out how that works. By the way, any output change for existing (deprecated) options would require a manual, editors eye check of the articles. Too delicate to do a blind change.

Later on I hope to illustrate the options more complete. Especially my suggestion wrt the short infobox form, and usage of unit names like "cubic metre" that are in play. -DePiep (talk) 10:10, 5 January 2018 (UTC)

Re disp=5 and disp=flip and more, Quondum is using AWB to fix zillions of these. Table: "by(x)" documents what convert has done for years although the meaning may be unclear. These examples illustrate the point.

• {{convert|11|by(x)|22|by(x)|33|m}} → 11 by 22 by 33 metres (36 ft × 72 ft × 108 ft)
• {{convert|11|by(x)|22|by(x)|33|m|order=flip}} → 36 by 72 by 108 feet (11 m × 22 m × 33 m)
• {{convert|11|by(x)|22|by(x)|33|m|abbr=off}} → 11 by 22 by 33 metres (36 feet × 72 feet × 108 feet)
• {{convert|11|by(x)|22|by(x)|33|m|abbr=off|order=flip}} → 36 by 72 by 108 feet (11 metres × 22 metres × 33 metres)
• {{convert|11|x|22|x|33|m}} → 11 by 22 by 33 metres (36 ft × 72 ft × 108 ft)
• {{convert|11|x|22|x|33|m|order=flip}} → 36 by 72 by 108 feet (11 m × 22 m × 33 m)
• {{convert|11|x|22|x|33|m|abbr=off}} → 11 by 22 by 33 metres (36 by 72 by 108 feet)
• {{convert|11|x|22|x|33|m|abbr=on}} → 11 m × 22 m × 33 m (36 ft × 72 ft × 108 ft)

I'm sorry to further complicate this section. Johnuniq (talk) 10:35, 5 January 2018 (UTC)

So I am wrong saying "new options introduced": by(x) is existing. Stroke. Sorry for confusion. -DePiep (talk) 10:43, 5 January 2018 (UTC)

• I'm somewhat confused about what is being proposed, and don't understand at all the questions about ranges, but speaking in general terms:
  • I'm happy for options that (a) have been marked as deprecated for some time (at least 2-3 months, preferably closer to 6) in all live documentation we are of (or have already been removed from this documentation), (b) have been marked as deprecated on preview and tracked for a similar length of time, and (c) have no live uses in main, draft, template, category or help namespaces, and (d) have no live uses on current policy, guideline or process/explanation pages in Wikipedia space (i.e. excluding those marked as historical, failed proposals, etc), (e) have no live uses on main userpages or non-abandoned userspace drafts of active editors (f) have no live uses in talk comments created in the past month or so (which would indicate continuing usage and a likelihood of breaking ongoing discussions). This might be a higher standard than others want, but I see it as more important not to break the encyclopaedia or these encyclopaedia-supporting pages than to have tidy code.
  • I'm happy for any parameter to be marked as deprecated if the same functionality is already available in a different way (e.g. disp=5 / round=5) and it is marked as deprecated in documentation we are aware of first (only needs to be long enough before that someone encountering an error on preview can find the reason and alternative in the documentation). It should remain marked as deprecated in both places for several months before removal.
  • I'm not happy for any parameter to marked as deprecated where the same functionality is not already present in a different way, without an explicit discussion here showing what will not be available, why, and what alternatives there are. If that discussion agrees to deprecate then documentation should be updated first, and deprecation should last several months. Thryduulf (talk) 11:18, 4 January 2018 (UTC)

• I see no problem with removing deprecated parameters, as long as it is possible to achieve the same result with other parameters. Frietjes (talk) 17:27, 4 January 2018 (UTC)

OK. Other parameters, like 'ranges' with separators |xx| and |*| (areas, cubes) are deprecated for being not MOS. Johnuniq made the question for de-deprecation them, somehow. That's the trickier issue. -DePiep (talk) 17:57, 4 January 2018 (UTC)

New version

We have to move forward so I am planning a new release, see Module version 21 (below). There is little likelihood of getting further uninvolved comments and the three extra editors who have responded each supported keeping parameters that are used, particularly where other parameters do not provide the same result. That leaves the following items for future consideration:

• Slowly replace the many disp=flip with order=flip and and sing=x with adj=x but the module should not flag them as deprecated. I have checked all occurrences of sing in the November article dump and have fixed broken cases (for example the duplication in {{convert|165000|acre|km2|0|sing=on|adj=on}} here). Therefore, it should be satisfactory to simply replace sing with adj.
• There is disagreement concerning the range separators xx and *. In a month or two, someone might like to find examples in articles that show a problem with keeping these, and seek discussion at MOS.

Johnuniq (talk) 00:35, 9 January 2018 (UTC)

Yes. -DePiep (talk) 09:49, 9 January 2018 (UTC)

In the documentation, sortable=in, sortable=out have never been marked "deprecated, use sortable", but obviously they are and they are not used. -DePiep (talk) 11:54, 9 January 2018 (UTC)

Yes, they have been deprecated by the module since April 2015. That is, using them in an article would show a warning asterisk and add the tracking category, which is empty. Johnuniq (talk) 22:20, 9 January 2018 (UTC)

Slow replacement tracking

This section is intended for long-term archive building. It has {{anchor|1=disp=flip|2=sing=}}

So parameters disp=flip and sing= are to be replaced slowly (by order=flip, adj=). That is, only when other other, non-trivial edits are made to that page. (For WP:AWB see here). To track this development, I'll note current usage numbers. Depending on counting method, these may vary. However, over time each method by itself should show a reduction.

disp=flip → order=flip requires an AWB custom module; not implemented. —Quondum 12:21, 16 January 2018 (UTC)

I have requested this feature. —Quondum 23:01, 18 January 2018 (UTC)

A. Counting by Johnuniq

see table above, 2017-12-21:

Counted: 3 Nov 2017 dump

Not {{Cvt}}

sing=<any> 9224

disp=flip 13917

B. Listing by TemplateParam tool

TemplateParam by Bamyers99 (updates 1/month)

Counted: 2018-01-01 dump

{{Convert}} on articles: 614317

{{Convert}} instances in those articles (transclusion count): 2653283

sing=<any> 23520

disp=flip 26044

C. Search enwiki source

by Quondum, 03:22, 13 January 2018 (see above and here)

sing=<any> 18,627 articles counted at 03:22, 13 January 2018 (a considerable overestimate, but the delta should be informative) (live count: insource:convert insource:"|sing=)

disp=flip 8,269 articles counted at 03:07, 9 January 2018 (live count: insource:convert insource:"disp=flip")

-DePiep (talk) 09:13, 16 January 2018 (UTC)

Update: The 3 November 2017 article dump contained 26,040 convert with disp=flip and 23,540 convert with sing=..., of which 13,917 and 9224 respectively were unique. There were 159 cvt with disp=flip and 1 with sing=..., all of which I have just fixed. Johnuniq (talk) 08:15, 17 January 2018 (UTC)

Well understood as additions to A. BTW, we should take care to distinguish "mainspace" from "transclusions on [any] page", etc. - DePiep (talk) 20:54, 3 February 2018 (UTC)

D. Extract converts from 20180201 dump

I extracted all converts in articles from the 1 February 2018 dump. There were 19,817 occurrences of convert with disp=flip (including duplicates) in 7,577 articles, and 22,062 occurrences of sing=x (including duplicates) in 14,800 articles. I'm going to claim a record for replacing 533 occurrences of disp=flip in a single article (diff)! Johnuniq (talk) 07:11, 10 February 2018 (UTC)

Default rounding bug

Hi,

{{convert|4.6|in|mm}} gives 4.6 inches (120 mm) while {{convert|4.6|in|mm|1}} gives 4.6 inches (116.8 mm). 116.8 should be rounded to 117, not 120.

Examples:

• {{convert|4.5|in|mm}} -> 4.5 inches (110 mm) -- ({{convert|4.5|in|mm|1}} gives 4.5 inches (114.3 mm) so it should be 114)
• {{convert|4.6|in|mm}} -> 4.6 inches (120 mm) -- ({{convert|4.6|in|mm|1}} gives 4.6 inches (116.8 mm) so it should be 117)
• {{convert|4.7|in|mm}} -> 4.7 inches (120 mm) -- ({{convert|4.7|in|mm|1}} gives 4.7 inches (119.4 mm) so it should be 119)
• {{convert|4.8|in|mm}} -> 4.8 inches (120 mm) -- ({{convert|4.8|in|mm|1}} gives 4.8 inches (121.9 mm) so it should be 122)
• {{convert|4.9|in|mm}} -> 4.9 inches (120 mm) -- ({{convert|4.9|in|mm|1}} gives 4.9 inches (124.5 mm) so it should be 125)
• {{convert|5.0|in|mm}} -> 5.0 inches (130 mm) -- ({{convert|5.0|in|mm|1}} gives 5.0 inches (127.0 mm) so it should be 127)

It seems to me like a rounding bug. I'd say that the rounding is done with cm instead of mm. The RedBurn (ϕ) 12:51, 31 January 2018 (UTC)

I'm sorry, but you asked the template to provide one place after the decimal, so why are you surprised that it gives you that? The default rounding is based on detecting the number of apparent significant figures, e.g. {{convert | 4.6 | in | mm | sigfig=2}} -> 4.6 inches (120 mm) -- 4.6 inches (120 mm). Dragons flight (talk) 13:04, 31 January 2018 (UTC)

You didn't say what you expected it to do, but my guess is you might want "|0". Kendall-K1 (talk) 15:16, 31 January 2018 (UTC)

I don't think I explained myself clearly. I've added "so it should be" followed with the right rounded value, the code of the value with one decimal value and the expected result in the second sentence.

I think {{convert|4.6|in|mm}} (4.6 inches (120 mm)) should give the same result as {{convert|4.6|in|mm|0}} (4.6 inches (117 mm)). The RedBurn (ϕ) 23:53, 5 February 2018 (UTC)

Convert cannot automatically produce results that satisfy every situation. The following shows that preserving the number of significant figures works pretty well, and options are available for situations where the output should have an unexpectedly higher degree of precision.

• {{convert|0.46|in|mm}} → 0.46 inches (12 mm)
• {{convert|4.6|in|mm}} → 4.6 inches (120 mm)
• {{convert|46|in|mm}} → 46 inches (1,200 mm)
• {{convert|460|in|mm}} → 460 inches (12,000 mm)

If convert produced 117 for the second case above, what should it produce for the others? Johnuniq (talk) 00:04, 6 February 2018 (UTC)

The exact value of 0.46 inch is 11.684 mm. With a 2 digits result before the decimal separator, that's 12 mm after rounding. But 4.6 inches in mm has 3 digits before the decimal separator, so the correct rounding 117. 120 is just plain wrong.

Here are the four examples with the correct rounding, by just adding |0:

• {{convert|0.46|in|mm|0}} → 0.46 inches (12 mm)
• {{convert|4.6|in|mm|0}} → 4.6 inches (117 mm)
• {{convert|46|in|mm|0}} → 46 inches (1,168 mm)
• {{convert|460|in|mm|0}} → 460 inches (11,684 mm)

I don't know how the conversion code works, but it seems to me that it could just behave like with |0 when we don't specify the number of decimals (which is supposed to mean 0 decimal). The RedBurn (ϕ) 23:04, 6 February 2018 (UTC)

If you want 5 significant figures in the output and you don't want to force the number of decimal places by specifying |3 or whatever, then you would have to give 5 significant figures in the input e.g. {{convert|0.46000|in|mm}} → 0.46000 inches (11.684 mm). If you just specify "0.46", the software assumes that you have rounded the value and the true value could be any value between 0.45501 and 0.46499. -- Dr Greg  talk  00:15, 7 February 2018 (UTC)

The template seems to be behaving as described in Template:Convert#Default rounding. Unless requested otherwise, the number of significant figures (not decimal places) coming out is the same number that go in, plus one where necessary to avoid drastic loss of precision (7 miles is 11 km, not 10 km). Certes (talk) 01:14, 7 February 2018 (UTC)

The current default behaviour is in keeping with norms/conventions for number of significant figures. A default behaviour of |0 would very much break with these conventions. The only question in my mind is where the boundary of what Certes describes as "drastic loss of precision" lies. At the moment the loss of precision can be quite significant, as the example 4.6 inches (120 mm) 5.1 inches (130 mm) shows: from 0.1/4.6 = 2.2% to 10/120 = 8.3%. This must be balanced against false implied precision from too many displayed significant digits. I think that the balance is not far off at the moment. —Quondum 04:38, 7 February 2018 (UTC)

I don't understand why the number of significant figures is not determined by the unit. Imperial and US units of length (or weight, or volume) often require decimals, whose number define their precision. However, the SI units have prefixes which define their precision:

4.6 inches is 0.11684 meters. But if I don't want decimals, that's also 12 cm or 116 mm. If I convert inches in mm, it means I want all 3 figures to be significant, otherwise I would have used cm.

Do you have a source for these norms/conventions, and are they based on Imperial/US units or SI units usage? The RedBurn (ϕ) 23:27, 7 February 2018 (UTC)

No there is no extra 'external' norms/convention for {{Convert}} primary rounding behaviour. Because: {{Convert}} /doc by itself, and above here, it is explained. To be honest: that could be better (the explanation, not the actual rounding). - DePiep (talk) 00:43, 8 February 2018 (UTC)

See Significant figures. To quote: "the number of significant figures roughly corresponds to precision". It has nothing to do with the choice of unit. —Quondum 00:56, 8 February 2018 (UTC)

I've added an example to /doc to show when the behavior is different with 0. There seems to be a consensus to keep the current behavior, but I'm still convinced that while "4.6 inches (12 cm)" is imprecise, "4.6 inches (120 mm)" is incorrect. When the orders of magnitude (not sure that's the correct term) of the units are comparable (e.g. feet and meters or inches and centimeters), there's no problem, it's when they're different (inches and millimeters or feet and centimeters) that problems arise.

I also think most if not all contributors above use US or Imperial units in everyday use instead of "metric" units, because the current default behavior of {{convert}} doesn't reflect normal usage of metric units in my opinion. Again, I've never seen for example "1 mile (1,600 m): it would be either 1 mile (1.6 km) or 1 mile (1,609 m).

By the way, I first discovered this problem here: Talk:Sony Xperia Z3 Compact. The RedBurn (ϕ) 11:50, 8 February 2018 (UTC)

Long term reply

This, once more, is not good. Every 6 months a confident, well-thinking user comes along and questions this point in GF. Up to us to reply & restore confidence.

IMO, we need: a short, a long, and a complete reply. It shows the /doc is not enough. - DePiep (talk) 01:12, 8 February 2018 (UTC)

Probably a good idea to put something in the FAQ then. Headbomb {t · c · p · b} 11:55, 8 February 2018 (UTC)

I really think the problem is with the coding for the existing arrangement. Surely anything that produces an answer (with minimal editor input) that is frequently criticised as wrong is, in itself, wrong. If the default gave more accuracy, but the editor felt that an excessive number of decimal places was shown, then that should trigger the editor to do something about it. Conversely, at the moment, the editor needs to double-check the convert facility every time it is used, which rather defeats the object of having this facility. I hesitate to throw an accusation at diligent and hard-working editors, but I suggest that convert template experts need to step outside their own universe and look at what the ordinary editor needs to assist them in making Wikipedia a better encyclopedia. Editors who are more interested in content than "how to edit" are those who will have useful material to add, but need tools that do not impose an unnecessary learning requirement.
ThoughtIdRetired (talk)

I suspect that there are an equal number of editors, like me, who regularly see the default providing too many significant figures and have to force the precision down, but who understand the template so don't come here to complain.

@ThoughtIdRetired: could you give some real examples of when the template should produce greater precision, other than when a definition is being given? My experience is that numerical illiteracy is widespread (for which education systems not editors should be blamed) and over-precise non-template conversions are common. Peter coxhead (talk) 14:59, 8 February 2018 (UTC)

In this case, it's when converting from a US unit to a non comparable metric unit. For example 5 inches to millimeters. 5 inches (13 cm) is right but not 5 inches (130 mm). When converting inches to millimeters - a non comparable metric unit - it implies that we want greater precision. Same thing for liquid capacity: 1 US gallon (3.8 L) is correct, but not 1 US gallon (3,800 ml). The RedBurn (ϕ) 08:31, 9 February 2018 (UTC)

Convert is for real-world values that have (almost always) been measured. Converting 5 inches to 127 mm would be an example of false precision. Johnuniq (talk) 10:10, 9 February 2018 (UTC)

Indeed, when converting the (manufacturer given) smartphone screen size from inches to mm, the precision is limited to a tenth of an inch (2.54 mm). However, instead of showing falser precision by rounding the millimeter value, I'd prefer Convert to override the mm preset and show the result in cm, which would be clearer and avoid misleading both the reader and the unexperienced (at least about this template) contributor. The problem here lies in the choice of the target unit (mm instead of cm) by the contributor. Sadly it seems like I'm talking to a brick wall as nobody here seems to be accustomed to everyday metric units usage. The RedBurn (ϕ) 11:33, 10 February 2018 (UTC)

Part of the problem may be an ambiguity with trailing zeroes. Is 80 mm the same as 8 cm, or does it imply a greater precision? It's the same issue that makes 89 miles (143 km) appear further than 90 miles (140 km) if you're driving in metric. Certes (talk) 11:57, 10 February 2018 (UTC)

If your question isn't rhetoric, yes I think in most cases 80 mm does imply greater precision. Otherwise, the use of mm is incorrect. So the 90 mm Gun M1/M2/M3 isn't the same caliber as the 8.8 cm Flak 18/36/37/41. The current behavior of the template is based on the thinking that 90 mm is the same as 8,8 cm, but it's not. About your miles to km example, since these are units of comparable size (much less than a factor of 10), and since the starting US unit could have been rounded, that result is expected. The RedBurn (ϕ) 13:10, 12 February 2018 (UTC)

No rhetoric; just trying to help find a good answer. So "80 mm" probably means 79.5—80.5 mm, because the alternative interpretation of 75—85 mm might have been better expressed as "8 cm". How about "80 g": does this mean 79.5—80.5 or 75—85? Does the fact that no one would express that as "8 decagrams" make a difference? But I expect these questions have been asked before and there are no definitive answers. Certes (talk) 16:07, 12 February 2018 (UTC)

Perhaps best not to try to debate suitability of any particular rounding convention in this particular subsection; I think DePiep's intention was to highlight that we need to describe better the existing convention that the default behaviour implements. Also, if there is to be another convention to be considered, the section title "Default rounding bug" is not suitable. —Quondum 17:09, 12 February 2018 (UTC)

Documentation is always hard. It occurs to me that the lead sentence in the template doc might be tweaked from this:

Template {{convert}} calculates measurements from one unit (you can enter) to another one, and then presents the results.

to, perhaps, something like this:

In its most simple form, Template {{convert}} receives unit and value inputs that you provide. From those inputs, the template calculates a corresponding value for a related unit which it rounds to an appropriate precision, and then presents in a consistent format.

I think that doing something like this straight-away serves as an indication that the result will not be precise to a bazillion digits but is instead rounded.

For all of my life I've had the conceit that I'm not stupid. If the test of that is to read and understand this single sentence, then that conceit is false:

By {{Convert}} default, the conversion result will be rounded either to precision comparable to that of the input value (the number of digits after the decimal point—or the negative of the number of non-significant zeroes before the point—is increased by one if the conversion is a multiplication by a number between 0.02 and 0.2, remains the same if the factor is between 0.2 and 2, is decreased by 1 if it is between 2 and 20, and so on) or to two significant figures, whichever is more precise. An exception to this is rounding temperatures (see below).

To paraphrase Shakespeare, that "learned editor is too cunning to be understood." Someone who knows what it means should spend some time recrafting it into something a bit more intelligible by mere humans.

—Trappist the monk (talk) 15:58, 8 February 2018 (UTC)

I tried to clean that text (diff) a long time ago was reverted. I replaced all the above with:

By default, the conversion result is rounded to a precision comparable to that of the input value.

I put my explanation at Help:Convert#Rounding. I know there should not be two documentation pages but having worked on the module I tried to explain things in a way that I would want as a reader. Johnuniq (talk) 21:55, 8 February 2018 (UTC)

Johnuniq, I really like that concise and communicative sentence. —Quondum 03:32, 9 February 2018 (UTC)

I also support using this sentence. Concise and communicative is clearer. — Huntster (t @ c) 13:43, 9 February 2018 (UTC)

Module version 22

Some 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

This release changes many unit links per discussion here. There are no other changes.

The following examples use fixed wikitext to show the current output from {{convert/sandbox}} so it will not change in the future.

Convert	Linked input unit
{{convert|2|cm/m|in/yd|disp=unit|lk=in}}	centimetres per metre
{{convert|2|Å|disp=unit|lk=in}}	ångströms
{{convert|2|sqft/acre|disp=unit|lk=in}}	square feet per acre
{{convert|2|A.h|disp=unit|lk=in}}	ampere hours
{{convert|2|g/m3|disp=unit|lk=in}}	grams per cubic metre
{{convert|2|CHU-IT|disp=unit|lk=in}}	Celsius heat units (International Table)
{{convert|2|cufootnaturalgas|disp=unit|lk=in}}	cubic foot of natural gas
{{convert|2|cuftnaturalgas|disp=unit|lk=in}}	cubic feet of natural gas
{{convert|2|th|disp=unit|lk=in}}	thermies
{{convert|2|GJ/kg|disp=unit|lk=in}}	gigajoules per kilogram
{{convert|2|J/g|disp=unit|lk=in}}	joules per gram
{{convert|2|kJ/g|disp=unit|lk=in}}	kilojoules per gram
{{convert|2|kJ/kg|disp=unit|lk=in}}	kilojoules per kilogram
{{convert|2|TJ/kg|disp=unit|lk=in}}	terajoules per kilogram
{{convert|2|USgal/a|disp=unit|lk=in}}	US gallons per year
{{convert|2|gr-f|disp=unit|lk=in}}	grains-force
{{convert|2|grf|disp=unit|lk=in}}	grains-force
{{convert|2|lb-f|disp=unit|lk=in}}	pounds-force
{{convert|2|lbf|disp=unit|lk=in}}	pounds-force
{{convert|2|lb(f)|disp=unit|lk=in}}	pounds
{{convert|2|oz-f|disp=unit|lk=in}}	ounces-force
{{convert|2|ozf|disp=unit|lk=in}}	ounces-force
{{convert|2|Gly|disp=unit|lk=in}}	gigalight-years
{{convert|2|kly|disp=unit|lk=in}}	kilolight-years
{{convert|2|Mly|disp=unit|lk=in}}	megalight-years
{{convert|2|μin|disp=unit|lk=in}}	microinches
{{convert|2|viss|disp=unit|lk=in}}	viss
{{convert|2|furlong per fortnight|disp=unit|lk=in}}	furlongs per fortnight
{{convert|2|foot/s|disp=unit|lk=in}}	foot per second
{{convert|2|mm/s|disp=unit|lk=in}}	millimetres per second
{{convert|2|dog year|disp=unit|lk=in}}	dog years
{{convert|2|kg.m|disp=unit|lk=in}}	kilogram metres
{{convert|2|kgf.m|disp=unit|lk=in}}	kilogram force-metres
{{convert|2|kgm|disp=unit|lk=in}}	kilogram metres
{{convert|2|m.kg-f|disp=unit|lk=in}}	metre kilograms-force
{{convert|2|m.kgf|disp=unit|lk=in}}	metre kilograms-force
{{convert|2|firkin|disp=unit|lk=in}}	firkins
{{convert|2|stere|disp=unit|lk=in}}	steres

Release notes for earlier versions are listed here. Johnuniq (talk) 04:37, 12 February 2018 (UTC)

Thank you. That addresses my initial report and makes many other improvements. Rather than link to sections, we could use existing redirects such as Viss, and create others like Dog year (unit), but that's a minor point and could backfire if someone creates Viss, Hungary. A good final check would be to preview Energen with the new Module:Convert/data and check that it links to Power (physics) rather than the dab Power. (It would be nice if mortals could preview module changes with Save disabled...)

Also on Energen, did we have any thoughts as to whether GJ/ks is a sensible unit or if it should be rephrased as something like MW? Certes (talk) 10:35, 12 February 2018 (UTC)

I just edited Energen to tell convert to use MW as the output unit, and I first previewed the page using {{convert/sandbox}} to confirm that the links will be good once the module is updated. Johnuniq (talk) 21:28, 12 February 2018 (UTC)

The new version is now live. Johnuniq (talk) 02:00, 16 February 2018 (UTC)

Problem converting long tons to metric tons

I've come across a problem with the weight conversion template; it doesn't seem to like converting long tons to metric tons in multiples of 100. For example, 100 long tons (100 t) while the true value is 102t (though 101 long tons (103 t) is accurate); 1,000 long tons (1,000 t), should be 1016t (and likewise 1,001 long tons (1,017 t) is correct); 10,000 long tons (10,000 t), should be 10,160t, and so on. It also seems to round up in a funny way; 45,000 long tons (46,000 t), when the correct value should be 45,722t. Is there a reason for this? Xyl 54 (talk) 23:21, 18 February 2018 (UTC)

Use {{Long ton}}? -DePiep (talk) 23:45, 18 February 2018 (UTC)

(edit conflict)I think you'll find the "problem" is in the way convert rounds to the quoted number of significant figures. 100 tons is 100 to 1 sf, which is indeed 100 tonnes (in both cases 100 ± 50). 101 tons is 103 tonnes to 3 sf (ie 101 ± 0.5 -> 103 ± 0.5). Likewise 1,000 is to 1 sf, 1,001 is to 4 sf. Martin of Sheffield (talk) 23:46, 18 February 2018 (UTC)

As mentioned, the issue is that convert rounds the output to have a precision that agrees with the number of significant figures in the input. One way to specify the rounding is:

• {{convert|1000|LT|t|0|abbr=on}} → 1,000 long tons (1,016 t)

Johnuniq (talk) 02:31, 19 February 2018 (UTC)

Well, the problem was that the template was showing a weight conversion that was confusing and incorrect (and I suppose I could have chosen better examples to illustrate that; comparing 100 long tons (100 t) to 99 long tons (101 t) for example). If the reason is that various values are displayed to different sfs, then the question becomes, why? Why not have them all display to the same level of accuracy?

But thank you for the explanation, and for the advice on specifying the rounding, thank you, that was useful, and I have done that (here) to good effect. Xyl 54 (talk) 02:54, 20 February 2018 (UTC)

The why comes from considering, for example, what {{convert|12000|mi|km}} should display. Showing 12,000 miles (19,312 km) would be silly because the km value would have false precision. Convert cannot know whether 12000 means ±500 or ±0.5. Johnuniq (talk) 04:05, 20 February 2018 (UTC)

comma parameter

The |comma= parameter name is a misnomer. It says what separator must be used; it may be omitted, be a comma (the default), be a gap, and additionally can be suppressed in a 4-digit value. For understandibility, I suggest renaming this parameter to |separator=. There are only 182 articles with |comma=off, |comma=gaps or |comma=5, so complete manual replacement will be easy. —Quondum 03:17, 21 February 2018 (UTC)

Simplicity is good and so is brevity. Conceptually, a lot of things in the output of a convert could be regarded as "separators". There is the gap between the number and the unit, something between the input and the output, and something between multiple outputs if present. The word "comma" obviously has something to do with commas, and people who use convert a lot are familiar with it by now. By the way, it is best not to use markup in a section heading because it makes linking to the section difficult. Johnuniq (talk) 04:55, 21 February 2018 (UTC)

"separator" might not be a good word for the ambiguity reasons you give, but "people who use convert a lot" is not who we should be consider when naming parameters; they only need to be considered in terms of how long to remain supporting the old name. And as I pointed out, the number of uses of this parameter is a (very) small number, so I don't think we have an issue here. The problem with "comma" is also its ambiguity – it will be confusing to the new user. And, contrary to what you say, I think nearly all editors seem to fall in to the new user category for this parameter from the numbers – even veteran users of {{convert}}. Maybe another name? The template {{val}} uses |fmt=commas, |fmt=gaps and |fmt=none, and uniformity across multiple templates with the same idea has definite value. Or are you too set against changing it? —Quondum 18:17, 21 February 2018 (UTC)

I am with Johnuniq in this. Don't blame me for repeating stuff ;-) :

As J described & motivated, the new parameter name should be more like |thousandseparator=. Exampling {{Val}}'s |fmt= is wrong for similar reasons: there are dozens of format settings to be set and handled in {{Convert}}; and as you know that can not and should not be done through one parameter. There is no issue with |comma= at all (just your search for a formally perfect name). In values in an English encyclopedia, "comma" has one single main meaning, and exactly that is what this one is handling. Note that earlier overlaps & confusions, indeed, were phased out years ago.

I see no gain in changing |comma= into |thousandseparator=. Even documentation would not be improved. - DePiep (talk) 19:32, 21 February 2018 (UTC)

The logic here seems not entirely consistent. However, whatever the benefit of a change (if any), it is clear that my suggestion is not getting any support, and because it has not resulted in any reasonable suggestions that would actually achieve the original purpose, I agree that it would be pointless to pursue a change. —Quondum 23:15, 21 February 2018 (UTC)

obscure abbreviation

Who decided to use 'kn' for 'knots' rather than 'kt'? 24.143.10.70 (talk) 03:17, 22 February 2018 (UTC)

"kt" is the SI abbreviation for "kilotonne" and so conflicts with using that same abbreviation for knots, regardless of its use in aviation, so we settled on "kn" as the solution. - Ahunt (talk) 03:23, 22 February 2018 (UTC)

The article Knot (unit) also says: "The ISO Standard symbol for the knot is kn." Thus, it might not be entirely "obscure". —Quondum 03:42, 22 February 2018 (UTC)

Linkages

Some units of measure, like kiloparsecs or the light year, may be unfamilar to non-experts and should be linked. -Inowen (talk) 23:08, 23 February 2018 (UTC)

Yes, but that is something editors control with the lk option: |lk=in or |lk=out or |lk=on. The unit is not automatically linked because it may appear multiple times in an article, and should not be linked in every occurrence per WP:OVERLINK.

• {{convert|12.3|kpc|lk=on}} → 12.3 kiloparsecs (40 kly)
• {{convert|12.3|ly|lk=on}} → 12.3 light-years (780,000 AU)

Johnuniq (talk) 23:18, 23 February 2018 (UTC)

Template quirks

I noticed some odd behaviour:

{{convert|1|km||abbr=~|order=flip}} → 0.62 miles (1 km) (unit symbol of right quantity placed with unit name of left quantity)

{{convert|1|m||abbr=values}} → 1 (3 ft 3 in) (fails to omit unit for output quantity)

—Quondum 20:33, 24 February 2018 (UTC)

Thanks, I'm sure that exhaustive testing would find several other quirks. I think I'll fix the first by ignoring option abbr=~ when used with order=flip. That's a bit crude but abbr=~ is used only 24 times in 2.7 million converts, and none of the occurrences also use flip. The workaround will be in the next release, quite a long time from now.

I was aware of the second problem. When thinking about it during development I decided it would be painful to implement abbr=values for combination output units like ftin because they are handled with different code which already has lots to do. I decided to call it a feature because showing (3 3) instead of (3 ft 3 in) would probably not be useful. I'm not in favor of documenting every quirk although I suppose it could be noted somewhere if felt essential. Long documentation becomes unhelpful. Johnuniq (talk) 23:25, 24 February 2018 (UTC)

I wasn't trying to say anything needs doing, though I would prefer the definition, documentation and implementation all simplified into a very simple general structure. Dealing with "undefined" things in an arbitrary way is fine. Finding the quirks is only really useful as knowledge to use for simplification. Part of my tweaking of documentation is to try to understand what convert does; at the moment there are cases where I cannot determine from the wording what it will do (hence the experimentation). Having parameters affecting independent things is a nice goal (orthogonality). But this is just my own style and preference. —Quondum 02:13, 25 February 2018 (UTC)

Degrees per foot of span

At Adaptive compliant wing there is a need to convert "1° per foot of span" to "per metre" or "per metre of span" (either is fine). No matter which options I've tried I've not managed to get it right. The closest I've got is:

{{convert|1|/ft|/m|disp=preunit| of span|adj=mid|°|abbr=off}} → 1 °-per-foot of span (3.3 °-per-metre)

which is not too far off, but not right. I'm guessing there is either something really obvious I'm missing or this is not actually possible at all! Thryduulf (talk) 00:52, 27 February 2018 (UTC)

Unfortunately, convert cleverly inserts a space because that is what is needed almost always (it does not insert a space before "+" to allow things like "5+ feet"). I don't think it is worth adding degrees as an exception at the moment, so instead offer a workaround:

1°-per-foot of span ({{convert|1|/ft|/m|disp=number}}°-per-metre) → 1°-per-foot of span (3.3°-per-metre)

Johnuniq (talk) 02:59, 27 February 2018 (UTC)

The template does not support conversions involving angle? I don't see it even mentioning the lack of support for this. —Quondum 13:51, 27 February 2018 (UTC)

Angles have been mentioned in the past but no one (apart from the OP here) has presented an example of a useful conversion. Radians has been mentioned but math editors have pointed out that often articles want to specify an angle as an exact multiples of pi, but rarely as a conversion with decimal fractions. Johnuniq (talk) 21:33, 27 February 2018 (UTC)

I tend to forget that {{convert}} is only needed in some circumstances. Decimal radians per metre and radians per second, as well as degree measurements, are commonplace in engineering and physics. However, these contexts tend to be mutually exclusive, and conversion is thus not typically of interest. In mathematical contexts, as you say, exact values are of interest. If there is no demand, I guess there is no point in expecting it to be supported. —Quondum 00:44, 28 February 2018 (UTC)

Interesting to note is that, in the OP example, the degrees are dimensionless. So they do not work in the calculation. This shows in the workaround: the number can simply be the number of degrees, "1" here, and the calculated outcome is correct (just ft and m are at work). Remaining issue is adding the unit symbol -nospace-° and overall formatting. The same applies to unit "$" (as in: $/acre conversion to $/km², {{Convert}} covers). OTOH, degree calculation is required when (a) radians-to-degrees or (b) deg-min-sec, ° ' '', appears, like with non-decimal ftin (actually: non-radix scale). - DePiep (talk) 09:24, 28 February 2018 (UTC)

I took "1° per foot of span" to mean "one degree of angle per foot of span", as opposed to, for example, "one degree Celsius per foot of span". Including the words "of angle" means that it now has a dimension, since it may be converted: 180/π degrees of angle = 1 radian, and radians are a defined SI unit. So the OP's phrase could probably mean "180/π radians per foot of span". --Redrose64 🌹 (talk) 11:37, 28 February 2018 (UTC)

Yes degree is a unit all right, but it is a dimensionless unit. The physical quantity "angle" has no dimension (one may say: "1"). SI dimensions appear like this: "speed has dimension length/time": v has dim L · T⁻¹. In any quantity (measurement) the rule is: dimension LH side must be dimension RH side. So far, no unit is involved, and even ftin may apply. Then, in the RH side the unit cqan be entered which must have the right dimension (but one is free to choose any complying unit: km/h or mm/s).

Point is not to confuse "unit" with its "dimension" (and to keep in mind: the quantity has a dimension too, while no unit). - DePiep (talk) 12:45, 28 February 2018 (UTC)

Though the unit degree can be considered dimensionless, it is not coherent. Thus, it introduces a multiplier that is not 1. The only reason this workaround works is because ° is balanced in input and output. —Quondum 16:06, 28 February 2018 (UTC)

Not "considered", "defined". What do you mean by 'not coherent', 'multiplier', 'balanced'? I tried to note that because degree is dim-less, the numerical workings in {{Convert}} are still fine. Were it having a dimension, it could be required to add a definition to get the number right. IOW, there is no such workaround for "Swedish foot/ft of span" because Swedish foot has a dimension (Length). BTW, my note was for theoretical interest only. - DePiep (talk) 17:07, 28 February 2018 (UTC)

(Yes, this is a side track, only for theoretical interest.) Let us suppose that a unit named degree (symbol °) were supported by {{convert}}. A good default unit to convert to would be radian (symbol rad). The radian is a coherent unit (multiplier 1), whereas the degree is not coherent (multiplier π/180). That is to say, rad = 1, and ° ≈ 0.0174532925. This is all totally standard and within SI. An example of where ° is not balanced (i.e. not present in both input and output): if I were to try {{convert|1|°/ft|/m}}, I would expect the result to be 0.057 m⁻¹. Angle is defined as dimensionless in SI, but not universally – that is why I use the phrase "can be considered". —Quondum 17:32, 28 February 2018 (UTC)