Template talk:Convert/Archive March 2016

Formatting square kilometres: km² or km2
I have noticed that on Wikipedia sometimes square kilometres and square metres (km2 and m2)

are displayed as km2 and m2; (wikimarkup: km2  and m  2  ), and sometimes as m² and km². (I prefer the latter form (m², km²) which looks neater to me.)

The convert template recognises both forms:

 100 km2  &  100 km² 

which both give same result, which is: 100 km2 & 100 km² (to me 100 km² (39 sq mi) looks more aesthetically pleasing, especially when within text)

For example:

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute km2 irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute km² irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Would it be possible to modify (or give an option to modify) the convert template's output to the m², km² form, simply for reasons of aesthetics?

Kind regards -- Marek . 69    talk  04:41, 3 March 2016 (UTC)
 * @Marek69: The Manual of Style has had a firm rule about this for a long time. That MOS link shows:
 * Write powers of unit symbols with HTML, e.g., 5 km2 not Unicode superscripts and subscripts.
 * I don't recall seeing any dissent from the above in the last couple of years so I don't think convert should change. The place to suggest a change would be at MOS talk because they deal with how units should be written. My feeling is that there would not be any support for a suggestion that 5 km² be accepted as an alternative for 5 km2.
 * By the way, convert outputs a very subtle error message so it is easy to miss problems. A good way to see if the page is ok is to check the hidden categories at the bottom. That requires a setting in your preferences to enable the display of hidden categories. Another method is to search the displayed page for "convert:" (with a colon) because errors start with that text. For example, doing that at São Vicente, Cape Verde currently shows a problem due to the following:
 * → 80 to(–)
 * The reason that fails is that  should use a plain hyphen, not an en dash. Convert expects users generally to type simple text into the template, and convert outputs the correct dash. Another example is that   is accepted as a unit, and I change   to use a plain 2 when I fix converts to help spread the idea that simple text is preferable. Johnuniq (talk) 06:28, 3 March 2016 (UTC)

Converts with ref are broken
As a convenience for users, convert tries to accept input numbers with a reference attached so converts like the following work: That is particularly useful in infoboxes where the number entered may be passed to convert by the infobox—if convert did not extract the reference, infobox-writers and infobox-editors would be required to engage in pointless make-work to enter the reference some other way.

Per this VPT discussion, the devs have once more changed how strip markers work, so there are now many broken converts in articles. I'm posting this to let people know that I will fix the problem and there is no need to report it. I've been frivolously engaged elsewhere so will need significant time to remind myself of convert's status and how to test everything. I will include the changes to the units mentioned at above. Johnuniq (talk) 23:21, 11 March 2016 (UTC)
 * I have uploaded a change to Module:Convert/sandbox. The following demonstrates the issue:
 * → 12.3 km


 * Johnuniq (talk) 08:49, 12 March 2016 (UTC)

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

The changes are: After some testing, I'll update the main modules. Johnuniq (talk) 08:59, 12 March 2016 (UTC)
 * Units:
 * (electronvolt) and  from Module:Convert/extra have been incorporated into the main data module.
 * uses a new symbol per kW-hrs -> kWh for electric cars above.
 * accepts  as a subdivision to replace the   workaround in Module:Convert/extra.
 * There are several minor tweaks to cleanup things like unused variables.
 * The method used to detect strip markers where a reference is embedded within convert has been made more tolerant so it is more likely to accommodate future arbitrary changes to MediaWiki, per Converts with ref are broken above.
 * Done. Johnuniq (talk) 23:52, 13 March 2016 (UTC)

Non-breaking hyphen
I've been updating Comparison of battery types. It would be nice to allow non-breaking hyphens for ranges. If I use {convert|1|‑|2|mi|km|abbr=values|disp=br} (where the dashes are non-breaking dashes) it would be nice if I could rely on my columns not breaking in ugly spots. --Skrapion (talk) 10:20, 29 February 2016 (UTC)
 * Never mind, I just used the nowrap template instead. --Skrapion (talk) 23:39, 29 February 2016 (UTC)
 * I'm glad you have a solution because using Hyphen may not give a satisfactory dash. The following lines show two numbers separated by an en dash (as used by convert), and a nonbreaking hyphen (second line):
 * 2.1–3.2
 * 2.1&#8209;3.2
 * On my system, the dash in the second line is too short, so nowrap is better. Johnuniq (talk) 00:09, 1 March 2016 (UTC)
 * The "dash" in the second line is not a dash at all, it's a hyphen, and is typographically incorrect. (I used to cast lead type for a living) Kendall-K1 (talk) 01:52, 1 March 2016 (UTC)
 * It's also incorrect per MOS:ENDASH. — groll tech  ( talk ) 07:18, 14 March 2016 (UTC)

Scientific notation
Is there a way to suppress scientific notation on output when the order is flipped? I've had a complaint about the "Comparison with Saturn V" table at N1 (rocket) because the "total impulse" row is in scientific notation in one column and not in the other. The source units are SI units in one column, and US units with flipped order in the other. I know how to get scientific notation in both columns but I don't think that's what we want. Kendall-K1 (talk) 14:35, 24 February 2016 (UTC)
 * This is one of the converts at N1 (rocket) which produces scientific notation in the output:
 * → 8153000 kN
 * The reason it is doing that is the value exceeds 1e9 (109). It also does that for very small values (less than 1e-4 = 10−4).
 * Convert will use scientific notation for both input and output (except if the output value is a simple number like 123.4 where scientific notation would be a waste), if e notation is used for the input; example:
 * → 1.7336e9 lbf
 * Apart from those general thoughts, I haven't studied the situation enough to understand what the problem is (has the table changed recently?). Please spell out the problem with an example of a convert and a description of what you would like it to do.
 * By the way,  is deprecated. Please use   instead. Johnuniq (talk) 20:41, 24 February 2016 (UTC)
 * I know about order=flip but old habits die hard. I will try to remember. I do know how to get scientific notation on output, what I don't know is how to get unscientific notation on output in all cases. I think if it were up to me I would just go with scientific notation but other editors object to this. The discussion and some examples are at Talk:N1 (rocket). The table originally had two columns with US units first in one column and SI units first in the other. I changed it so SI units are first in both columns by using disp=flip (sorry). Kendall-K1 (talk) 21:17, 24 February 2016 (UTC)
 * When abbr is not specified, the default is that the output will be abbreviated, and that will use scientific notation for very big or very small numbers. That can't be turned off because it would be pretty strange to have a number like 1,234,560,000 followed by an abbreviated unit. I see you mentioned "million" on talk, and if the values were reasonably uniform using e6 or e9 or others might help, but I don't think it would do what was wanted. If the units were the same in each column, perhaps they could be put in a heading and the units omitted from convert? I know you can do that, but I'll mention that there is an example at Help:Convert. Johnuniq (talk) 00:04, 25 February 2016 (UTC)
 * I didn't know abbr applied to numbers too. I don't see what's so strange about mixing unabbreviated numbers with abbreviated units, but I'll play around with this and see if I can make everyone happy. Thanks. Kendall-K1 (talk) 00:18, 25 February 2016 (UTC)


 * Could show 'billion' instead of x10 form: I would use output unit-code "e9lbf" as with:     {convert|8153000|kN|e9lbf |abbr=off} to give:     8153000 kN That would show word "billion" rather than x10 notation. -Wikid77 (talk) 23:21, 15 March 2016 (UTC)

Mixed input units in a range
In many automobile articles I need to show a range of conversions that have the high and low values in different units. Eg, low value of the range as 80 km and high value as 100 miles. The following works: But is there a better, less cryptic way that non-mathematicians/-programmers can understand easier?  Stepho  talk 03:00, 23 March 2016 (UTC)
 * giving 80 - 100 mi km
 * I can't think of any other way to allow . Would that be wanted because one reference supports 80 km, while another supports 100 miles? Johnuniq (talk) 06:39, 23 March 2016 (UTC)


 * Correct, some references are metric and some are American.  Stepho  talk 08:48, 23 March 2016 (UTC)

Minor corrections
Hello I'm working to localize the data for the italian wiki. I would like to report some minor details I noticed during the conversion:
 * In the power table Cal/h should be "large calorie per hour" not "calorie per hour"
 * In the lenght table shaku should link the specific article Shaku (unit) not the more general Japanese units of measurement
 * The link for "hp-electric" should be Horsepower not Electric horsepower
 * The link Beverage can should be changed to Beverage can
 * The documentation for Module:Convert/documentation/conversion_data/doc do not list the section "Automatic per units" in the list under the heading "Table format/Format"--Moroboshi (talk) 18:24, 28 March 2016 (UTC)
 * Thanks, I'll digest that later and will incorporate the fixes in the next release. I had a look at a few European Wikipedias a year ago and it appeared they had little need for a convert template but it's great if the module is useful, and I see you have done a lot of work. I put a list of links to what I could find at it:User:Johnuniq. Please contact me if you want any help. I hope you are using it:Module:Convert/makeunits to translate the unit names because trying to translate them directly in it:Module:Convert/data will cause trouble. Johnuniq (talk) 00:06, 29 March 2016 (UTC)
 * Thanks to you, it's a great module. Generally in Italy we use SI units for length/weight/time so we don't need to give a distance in miles and km, probably the only Italians who use feet and yards are Dungeons & Dragons player's. However on some articles is useful to give measures both in original and SI units, for example ship displacement/speed/endurance/etc... Furthermore Module:Convert is used also by [[template:Val], so I can upgrade the corresponding italian template.
 * I have localized only Module:Convert/text and Module:Convert/documentation/conversion data/doc (I have moved this to the template namespace in it:Template:Converti/man/Conversion data) and I'm using the makeunits module to generate it:module:Convert/data.--Moroboshi (talk) 10:20, 29 March 2016 (UTC)
 * Excellent! I didn't realize that you had put the name of the master units list in it:Module:Convert/text (very few people have managed to do that!), so I was a bit concerned. A very quick look suggests Convert/text is good, but I suggest you replace the two error tracking categories with just one. We use two here and they are a waste of time. Originally I thought there would be some purpose to trying to separate the different types of errors, but in practice no one cares—mistakes have to be fixed regardless of the category, and it is easier to track one category than two. If you decide to use one category, pick a suitable name and use that for both "unit" and "option" in all_categories. Johnuniq (talk) 10:50, 29 March 2016 (UTC)