Misplaced Pages

Revision as of 08:39, 21 November 2013

view · edit Frequently asked questions Q: When using {{convert}} why does the answer sometimes seem a bit off? A: This template takes into account the precision of the supplied value and generally rounds the output to the same level of precision. If you need to change from the default output precision, see rounding. Note: This can cause whole numbers that end in one or more zeroes to be converted less accurately than expected. Q: What are all the possible units (kg, lb, m, cm, ft, in, °C, °F, km, mi, nmi, mph, km/h, and so on)? A: See Help:Convert units for an introduction and Module:Convert/documentation/conversion data for the complete list. Q: I've been using Convert for some time and am pretty comfortable with its basic features. Does it have other features which it would be worth my while to learn about? A: Almost certainly. Start with Help:Convert. For more, see the FAQ.

Archives

2007 January–October November December 2008 January February March April May June July August September October November December 2009 January February March April May June July August September October November December 2010 January February March April May June July August September October November December 2011 January February March April May June July August September October November December 2012 January February March April May June July August September October November December 2013 January February March April May June July August September October November December 2014 January February March April May June July August September October November December 2015 January February March April May June July August September October November December 2016 January February March April May June July August September October November December 2017 January February March April May June July August September October November December 2018 January February March April May June July August September October November December 2019 January February March April May June July August September October November December

This page has archives. Sections older than 21 days may be automatically archived by Lowercase sigmabot III when more than 2 sections are present.

C-change

Just curious but is {{Convert|3|-|4|C-change|0}} supposed to give 3–4 °C (5–7 °F)? In context, "He goes on to say that the temperature in the Arctic region has increased by 3–4 °C (5–7 °F) within the last half century.", it looks odd. CambridgeBayWeather (talk) 04:27, 2 November 2013 (UTC)

I don't know if this was a personal quirk of my chemistry teacher in high school or not, but she always taught us that 3°C was a temperature, but the change was 3C° (degrees Celcius vs. Celcius degrees). I've yet to find anyone else use that inverted format to denote a change, but we have to indicate it somehow to remove the ambiguity because the two scales have different zero points. Imzadi 1979 → 04:52, 2 November 2013 (UTC)

That seems logical, as an obvious difference between degrees C and C-change (reversed "C°"), so I have started searching sources for "Celsius degrees". Over the years, this topic has not been discussed much here. -Wikid77 06:04, 2 November 2013 (UTC)

Celcius#Temperatures and intervals mentions that the reversal of characters is sometimes used but that it is non-standard - so it doesn't help many readers for disambiguation and some editors may complain about it being non-standard. I don't think there is any need for change. As long as the text has something like 'increased by', 'decreased by', 'changed by' or similar then the reader knows we are talking about a change, ie an interval.  Stepho  talk  06:53, 2 November 2013 (UTC)

But if the word "change" is going to be used in the example above why is it not in {{Convert|100|C-change|0}} 100 °C (180 °F)? Ah, just thought if the convert is supposed to use the word "change" then I should be asking at the reference desk why it is done like that. CambridgeBayWeather (talk) 15:12, 2 November 2013 (UTC)

I'm sorry, I don't understand your question. Could you give a concrete example?  Stepho  talk  22:54, 2 November 2013 (UTC)

• Temperature ranges differ from single-amount format: The addition of the word "change" (in the output of a range) is a new development, not seen in the single-amount conversions. That is the difference:

• {{convert|20|C-change|0}}        → 20 °C (36 °F)
• {{convert|20|-|21|C-change|0}} → 20–21 °C (36–38 °F)

Again, over the years, this topic has not been discussed much here, so I just inserted the word "change" as a reminder. I have fixed "adj=mid" to allow more text, to note the interval:

• {{convert|20|-|21|C-change|0|adj=mid|higher}} → 20–21 °C higher (36–38 °F)
• {{convert|20|-|21|C-change|0|adj=mid|Δ}} → 20–21 °C Δ (36–38 °F)

Those are some possibilities. -Wikid77 00:38, 3 November 2013 (UTC)

Thanks. That makes more sense. CambridgeBayWeather (talk) 16:36, 3 November 2013 (UTC)

Tooltips, another option for "abbr"

To my knowledge, there are essentially two options for the abbr parameter of this template right now.

1. {{convert|12345|btu|MJ|abbr=off}} produces 12,345 British thermal units (13.025 megajoules)
2. {{convert|12345|btu|MJ|abbr=on}} produces 12,345 BTU (13.025 MJ)

So how about adding a third option that uses abbreviations but adds tooltips, i.e.

3. {{convert|12345|btu|MJ|abbr=tt}} produces 12,345 BTU (13.025 MJ)

Using template {{abbr}}. A good idea, or not? --bender235 (talk) 10:21, 2 November 2013 (UTC)

• People prefer lk=on as wikilink units: The tooltips option has been suggested before, and the comment was to just use "lk=on" to wikilink the unit symbols, for mouseover of names, but also consider "abbr=~" as follows:

• {{convert|20|BTU|MJ|abbr=on|lk=on}} → 20 BTU (0.021 MJ)
• {{convert|20|BTU|MJ|abbr=~|lk=out}} → 20 British thermal units (0.021 MJ)

By using "abbr=~" in a prior conversion, then the reader will be prepared for the unit symbol later. However, the tooltips idea is an interesting concept for other cases. -Wikid77 00:38, 3 November 2013 (UTC)

(ec)There was a related discussion here. Included there is the fact that abbr can have values: off, on, in, out (and a couple of other rare values). The syntax for formatting needs some serious review, but abbr=tt would probably be ok as meaning abbr=on with a tooltip (both input and output units shown as symbols, with the unit names as a tooltip. We would need some enthusiastic support before trying to implement that. Johnuniq (talk) 00:47, 3 November 2013 (UTC)

Refresh my memory, how is it done?

For Atlantic Shore Line Railway {{convert/spell|4|mi}} Template:Convert/spell How does one get the upper case here as in "Four miles"? Peter Horn User talk 22:15, 5 November 2013 (UTC)

Template:Convert/spell is {{convert/spell|4|mi|case=u}} . Imzadi 1979 → 23:30, 5 November 2013 (UTC)

Thanks. Peter Horn User talk 23:44, 5 November 2013 (UTC)

Question

I have noticed that this template is unable to process signs such as "½". Would it be possible to change this? Toccata quarta (talk) 21:34, 6 November 2013 (UTC)

possible, but probably not worth the complexity to string replace them if {{#expr:}} cannot process these either. Frietjes (talk) 23:03, 6 November 2013 (UTC)

• Fractions of form 3+1/2 are recognized in most conversions: To improve readability of small-font fractions, and the consistency in format for rare denominators (such as "4/128"), the preferred format for mixed numbers is "3+1/2" (or "6,705+9/100"), and the number will be displayed in full-size numerals, although fractions in the results are rare, such as with unit-code "ftinfrac" to show feet-and-inches with fractions. -Wikid77 (talk) 01:16, 7 November 2013 (UTC)

Pressure (at least) doesn't seem to allow conversion to 2 output units

I don't know if this is an error, an undocumented feature which sometimes works and sometimes doesn't, or a known feature which doesn't work for all units.

For what it's worth: in the documentation the following example is given, and works:
{{convert|641|acre|ha sqmi|2|lk=on}} ==> 641 acres (259.40 ha; 1.00 sq mi)

But this doesn't:
{{convert|895|hPa|mmHg inHg|abbr=on|2}} 895 hPa (671.31 mmHg; 26.43 inHg)

The abbreviations used are correct:
{{convert|895|hPa|mmHg|abbr=on|2}} 895 hPa (671.31 mmHg)
{{convert|895|hPa|inHg|abbr=on|2}} 895 hPa (26.43 inHg)

It seems to me that showing pressure, in particular, in several units can be useful, as there are several in common use, particularly for atmospheric pressure. Pol098 (talk) 16:33, 9 November 2013 (UTC)

fixed. Frietjes (talk) 17:06, 9 November 2013 (UTC)

Quick! Pol098 (talk) 19:19, 9 November 2013 (UTC)

Is this something that needs the template to be modified unit by unit? I've tried this both ways round; as of now the form that was failing above, {{convert|895|hPa|mmHg inHg|abbr=on|2}}, has indeed been corrected, but the form with the units swapped so inHg precedes mmHg fails.

{{convert|895|hPa|inHg mmHg|abbr=on|1|lk=on}} 895 hPa (26.4 inHg; 671.3 mmHg)
{{convert|895|hPa|mmHg inHg|abbr=on|1|lk=on}} 895 hPa (671.3 mmHg; 26.4 inHg)

This isn't a request from me for this to be corrected; my attitude is simply that I report issues in case it's thought they should be rectified. If for example it has to be done case by case, I shouldn't think it's worthwhile. Congratulations on the ultra-speedy correction of the first issue. Best wishes, Pol098 (talk) 19:49, 9 November 2013 (UTC)

I added the swapped version for you. Yes, there is a separate template for every combination currently in use :( Hopefully this will be fixed in the Lua module :) 895 hPa (671.3 mmHg; 26.4 inHg) and 895 hPa (26.4 inHg; 671.3 mmHg) Thanks! Plastikspork _―Œ 23:01, 9 November 2013 (UTC)

For me? Thanks, but I really didn't want to put you to the trouble, just thought it seemed wrong. If I'd known it was case-by-case I'd not have said anything. Until and unless this works in general, might it not be better to remove the "acre|ha sqmi" example from documentation? Or maybe say that for some (a few? most? hardly any?) units this notation works? It would have stopped me from wasting your time. This is a comment, no need to answer.

Note to anybody reading this: in Plastikspork's comment immediately above, after the ":)" there are two examples of the Lua sandbox version; today it displays error messages, when it is working it will display the result with two parenthesised alternative units. Best wishes, Pol098 (talk) 00:11, 10 November 2013 (UTC)

@Pol098:Real-life issues have meant I haven't had the energy to finish some details to release Module:Convert, but it will be soon...

Lots of combination units like "ha sqmi" are defined, but as noted above, each such combination has to be individually defined. The module allows combinations to be created by joining standard unit codes with "+" signs, as in these examples:

• {{convert/sandboxlua|895|hPa|mmHg+inHg|abbr=on|1|lk=on}} → 895 hPa (671.3 mmHg; 26.4 inHg)
• {{convert/sandboxlua|895|hPa|inHg+mmHg|abbr=on|1|lk=on}} → 895 hPa (26.4 inHg; 671.3 mmHg)

One benefit from sticking to the defined combinations is that they encourage uniformity across articles, but there are far too many possible combinations to define them all. Johnuniq (talk) 01:05, 10 November 2013 (UTC)

would it be possible to simply enumerate all the single-unit outputs with a space (e.g., Irish acre) in the lua module, then assume that the rest are multiple-unit outputs? or would this be too complicated? seems like this could reduce the need for explicitly handling combinations like 'ha acre'. Frietjes (talk) 18:19, 10 November 2013 (UTC)

Convert/show2 and Convert/show3 show any outputs

Among the new wp:wrapper templates, {convert/show2} and {convert/show3} can be used to show any combination of output units. Examples:

• {{convert/show2|895|hPa|mmHg|inHg|abbr=on|1|lk=on}} → Template:Convert/show2
• {{convert/show2|895|hPa|psi|inHg|abbr=on|1|lk=on}} → Template:Convert/show2
• {{convert/show3|895|hPa|psi|inHg|lbf/sqin|abbr=on|1|lk=on}} → Template:Convert/show3

Those wrapper templates are intended to reduce the need for other special subtemplates of Convert. -Wikid77 (talk) 16:45, 10 November 2013 (UTC)

I'd suggest at least a brief mention in the documentation (I may have missed it, but don't think so). I would do it, but am not familiar with what's happening and what's recommended. Best wishes Pol098 (talk) 16:35, 15 November 2013 (UTC)

Proposal for output combination units

There are 66 units that include a space in the unit code. Please see here (permalink) for a list of those units and a proposal to have the module accept user-defined output combinations, based on the suggestion by Frietjes above.

The proposal would allow combinations like "m3 impgal usgal" (any codes which do not contain spaces), but would require "+" when combining codes that contain spaces, like "m3+board feet". That would be easy to achieve and easy for users to understand. The module could get more adventurous and try to interpret "m3 board feet" but the effort does not seem worthwhile. Any thoughts? Johnuniq (talk) 08:45, 11 November 2013 (UTC)

Without having any particular experience in this topic, mandatory use of a "+" seems a good compromise. Alternatives: my background in general (rather than wiki) computing would suggest the underscore character "_", routinely used to indicate a space without being interpreted as a separator. Another computing practice that might work is the use of "double quotes", so long as they don't get interpreted as part of the unit (inches and seconds, often indicated with the double quote character, come to mind). Pol098 (talk) 12:44, 11 November 2013 (UTC)

The underscore would be a good character to use, but for compatibility reasons the module translates each underscore to a space early in the conversion (because, for example, Template:Convert/board_feet works with or without an underscore).

At any rate I have implemented my proposal so Plastikspork's above examples work, as do the following:

• {{convert/sandboxlua|12|km2|acre sqyd ha}} → 12 square kilometres (3,000 acres; 14,000,000 sq yd; 1,200 ha)
• {{convert/sandboxlua|123|cuyd|m3+board feet}} → 123 cubic yards (94 m; 40,000 board feet)
• {{convert/sandboxlua|895|hPa|psi inHg lbf/in2|abbr=on|1|lk=on}} → 895 hPa (13.0 psi; 26.4 inHg; 13.0 lbf/in)

Johnuniq (talk) 10:40, 12 November 2013 (UTC)

possible problem with fractions?

1⁄4 mile (0.40 km) should, if I'm not mistaken, have "mile" singular and only round km to one significant figure. --NE2 00:00, 13 November 2013 (UTC)

this has been debated before, but I don't recall the exact conclusion. I believe that the conclusion was '0.25 miles', and '1/4 of a mile', but I don't recall what the conclusion was for '1/4 mile(s)'. Frietjes (talk) 00:44, 13 November 2013 (UTC)

@NE2: note that you can use {{convert|1/4|mi|adj=1}} to force it to not use the plural. and {{convert|1/4|mi|adj=1|sigfig=1}} for one sigfig. Frietjes (talk) 00:47, 13 November 2013 (UTC)

kW/tonne and hp/tonne

For Sprinter (Victorian train)#Technical {{convert|9.2|kW/tonne|hp/tonne|abbr=on|disp=or}} 9.2 kW/tonne or 12.3 hp/tonne instead of 9.2 kW/tonne or 12.4 hp/tonne. But what about {{convert|9.2|kW|hp|abbr=on}}/tonne 9.2 kW (12.3 hp)/tonne? Peter Horn User talk 03:16, 17 November 2013 (UTC)

Make that {{convert|9.2|kW|hp|abbr=on|disp=or}}/tonne 9.2 kW or 12.3 hp/tonne Peter Horn User talk 03:18, 17 November 2013 (UTC)

• Try Convert/f with x2=/tonne: In cases where the per-unit will be the same for both amounts, then just insert "/tonne" into the conversion, using Template:Convert/f as follows:

{convert/f |9.2|kW|hp|abbr=on|disp=or|x2=/tonne}} → Template:Convert/f

Then just append the extra "x5=/tonne" at the end. Recall options x0-x5:

             12,340 kilometres (7,670 miles)
             |     |          | |    |     |
             x0    x1         x2 x3   x4   x5

While parameters x0 and x1 insert text before or after the first amount, x2 follows the input unit, x3 puts text before the output amount, x4 follows the output, and x5 follows the output unit name.
Convert/f is intended to continue the same format with the Lua version of Convert, while allowing any "/xx" such as per week "/week" or "/year" or "/century" etc. This is the next generation of Convert, along with Template:Convert/text3 for free-form conversions. -Wikid77 (talk) 07:03, 17 November 2013 (UTC)

Thanks, I need to study this carefully. Peter Horn User talk 21:31, 17 November 2013 (UTC)

Add CSS hooks

td .convert       > .en {display: none;}
td .convert:hover > .en {display: inline;}

<span class="convert">
  <span class="si origin">1 m</span> 
  <span class="en target">(39 in)</span>
</span>

This template is used a lot in spec tables, which makes them hard to read. I’d like to hide English units, at least in tables, by means of my user stylesheet, but as far as I can see the output of this template is not wrapped in elements to facilitate that. Could someone please add this? I actually wouldn’t mind if the English value was still accessible within a tooltip. — Christoph Päper 21:54, 17 November 2013 (UTC)

• Perhaps have a Convert/css wrapper template: We could develop a special, customized wp:wrapper template to control the placement of span-tags with the named CSS classes, as a Template:Convert/css. There would be at least 3 CSS classes, to display the input amount, the output amount, and the separator text "(__)". Then, a user could set the input and separator text to "display:none;" so only the output amounts would appear in a large table of conversions. In general, Convert has been designed to display a special format for every combination of options, and so hundreds of Convert subtemplates would need to be changed to show CSS span-tags in every case and avoid expression errors of span-tags in raw numbers shown by "disp=number". However, having {Convert/css}, to use special CSS span-tags, would provide a simple means for hiding parts of the conversions. To hide only the Imperial units, or US customary units, would require complex code to set the CSS classes depending on the unit-code chosen, where "m" would be an SI unit, but "ft" would set the span-tag CSS class for US Customary units. -Wikid77 (talk) 05:32, 19 November 2013 (UTC)

Something new

In Electric heating#Industrial immersion heaters, what would be the metric equivalent and conversion for 40 w/in² & 60 w/in² (or 40 W/in² & 60 W/in² ?) ? Peter Horn User talk 15:40, 19 November 2013 (UTC)

• Let's use /sqin and /cm2 as new unit-codes: The typical conversion of watts to horsepower has been questioned as misleading, so just convert the per-square-inch to per-square-cm. Note:

{convert|40|or|60|/sqin|/cm2}} → 40 or 60 per square inch (6.2 or 9.3/cm)

40 or 60 W/in{sup|2} ({convert|40|or|60|/sqin|/cm2|disp=out}}) → 40 or 60 W/in (6.2 or 9.3/cm)

In many subjects, the reader tends to learn the units, with little need for extra conversions. -Wikid77 (talk) 17:36, 19 November 2013 (UTC)

Thanks. Peter Horn User talk 20:19, 19 November 2013 (UTC)

Request to switch to Module:Convert

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following list: Misplaced Pages technical issues and templates When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

I propose we should migrate convert to use the module Module:Convert now, as it seems it's ready for prime time now. I understand this is a big switch, so please decide wisely :) _→AzaToth 21:49, 19 November 2013 (UTC)

Would you like to try it on Commons first? The version there is not used as much as on Misplaced Pages, but it's somewhat old and has bugs. ghouston (talk) 22:59, 19 November 2013 (UTC)

Note see Template:convert/testcases for some comparisons. Frietjes (talk) 00:29, 20 November 2013 (UTC)

Here is what Johnuniq has to say about it Module_talk:Convert#Status. -DePiep (talk) 07:52, 20 November 2013 (UTC)

I'd rather have him around when the tide comes in. -DePiep (talk) 08:18, 20 November 2013 (UTC)

• Support! I've recovered from a hectic period and have finished working through my to do list. Any time after UTC midnight today would be fine by me, or wait a few days if people want. I've updated Help:Convert and it should act as a quick reference for what is supposed to work. I've put some temporary notes at User:Johnuniq/Convert documentation (mainly the different way that "spell" works). Re Commons: I'd be glad to help get convert working there (it is working at the Bengali wiki, see here), but there are only 1350 converts at Commons, and there may not be many editors who would notice broken results, so the only real test would be going live here. Johnuniq (talk) 09:29, 20 November 2013 (UTC)
  • I've copied what look like the most important module files to Commons and checked that it works at https://commons.wikimedia.org/Template:Convert/sandboxlua. Is there anything else that would need to be done before trying it live? ghouston (talk) 11:00, 20 November 2013 (UTC)
    • @Ghouston: See my comments at commons:Template talk:Convert#Module:Convert. You should be ready to go. Johnuniq (talk) 12:00, 20 November 2013 (UTC)
• Fix mismatches and write transition plan: First, we need to fix the known mismatches (some already fixed), and remember, unlike markup-based Convert, fixing a troublesome unit will require reformatting all pages which use Convert, so perhaps move the troublesome units into Module:Convert/extra to allow updates with reformatting all pages. Note any current mismatches:

• Template:Convert/testcases/bytype/mass - notice any problems of weight/mass

In general, we need to develop a transition plan, such as a 1-week trial period (or longer depending on 3-day reformatting of all pages using Convert), along with a plan to log any detected bugs, then revert back to markup-based Convert until enough mismatches are adjusted for a new "go-live" date. Part of the transition plan could be a "readiness checklist" to ensure each major type of conversion has minimal mismatches, and when ready, then switch to Lua-based Convert. Remember, we will lose the tracking subtemplates, and no longer have Special:WhatLinksHere/Template:Convert/fathom and such, to track usage of unit-codes. Plus, we need to add the new unit-codes into the Lua module, before the first stage of transition. Unlike other Lua modules, there is little benefit to using the Lua Convert, perhaps less than a fifth-second gain, because markup-based Convert is quite fast and used just a few times in most pages. The transition to Lua Convert is mainly a nightmare of potential conversion problems, precision mismatches, and massive slow reformatting of 600,000 pages. -Wikid77 (talk) 09:44, 20 November 2013 (UTC)

I have tried getting editors involved in checking the testcases, but it's tedious. Would anyone who does some checking please review this note I wrote two months ago. Losing "what links here" and the tracking templates is a problem which I have pondered. To at least have a snapshot, I captured "what links here" for each tracking template in the last couple of days, and a list of articles that transclude each unit known to the module a month ago. I understand that's not very helpful, particularly as they are files on a local computer, but it's better than nothing. I have some blue-sky plans for a weekly snapshot, but that may never happen. Johnuniq (talk) 10:27, 20 November 2013 (UTC)

(edit conflict) re Wikid77.

"... allow updates with reformatting" - or without?

Is there a need, a priori, to revert to wikicode after one week? Imagine this scheme. Some 24h after going live, a new version is put live that has some major bugs fixed. So then the whole cache is emptied again, the next three days are for the queue. But not adding up to six days! You can throw a page from the cache only once. That would support early versions (not compromising code quality of course). Maybe at day 3 or 5 another version is ready & needed. OK. Then, we can wait longer when the bug are smaller. The revert-to-wikicode option is an emergency button only.

We should make the agreement that, starting 24h before the Switchover, all old wikicode template code is frozen. That prevents that, when it were needed in a reverse, new differences are introduced from the backup. (This should also prevent doing edits in the old one that were long due, an can be "squeezed in nicely" when it is offline: don't go there). Mirrored, new units in Lua all should go in /extra first weeks, until Lua is stable Or better: do not accept any new unit features during switchover weeks. I propose two-sided feature freeze during switchover weeks. -DePiep (talk) 10:30, 20 November 2013 (UTC)

Well perhaps we should add new unit-codes, at the same time, to both the Lua-based Convert and Template:Convert/old, to allow progress to continue without using Lua as an excuse to halt improvements. -Wikid77 (talk) 15:39, 20 November 2013 (UTC)

Strong advise not to do that. Adding units require "unit tests" (as in: software-units), which are details. Switching over, on the other hand, is a system test. Once doing a system test/rollout, no sane person wants to be surprised by bugs/issues from such newly introduced details.

Also think of what Johnuniq has to face during these switchover days. Trying to get a grip on the new system bugs (the easy ones are caught already, so these are the dirtier, meanly hidden beasts!), he would also have to cope with not-essential details. Trying to cater two running trains is nigh impossible. There better be one leading train at any one time. Time for the wikicode template to pause as leader.

And there is this simple question, Wikid77: why not save these new unit proposals in a fridge for a few weeks, and when the module is stable, put them in /extra. Right when Johnuniq has time to discuss any issue. -DePiep (talk) 17:06, 20 November 2013 (UTC)

Johnuniq, are you gonna request a development freeze of the old template? If so, how long before The Edit (to catch up its latest changes)? Or do you have an other process proposal in this. -DePiep (talk) 04:51, 21 November 2013 (UTC)

I'm thinking that the module should not be changed unless there is compelling reason to do so (that is, to fix a bug), and I do not plan to add features or tweak the code at this stage as fiddling often leads to problems. I see no reason that the convert templates should be changed, but standard procedure is for everyone to do what they want, so I'm not going to object. There are plenty of things in the convert templates that could be addressed (some are here), but working on fixing template bugs seems like a waste of time to me. I have no plans to modify the module to keep it in step with any changes that are made to the templates—any new features can be added later (after a fair bit of planning). Johnuniq (talk) 08:39, 21 November 2013 (UTC)

Excessive rounding in ranges

The default precision of conversions is still causing bizarre results, such as for a range of similar weights:

• {convert|43|-|45|lb|kg}}    → 43–45 pounds (20–20 kg)
• {convert|141|-|142|lb|kg}} → 141–142 pounds (64–64 kg)
• {convert/sandboxlua|141|-|142|lb|kg}} → 141–142 pounds (64–64 kg)

Clearly, a 3-digit amount should produce a 3-digit precision, but even the 2-digit weights should be sensible. There had been similar problems with temperatures, but they have been fixed:

• {convert |105|-|106|F|C}}                 → 105–106 °F (41–41 °C)
• {convert/sandboxlua|105|-|106|F|C}} → 105–106 °F (41–41 °C)

As several users have noted, the rounding tends to be over-rounding, which causes similar amounts to convert to the exact same output number. -Wikid77 (talk) 10:51, 20 November 2013 (UTC)

Wikid77, will you keep this in the fridge during switchover process? Or do you have an other process proposal? -DePiep (talk) 04:32, 21 November 2013 (UTC)

Range x has changed

Following the discussion above, Template:Convert at Commons has been switched to using the module. I have just downloaded the 1300 converts that are used at Commons to check that the module is handling their requirements (and to find any broken converts). I captured the output from each {{convert}} in Special:ExpandTemplates at enwiki, then compared it with the output from the module.

Everything is good (the module matches the templates in use here), except for converts like the following:

• {{convert|9|x|12|in|cm|abbr=on}} → 9 in × 12 in (23 cm × 30 cm)
• {{convert/sandboxlua|9|x|12|in|cm|abbr=on}} → 9 in × 12 in (23 cm × 30 cm)

Note that the module duplicates the symbol (only when abbreviated—it does not duplicate unit names). The templates used to do that! The current discrepancy must be due to a change in the templates since August (I have many "x" converts that I captured in August, and they matched the module).

Is this due to changes at Template:Convert/x/AonSoff and/or others? Was there a discussion? What is wanted? Johnuniq (talk) 03:19, 21 November 2013 (UTC)

I'd say, the module is right, because an area must be expressed in "in × in" (or equal "in". The old tempate suggests it is a length ("in"), which is wrong. Thisa way the non-abbreviated units should be areal too, but that could be postponed till after switchover (because it does replicate the old template "correctly").

As for this change in general, I'd say the module is not required to catch up late changes. The old template should be feature freezed shortly before switchover. Then the module can catch up completely, and can promise equalness. There is no use in keep adding minor incremental changes to the old template, once the module has the lead. As noted above wrt the changeover process. -DePiep (talk) 04:29, 21 November 2013 (UTC)

• Misplaced Pages requests for comment