Jump to content

Template talk:Convert

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
... in conception
... and in reality

1 g of something from each m²

[edit]

In dust devil I've found this statement: 1 gram of dust per second from each square metre (10 lb/s from each acre). Is there a workaround to use {{convert}} in this case?-- Carnby (talk) 13:44, 11 April 2026 (UTC)[reply]

How about {{convert|1|g/s/m2|lb/s/acre}} : 1 gram per second per square metre (8.9 lb/s/acre) -- WOSlinker (talk) 17:30, 11 April 2026 (UTC)[reply]
If you want to keep the verbose version of the SI value (probably a good idea in this case), you could use "|disp=out |abbr=off": 1 gram of dust per second from each square metre (8.9 pounds per second per acre). Indefatigable (talk) 17:50, 11 April 2026 (UTC)[reply]
{{convert|1|g/s/m2|lb/s/acre|abbr=off}} displays as: 1 gram per second per square metre (8.9 pounds per second per acre)  Stepho  talk  05:36, 12 April 2026 (UTC)[reply]
I wrote this: {{convert|1|g/s/m2|lb/s/acre|-1|abbr=off}} yielding "Field experiments indicate that a dust devil can lift 1 gram per second per square metre (10 pounds per second per acre) of dust on the ground over which it passes." Does it soundlook good?-- Carnby (talk) 13:09, 13 April 2026 (UTC)[reply]
Looks good. Although I think the correct grammar is "off the ground".  Stepho  talk  21:52, 13 April 2026 (UTC)[reply]
Right, thank you.-- Carnby (talk) 04:01, 14 April 2026 (UTC)[reply]

Rounding method

[edit]

Which rounding method does the template/module implement? Is it PHP's round? (In that case, which RoundingMode?) I imagine there might be some special cases. Could this be documented at Help:Convert? TheFeds 22:13, 15 April 2026 (UTC)[reply]

Convert rounds half away from zero using custom code (not PHP). The convert system is the common usage meaning of "round" so I think documenting it would just bloat the already over-sized page and cause confusion because many people would be unaware that other methods existed. Johnuniq (talk) 06:48, 16 April 2026 (UTC)[reply]

Multiple output

[edit]

Right now many Canadian airports contain something like {{convert|1.5|NM||lk=in}} giving 1.5 nautical miles (2.8 km; 1.7 mi). But when using |order=flip, like this {{convert|1.5|NM||lk=out|order=flip}} you get 2.8 kilometres; 1.7 miles (1.5 NM). Is there any way to get either the kilometres or miles, depending on the article, inside the brackets? CambridgeBayWeather (#1 deranged), Uqaqatigijaa (talk), Huliva 04:31, 17 May 2026 (UTC)[reply]

Not really. You can use order=out to do what you want, but also linking NM is a problem. The closest is:
  • {{convert|1.5|NM|mi km NM|lk=out|order=out}} → 1.7 miles (2.8 km; 1.5 NM)
With order=out, the input is used for the conversion but is then ignored. The displayed input is the first unit in the output. If really needed, there could be a new unit NMlk which was the same as NM but had a link built in to the symbol and name. That is done for unit chain which also has chainlk. Johnuniq (talk) 06:02, 17 May 2026 (UTC)[reply]
Thanks. I figured that there was some way to do it but I just couldn't see it. Linking the nautical miles is important because most people don't use it. CambridgeBayWeather (#1 deranged), Uqaqatigijaa (talk), Huliva 06:08, 17 May 2026 (UTC)[reply]
Please link to, say, three articles where NMlk would be useful and the unit can be added. That is, if linking km as above is a problem. Johnuniq (talk) 06:15, 17 May 2026 (UTC)[reply]
Cambridge Bay Airport, Inuvik (Mike Zubko) Airport, Dawson City Airport, and there's 100's more Canadian airports that will have it. I'm not sure that linking kilometres is a problem but it probably falls under Wikipedia:Manual of Style/Linking#What generally should not be linked item 3 "Common units of measurement". CambridgeBayWeather (#1 deranged), Uqaqatigijaa (talk), Huliva 06:23, 17 May 2026 (UTC)[reply]
I added NMlk:
  • {{convert|1.5|NM|mi km NMlk|order=out}} → 1.7 miles (2.8 km; 1.5 NM)
Johnuniq (talk) 06:35, 17 May 2026 (UTC)[reply]
Thanks. CambridgeBayWeather (#1 deranged), Uqaqatigijaa (talk), Huliva 06:46, 17 May 2026 (UTC)[reply]
Pinging @10mmsocket
Surely the question is "what is the relevance of nautical miles?". I understand that in aeronautical publications, this is the preferred unit of measure, but Wikipedia is not an aeronautical publication. It would be the same as identifying the Belair Stud as being 9+12 furlongs (1+316 mi; 1.9 km) from the nearest 7-Eleven store. A case of horses for courses? As I have also observed, if it was anything other than an airfield, such as a parkland, or a large town, we wouldn't hesitate to unload a unit of measure that is alien to most readers of Wikipedia. However I do recognise that the original data often comes in the form of NM, so I looked for a solution that included that aspect.
My solution, as already described in this discussion is a variant of the convert template as follows...

{{convert|5|NM|mi km|0|order=out}} starts with 5 NM but outputs 6 miles (9 km)
or, with a little bit of tweaking
{{convert|5|NM|0|abbr=in|order=out}} outputs metric first i.e. 9 km (6 miles)

The other bonus here is that everybody recognises both miles and km, and we no longer need a link to explain "NM".
WendlingCrusader (talk) 13:15, 17 May 2026 (UTC)[reply]
Yup. I'm 100% with you. Distance in NM can be sourced if necessary, but displaying it is just not needed. 10mmsocket (talk) 20:02, 17 May 2026 (UTC)[reply]

Not playing nice with visual editor?

[edit]

If I edit:

{{convert|12.75|±|0.02|km2|sigfig=3}}

with the Visual Editor I get a mess. It comes up with From unit = "±", To units = "0.02", and Precision of suffix = "km2". Is this a problem with VE, or a problem with the template? RoySmith (talk) 17:17, 24 May 2026 (UTC)[reply]

@RoySmith: Neither, it's a problem with the definitions at Template:Convert#TemplateData, which presumes that the first four positional parameters will only take on certain roles. In other words, it's not flexible. --Redrose64 🌹 (talk) 21:15, 24 May 2026 (UTC)[reply]

English variety

[edit]

Would it be possible for this template to use American English spellings by default in articles with {{Use American English}}? A Wondrous Raven (talk) 19:29, 31 May 2026 (UTC)[reply]

This has been suggested before, see August 2023 and December 2025. As can be seen in my replies, I do not think individual modules should roll their own method of detecting page-wide options such as "Use X English". Convert could do what was wanted If there were a way for a module to read such data efficiently and reliably. Preferably, the method would work, or at least not cause problems, on Wikipedias in other languages because dozens of sites use convert. The issue should be raised as a wishlist request for the WMF to resolve, but see WP:COMMTECHGATE. Johnuniq (talk) 01:49, 1 June 2026 (UTC)[reply]
Ah, okay. A Wondrous Raven (talk) 02:12, 1 June 2026 (UTC)[reply]
Technically I suspect it would be easy for a bot to set convert to use sp=us on articles that are tagged with {{Use American English}}, however whether there would be consensus for that task is a different question I would not like to predict the answer to. Thryduulf (talk) 09:39, 1 June 2026 (UTC)[reply]
That's an interesting thought. A bot could use Category:Use American English which would work well (modules cannot access page categories). At one point, WP:AWB was set to include certain changes to convert when doing its routine changes. I haven't noticed that in recent years and don't know if it is still used. If not done with other edits, a bot might hit a lot of articles. It should avoid changing converts with abbr=on for simplicity and to reduce the number of changes. Johnuniq (talk) 10:27, 1 June 2026 (UTC)[reply]
For the same reasons a bot also shouldn't add the parameter when British and US English are the same, e.g. lbs ↔ kg, ft → m when abbreviation is not "in" or "off". That could get quite complicated though. Thryduulf (talk) 23:43, 1 June 2026 (UTC)[reply]
Things could go wrong. Sometimes editors go on a tear of adding {{Use American English}} to many articles inappropriately (seen it, rolled it back, got the T-shirt). If a bot adjusted the uses of Convert before any caught it, that'd survive rollback of the template additions and nothing would cause the bot to self-revert. NebY (talk) 14:10, 2 June 2026 (UTC)[reply]
A maintenance bot could look for the addition or removal of such templates and add/remove the sp=us parameter after a delay to allow for quick rollbacks, etc. There are multiple bots that work like this for other tasks. Thryduulf (talk) 14:17, 2 June 2026 (UTC)[reply]
I did not know (/think of) that. Thank you! NebY (talk) 14:19, 2 June 2026 (UTC)[reply]
It should be technically possible in the same way that {{cite web}}, et al., can figure out how to format dates in articles when there is {{use mdy dates}} or {{use dmy dates}} present. Imzadi 1979  01:11, 2 June 2026 (UTC)[reply]
There should not be wholesale changing of British English to the American variety with this template. See[[1]]. I have just reversed an edit of an article that I started. This template was added, even though there were no American spellings in it. The American version of English has no automatic superiority. This template seems to be a way of imposing this imaginary superiority.JMcC (talk) 23:06, 6 June 2026 (UTC)[reply]
The template being incorrectly placed is a separate issue that is at best tangential to what is being discussed here. All articles with the {{Use American English}} tag should use American English, all articles with the {{Use British English}} tag should use British spellings - otherwise there would be no point in those templates existing. If you believe an article uses the wrong tag then correct it and/or discuss it like with any other change to the article. Thryduulf (talk) 00:21, 7 June 2026 (UTC)[reply]

Suggestion

[edit]

I was thinking it would be helpful to modify the description of the Abbreviation field to a bulleted list, as follows. The purpose would be to make it easier for users to more quickly parse and understand the available options.

Display for the units:

  • “on” to display all units using their unit symbols
  • “off” to display all units in full words
  • “in” to display the unit symbol for the input unit
  • “out” to display the unit symbols for the output units
  • “unit” to display unit symbols for both input and output units when using scientific notation
  • “values” for no units at all (neither unit symbols nor full words of units)


It might be further modified for better appearance:

Display for the units:

  • on – displays all units using their unit symbols
  • off – displays all units in full words
  • in – displays the unit symbol for the input unit
  • out – displays the unit symbols for the output units
  • unit – displays unit symbols for both input and output units when using scientific notation
  • values – displays no units at all (neither unit symbols nor full words of units)


It could possibly be consolidated as follows, though I don't know if that's better; just brainstorming here.

Display for the units:

  • on/off – displays all units using their unit symbols (on) or full words (off)
  • in/out – displays the unit symbol for the input or output unit
  • unit – displays unit symbols for both input and output units when using scientific notation
  • values – displays no units at all (neither unit symbols nor full words of units)


Any thoughts? abcasada (talk) 19:36, 23 June 2026 (UTC)[reply]

Are you referring to the Template:Convert#TemplateData section with description starting "Display for the units"? I like the compact alternative (the last above) although I have no idea how it would look to editors. However, the description for abbr=unit is not right. The most accurate documentation is probably the comment "abbr=on but abbreviate units only: e6km → million km (not ×10⁶ km)" in Module:Convert/text. The release note is another reliable source: Template talk:Convert/Archive September 2016#Module version 15. Also, I would suggest "name" rather than "full words". Johnuniq (talk) 06:15, 24 June 2026 (UTC)[reply]

Accept units like ºC as an alias for °C

[edit]

Description of suggested change: proposing adding support for informal homoglyph U+00BA º MASCULINE ORDINAL INDICATOR to automatically redirect to the typographically recommended U+00B0 ° DEGREE SIGN for the temperature units.

Diff:

+
["ºC"] = { target = "C", }, ["ºF"] = { target = "F", }, ["ºR"] = { target = "R", },

 Juwan  🕊️🌈 09:13, 24 June 2026 (UTC)[reply]

The proposal is that new units ºC and ºF and ºR be accepted as aliases for temperature units °C and °F and °R. I refactored your comment because proposals here are considered before moving to implementation. Another point is that the place to add trial units would be Module:Convert/extra which does not need an edit request. Any thoughts from others? I've never encountered º. Is there an article where someone tried to use that alternative? Johnuniq (talk) 09:26, 24 June 2026 (UTC)[reply]
that is correct. the ordinal symbol wouldn't be encountered too onwiki, often because it will be copyedited away, but it is certainly used elsewhere, especially for editors that speak Romance languages as many of them have the ordinal symbol on their keyboard but not the degree one (or not as easily accessible).  Juwan  🕊️🌈 09:32, 24 June 2026 (UTC)[reply]
Convert defines 750 units and another 296 aliases for units. That complexity makes people here reluctant to add more without good reason based on examples. Choice can be good but too much choice can cause confusion because someone trying to use convert is going to wonder "What should I do?". If someone uses the proposed unit code, others will end up copying it. What would be better would be to let editors know that they should use C if they want °C. They sooner they learn that, the better. Anyway, I'm going to wait to see if other people have an opinion. Johnuniq (talk) 09:57, 24 June 2026 (UTC)[reply]
It might be better to say that many primarily Portugese- or Spanish-speaking editors may have keyboards which have the symbol (Ordinal indicator#Typing tells us Portuguese and Spanish keyboard layouts are the only ones on which the characters are directly accessible through a dedicated key). I do rather agree that the simplicity of using C is to be encouraged, benefiting editors glancing over or correcting article source too. NebY (talk) 10:45, 24 June 2026 (UTC)[reply]
The ordinal indicator is different from the degree symbol. Their Unicode values are, respectively, 'MASCULINE ORDINAL INDICATOR' (U+00BA) and 'DEGREE SIGN' (U+00B0). These display as º and ° which, depending upon machine, operating system, installed fonts and browser, may display identically or differently. On my Dell/Windows/Firefox setup, they're noticeably different - º is oval and taller, ° is circular and smaller. --Redrose64 🌹 (talk) 20:03, 24 June 2026 (UTC)[reply]
On Apple ipad/ios/safari, they're only distinguishable when zoomed out. Curiously, when inside <code>...</code> tags, 00ba is underlined, 00b0 is not. --Redrose64 🌹 (talk) 20:15, 24 June 2026 (UTC)[reply]
As a side question, why is {{Text diff}} being used? These are not text changes; the sandbox should be used to show the desired change; this will also allow direct testing. --Redrose64 🌹 (talk) 20:21, 24 June 2026 (UTC)[reply]
short and boring answer: the template is part of the preloaded code and I didn't want to bother since it's just adding items to a list.  Juwan  🕊️🌈 20:55, 24 June 2026 (UTC)[reply]