Jump to content

Template talk:Convert/Archive September 2016

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


Conversion to inches: fractions, avoiding unnecessary decimals

I have been modifying the unit conversions in articles on trees (working through List of Minnesota trees by scientific name). I am using the |frac= parameter, because tenths, hundredths, and thousandths of inches are meaningless to me and probably other people in the US; rulers are marked in fractions by powers of two. I have no idea how much 0.39 inch is, but I can understand 3⁄8 inch. See for instance this article when it had decimals in the Description section and then after I converted it to fractions

I wonder if it would be possible to make fractions the default, or at least make a setting that would automatically choose the appropriate fraction. For centimeters, I have been using 1⁄4 inches; for half-centimeters or millimeters rounded to 5, 1⁄8 inch; for millimeters, 1⁄16 inch; for half-millimeters, 1⁄32.

It would also be nice if measurements rounded to five or ten centimeters were automatically displayed as whole inches (rather than tenths of inches), because one inch is almost exactly 2.5 centimeters. It is annoying to have to specify a precision of 0 every time that a number like 10 cm gets converted to 3.9 inches rather than simply 4 inches.

I was thinking maybe either fractions could be the default when converting from cm or mm to inches, or there could be a default setting for the |frac= (|frac=default?) that would use a standard set of equivalencies similar to the one I mentioned above. — Eru·tuon 22:33, 3 September 2016 (UTC)

One inch is defined as 2.54 cm. Fractions are never used with metric. I think we are running up against the olde measurements being nearly obselete, but this conversion should not be the default. In other contexts we want the decimal form eg. QF 3.7-inch mountain howitzer or 9.45-inch Heavy Mortar. There is no reason to believe that the fractional form is preferred, when so few people think in chains or furlongs anymore. Hawkeye7 (talk) 23:16, 3 September 2016 (UTC)
Inches and feet may be almost obsolete in Australia, but not in the United States. Hmm, I suppose I am not being very clear. I am proposing that fractions of inches be used when cm or mm are converted to inches. Of course fractions of cm and mm are never used. — Eru·tuon 23:34, 3 September 2016 (UTC)
Despite having used fractions of an inch all my life, I wouldn't support using them in a modern encyclopedia, other than in very specialised areas. Fractions are probably losing traction throughout most fields because of the use of calculators and computers which do routine calculations in decimal format by default. I've used A/F spanners for over 50 years, but I'd still have to think carefully to work out that a 21⁄32 nut is 50% wider than a 7⁄16 one. It's pretty obvious that 660 thou is 50% bigger than 440 thou, though. --RexxS (talk) 23:50, 3 September 2016 (UTC)
Then, I retract my proposal of making it the default (used whenever you type {{convert|number|cm|in}}). It would, however, be helpful if there were an option like |frac=default that could be used in articles on plants. I suppose the parameter name would have to be different: obviously the default would be to convert to decimals... — Eru·tuon
I suppose you know that you can force fractions as output like this: {{convert|0.5|cm|in|frac=16}} -> 0.5 centimetres (3⁄16 in) ? It's documented at Template:Convert/doc #Round to a multiple of a given fraction and might be usable, even if it's not precisely what you want. --RexxS (talk) 00:26, 4 September 2016 (UTC)
That's what I have been using (see for instance this recent diff), and it works well, but it is a bit laborious, since I have to decide which denominator to use. It would save time if I could simply input the same parameter into all conversion templates. ([edit:] It would also standardize the behavior, and if the standardization was done right, give a good result every time even when used by an unskilled editor.) — Eru·tuon 00:52, 4 September 2016 (UTC)
Sorry, I should have read your original post more carefully. What you'd like is to have auto-selection of the value of |frac=, rather than a default? I'd have suggested something like |frac=auto leading to a lookup for the value for frac. Would you want a scheme like: if 'val' is the input value, then: val > 1cm -> |frac=4; 1cm > val > 5mm -> |frac=8; 5mm > val > 1mm -> |frac=16; 1mm > val -> |frac=32? Or is it the least significant figure in the value that should determine the denominator? Either way, it should be feasible. How many articles would benefit from this feature, do you think? --RexxS (talk) 02:32, 4 September 2016 (UTC)
Yes, that sounds like what I mean. |frac=auto would be a better label. Yes, I use the least significant figure, and determine if the value has a significance of 5, 1, 0.5, or 0.1. 1.5-3.5 cm (15-35 mm) would have a significance of 0.5 cm (5 mm), and I would use |frac=8. But 1.4-3.6 cm (14-36 mm) would have a significance of 0.1 cm (1 mm) and I would use |frac=16 (though probably I should be using |frac=32). I would take 13-15 mm as significant to 1 mm, though, because the first number is not rounded to 5. Does that make sense of my process?
Articles about plant species that have measurements would benefit. I don't know how many there are, but there must be thousands of articles on plant species, some fraction of which have measurements. At least several hundreds. (Perhaps an accurate count would be obtained if one could determine which articles have {{Taxobox}} with |regnum=[[Plantae]] and {{convert}} with the |cm= or |mm= parameters.) — Eru·tuon 03:38, 4 September 2016 (UTC)

@Casliber: You write botanical articles and I think I've seen you use converts with fractions such as frac=4. Do you have a comment on the proposal that convert should support frac=auto to automatically determine the denominator from the precision of the value? If implemented, it would allow {{convert|15|cm|in|abbr=on|frac=auto}} and convert would guess whether the denominator should be 2, 4, 8, 16, or some higher power of 2. Bear in mind that convert currently reduces the fraction, for example, if a value would be 1+8⁄16 it is actually displayed as 1+1⁄2. I suppose some (historic?) engineering specification might use 1+8⁄16 to suggest the precision, but I don't think convert should do that. Unfortunately the rounding/precision part of convert is among its trickiest code, and a very clear mind would be needed to work out how to implement this—I imagine there would be some awful corner cases, including things like:

  • {{convert|83.2|to|161.6|cm|ftin|abbr=on|frac=8}} → 83.2 to 161.6 cm (2 ft 8+3⁄4 in to 5 ft 3+5⁄8 in)

Johnuniq (talk) 04:44, 4 September 2016 (UTC)

The only problem I see is intuiting some cases where one would use only a 1/2 inch - I'd hate to see small fractions used there. So I'd be wary of coding like that unless it had some other feature countering that. Cas Liber (talk · contribs) 10:59, 4 September 2016 (UTC)

Output nothing for sample converts using NNNN

Some templates call convert and provide samples like {{convert|NNNN|mm|in|abbr=on}}. If "NNNN" is not replaced with a valid number, convert currently outputs an error message. Instead, the sandbox module outputs nothing.

  • Example: {{convert/sandbox|NNNN|mm|in|abbr=on}} → Example:

I am planning to include that in the next release (soon). Johnuniq (talk) 07:52, 24 September 2016 (UTC)

I've done a bit more checking. The only examples I had seen used "NNNN" (four N), but searching found a couple of templates using "NNN" (three N). I plan to take three or more "N" as an indication that convert should output nothing. Johnuniq (talk) 09:47, 25 September 2016 (UTC)

Unabbreviated something something request

I have no idea how to title this request. In astronomy/space exploration articles (and, perhaps, elsewhere), it is often desirable to have vast numbers converted, but you don't want all the zeroes, nor do you always want exponential notation, just for the sake of readability and easy comprehension. I've been taking to doing this:

  • {{convert|280|e6km|e6mi AU|abbr=off|sp=us}} to obtain 280 million kilometers (170 million miles; 1.9 astronomical units)

This is nice, at least for the first instance of a measure, but it gets long on the eyes after a while. What I'd like is to keep the written out "million", "billion", etc, but abbreviate the unit. In other words, something like:

  • {{convert|280|e6km|e6mi AU|abbr=unit}} to obtain 280 million km (170 million mi; 1.9 AU)

That is nice and simple and easy on the eyes and on the editor. I'd thank you from the bottom of my wee heart if this could be done.

P.S.: This is not part of this request, necessarily, just a curiosity about something I would like to see available but don't know if its possible. Using the above example, if a source only gives the measurement in miles, but for standardisation we want kilometers first, but also want AUs represented, would it be feasible to re-jigger the |order=flip to select which unit comes first...or, possibly easier, create a parameter akin to |first=km to do the job? For example:

  • {{convert|170|e6mi|e6km AU|abbr=unit|first=km}} to obtain 280 million km (170 million mi; 1.9 AU)

Anyway, uh, yay conversions! — Huntster (t @ c) 00:50, 14 September 2016 (UTC)

So your second request seems so reasonable that this almost seems like a bug to me. If I say order=flip and there are multiple output units I would expect to see what you're asking for. Why would we ever want the current behavior, which produces this: 270 million kilometres; 1.8 astronomical units (170×10^6 mi) ? Kendall-K1 (talk) 01:36, 14 September 2016 (UTC)
I second that. "unit; unit (unit)" is clunky and bizarre. — Eru·tuon 01:49, 14 September 2016 (UTC)

Having a choice with order=flip was discussed at Template talk:Convert/Archive June 2016#A flippin' mess with order=N being suggested (and I wondered about order=0 to suppress the source unit as wanted for some converts). Re "million", as people here probably know, the current situation is that it's "million" when the unit is not abbreviated, and scientific notation when it is. Examples:

  • {{convert|280|e6km|e6mi AU|sp=us}} → 280 million kilometers (170×10^6 mi; 1.9 AU)
  • {{convert|280|e6km|e6mi AU|abbr=on|sp=us}} → 280×10^6 km (170×10^6 mi; 1.9 AU)
  • {{convert|280|e6km|e6mi AU|abbr=off|sp=us}} → 280 million kilometers (170 million miles; 1.9 astronomical units)

I'll try to think about the issues raised next week. Johnuniq (talk) 07:48, 14 September 2016 (UTC)

@Huntster: I have put abbr=unit in the sandbox, examples:

  • {{convert/sandbox|280|e6km|e6mi AU|abbr=unit}} → 280 million km (170 million mi; 1.9 AU)
  • {{convert/sandbox|280|to|315|e6km|e6mi AU|abbr=unit}} → 280 to 315 million km (174 to 196 million mi; 1.87 to 2.11 AU)

Please test and check it does what is wanted. I know someone is going to want "million miles" but I'll wait for that, along with a suggestion for the syntax. I'm still pondering order=flip but that one is very tricky, and more than the OP is needed per the June 2016 discussion I linked above. Johnuniq (talk) 05:14, 19 September 2016 (UTC)

Johnuniq, yep, I put |abbr=unit through some paces, and it worked perfectly. Outstanding! If they want "million miles" spelled out, then they can use |abbr=off like I did. Regarding the |order=flip, I fully admit I have no idea how the code works, but would it be possible to simply specify, say, |order=km to force kilometers first, or |order=mi to force miles first, etc etc? As in, rather than the code trying to figure out what the user is wanting with "flip", make the user specify what they want for non-standard cases. I'm just spitballing due to ignorance, of course. — Huntster (t @ c) 07:57, 19 September 2016 (UTC)

That's good, but more may be needed. The earlier discussion wanted something to handle, for example, a table where some entries have a reference in one unit, while others use a second unit, and still others use a third. That is, some converts would use one unit for the input, while others would have different input units. However, convert would display each item with consistent units. The following example is contrived but shows the idea. 

Unit position for order=N:                           0                1          2       3       4
{{convert|100|kPa|Torr atm psi inHg}}          → 100 kilopascals (750 Torr; 0.99 atm; 15 psi; 30 inHg)
{{convert|750|Torr|kPa atm psi inHg|order=1}}  → 100 kilopascals (750 Torr; 0.99 atm; 15 psi; 30 inHg)
{{convert|0.99|atm|kPa Torr psi inHg|order=2}} → 100 kilopascals (750 Torr; 0.99 atm; 15 psi; 30 inHg)
{{convert|15|psi|kPa Torr atm inHg|order=3}}   → 100 kilopascals (750 Torr; 0.99 atm; 15 psi; 30 inHg)
{{convert|30|inHg|kPa Torr atm psi|order=4}}   → 100 kilopascals (750 Torr; 0.99 atm; 15 psi; 30 inHg)

The suggested syntax was order=N where N is a number as above. I'm thinking about that, but convert has a lot of peculiarities which complicate the code. Another discussion wanted the ability to omit the input unit because, for example, a reference might use PS but the table wants to display some other units. I'll report back in a few days. Johnuniq (talk) 10:26, 19 September 2016 (UTC)

Well, you know best certainly, but oh boy that sounds unreasonably complicated, from both a code and an end-user standpoint. — Huntster (t @ c) 20:34, 19 September 2016 (UTC)
Would it make sense to tackle the simpler, more common case first? order=flip with two output units should produce "unit (unit; unit)" instead of "unit; unit (unit)". Kendall-K1 (talk) 21:10, 19 September 2016 (UTC)

order=unit numbers

What if |order= could contain a series of numbers that specified which of the units should be displayed and in what order? 1 would represent the input unit, 2 the output unit, and 3 and 4 the optional second and third output units. Then if you input {{convert|value|unit1|unit2 unit3 unit4}} and you only wanted to display the last three, you could add |order=234. Or if you input {{convert|value|unit1|unit2}}, you could add |order=21 as an alternative to |order=flip. — Eru·tuon 18:16, 25 September 2016 (UTC)

Possibly, but very few people would want to figure out that kind of syntax. I thought it was more obvious to just list the units that are wanted as the output. Johnuniq (talk) 02:13, 26 September 2016 (UTC)

order=out

@Huntster, Jimp: I put a test of a new system in the sandbox to implement your suggestions although I am experimenting with a different syntax. I'm pretty sure some options will fail with the new system, and I will either fix them or disable use of those options when the new syntax is used.

While Huntster may have a different aim, the main objective was to easily make tables where, for example, one reference might give a value in km, while another gives a value in miles, and other references use other units. The option order=out replaces the input with the first unit in the output combination—the order of the units displayed is determined by the output combination used in the convert. Examples:

  • {{convert/sandbox|3.2|km|km mi yd|order=out}} → 3.2 kilometres (2.0 mi; 3,500 yd)
  • {{convert/sandbox|2.5|mi|km mi yd|order=out}} → 4.0 kilometres (2.5 mi; 4,400 yd)
  • {{convert/sandbox|2340|yd|km mi yd|order=out}} → 2.14 kilometres (1.33 mi; 2,340 yd)
  • {{convert/sandbox|1.9|nmi|km mi yd|order=out}} → 3.5 kilometres (2.2 mi; 3,800 yd)

In the above, the inputs use different units but each result shows the same units. The input unit in the last example (nautical miles) does not appear in the output. That would be useful if a reference specified an unwanted unit.

Examples based on previous suggestions follow.

  • {{convert/sandbox|170|e6mi|e6km e6mi AU|abbr=unit|order=out}} → 270 million km (170 million mi; 1.8 AU)
  • {{convert/sandbox|100|kPa|kPa Torr atm psi inHg|order=out}} → 100 kilopascals (750 Torr; 0.99 atm; 15 psi; 30 inHg)
  • {{convert/sandbox|750|Torr|kPa Torr atm psi inHg|order=out}} → 100 kilopascals (750 Torr; 0.99 atm; 14.5 psi; 30 inHg)
  • {{convert/sandbox|0.99|atm|kPa Torr atm psi inHg|order=out}} → 100 kilopascals (750 Torr; 0.99 atm; 14.5 psi; 30 inHg)
  • {{convert/sandbox|15|psi|kPa Torr atm psi inHg|order=out}} → 100 kilopascals (780 Torr; 1.0 atm; 15 psi; 31 inHg)
  • {{convert/sandbox|30|inHg|kPa Torr atm psi inHg|order=out}} → 100 kilopascals (760 Torr; 1.0 atm; 15 psi; 30 inHg)

Thoughts? Johnuniq (talk) 10:03, 21 September 2016 (UTC)

Johnuniq, very interesting. Even if practical application is fairly limited, I especially like the flexibility of an input measure that can be entirely excluded from the output. I'm at work right now and cannot get too involved with testing, but I'll try to run a gamut of tests tonight. — Huntster (t @ c) 15:41, 21 September 2016 (UTC)
That looks great, very simple & straight forward. Jimp 08:27, 25 September 2016 (UTC)

Using order=out is not useful with some options. I am recording this for future reference.

  • Spelling (for example, spell=in) is disabled.
  • The option abbr=~ (show input unit symbol as well as name) is disabled.
  • The following shows some options without order=out to show normal operation. This uses fixed wikitext so the output will not change in the future.
    • {{convert|78|in|yd ft cm}} → 78 inches (2.2 yd; 6.5 ft; 200 cm)
    • {{convert|78|in|yd ft cm|disp=number}} → 2.2; 6.5; 200
    • {{convert|78|in|yd ft cm|disp=unit}} → inches
    • {{convert|78|in|yd ft cm|disp=unit2}} → yd; ft; cm
    • {{convert|78|in|yd ft cm|disp=out}} → 2.2 yd; 6.5 ft; 200 cm
  • The following shows the same converts using order=out. Some of the results may be unexpected. These combinations of options are not intended to do anything useful; this shows what happens.
    • {{convert|78|in|yd ft cm|order=out}} → 2.2 yards (6.5 ft; 200 cm)
    • {{convert|78|in|yd ft cm|disp=number|order=out}} → 2.2 (6.5; 200)
    • {{convert|78|in|yd ft cm|disp=unit|order=out}} → inches
    • {{convert|78|in|yd ft cm|disp=unit2|order=out}} → yards (ft; cm)
    • {{convert|78|in|yd ft cm|disp=out|order=out}} → 2.2 yards (6.5 ft; 200 cm)

Johnuniq (talk) 10:57, 25 September 2016 (UTC)

I particularly like the one whose only output is the word "inches." I'm trying to think where I can use this... Kendall-K1 (talk) 17:50, 25 September 2016 (UTC)
I did say it wasn't useful! The same result comes from {{convert|78|in|disp=unit}} and that has worked for years. Presumably disp=unit is for more exotic units where getting the formatting of the unit name might not be easy. I was just testing what the unusual options do with the new order=out. Johnuniq (talk) 02:10, 26 September 2016 (UTC)

Module version 15

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:

  • Units minor changes/additions:
    • league will now show plural "leagues" with abbr=on (like acre). Discussion here.
    • solar radius is a new unit with symbol R☉, and the existing solar mass now has symbol M☉ (italic "M"). Discussion here with follow-up here.
  • New range / for a table of high/low temperatures such as {{convert|83|/|63|F|disp=br()|abbr=values}}. Discussion here. Example:
    • {{convert/sandbox|83|/|63|F|abbr=values}} → 83 / 63 (28 / 17) (for use in a table)
  • Convert will output an empty string if the first input value is "NNN"—three or more "N". Some infoboxes (example) have documentation with samples including converts like {{convert|NNNN|mm|in|1|abbr=on}}. This change allows the samples to be copied into an article without displaying an error. Discussion here.
  • New abbr=unit option. Using abbr=on abbreviates all units and number names; abbr=unit abbreviates only units. Discussion here. The following examples have both options to show the difference.
    • {{convert/sandbox|280|e6km|e6mi+AU|abbr=on}} → 280×10^6 km (170×10^6 mi; 1.9 AU)
    • {{convert/sandbox|280|e6km|e6mi+AU|abbr=unit}} → 280 million km (170 million mi; 1.9 AU)
    • {{convert/sandbox|280|to|315|e6km|e6mi+AU|abbr=on}} → 280×10^6 to 315×10^6 km (174×10^6 to 196×10^6 mi; 1.87 to 2.11 AU)
    • {{convert/sandbox|280|to|315|e6km|e6mi+AU|abbr=unit}} → 280 to 315 million km (174 to 196 million mi; 1.87 to 2.11 AU)
  • The suppression of overlinking is improved. This was possible due to changes required to implement order=out. The only differences for converts in articles as at June 2016 occur with the following:
    • {{convert/sandbox|115|lb|kg stlb|abbr=on|lk=on}} → 115 lb (52 kg; 8 st 3 lb) (lb only linked once)
    • {{convert/sandbox|25|kg|lb stlb|lk=on}} → 25 kilograms (55 lb; 3 st 13 lb) (lb only linked once)
    • {{convert/sandbox|1500|lb/h|abbr=on|lk=on}} → 1,500 lb/h (680 kg/h) (h only linked once)
    • {{convert/sandbox|15|kWh/m2|btu/ft2 MJ/ft2|sigfig=4|lk=out|abbr=on}} → 15 kWh/m2 (4,755 BTU/sq ft; 5.017 MJ/sq ft) (sqft only linked once)
  • The previous version (before September 2016) output the following for these converts.
  • New order=out option. Discussion here. Using order=flip swaps the entire left-hand and right-hand sides, which is not helpful when the output is a combination. This uses fixed wikitext so the output will not change in the future.
    • {{convert|86|in|yd m|order=flip}} → 2.4 yards; 2.2 metres (86 in)
  • Using order=out, the order in which units are displayed is set by the output unit. The input unit can be repeated in the output, or can be omitted if it is not wanted.
    • {{convert/sandbox|86|in|m yd in|order=out}} → 2.2 metres (2.4 yd; 86 in)
    • {{convert/sandbox|86|in|yd m|order=out}} → 2.4 yards (2.2 m)
    • {{convert/sandbox|86|in|ydftin m|order=out}} → 2 yards 1 foot 2 inches (2.2 m)

The order=out option may not be used often, but it solves two problems that have been raised in the past:

  • When preparing tables of measurements (for example, lengths of rivers), one reference might give a value in km, while another gives a value in miles, and other references use other units. Using order=out, the wikitext for each convert would be exactly the same except for the input—the input value and unit would depend on the reference.
  • Sometimes the unit used in the reference is not wanted in the result (for example, as discussed here). For example:
    • {{convert/sandbox|10000|PS|ihp kW|abbr=on|order=out}} → 9,900 ihp (7,400 kW)

Release notes for earlier versions are listed here. Johnuniq (talk) 04:54, 26 September 2016 (UTC)

Johnuniq, very very cool. Thanks for all your hard work! — Huntster (t @ c) 14:26, 26 September 2016 (UTC)
Thanks seconded, especially for |abbr=unit which is just what I was looking for a few days ago -- how did you guess? — JFG talk 09:31, 27 September 2016 (UTC)
Thanks all, version 15 is now live. Johnuniq (talk) 07:53, 28 September 2016 (UTC)

Can this be made to work?

For Intermodal container#History, {{convert|8|x|8.5|x|35|ft|m|2|abbr=on}} 8 ft × 8.5 ft × 35 ft (2.44 m × 2.59 m × 10.67 m) would work. {{convert|35|0|x|8|0|x|8|ft|6|in|m|2|abbr=on}} 35 0[convert: unknown unit] and {{convert|35|ft|0|in|x|8|0|x|8|ft|6|in|m|2abbr=on}} 35 ft 0 in ([convert: unknown unit])* would not. Peter Horn User talk 17:21, 28 September 2016 (UTC)

Template doc says "While it is possible to enter feet, inch in a simple conversion, this is not possible for ranges [and multiples]". But maybe something along these lines? {{convert|8|x|8.5|x|35|ft|m ftin|2|abbr=on|disp=out|order=out}} 2.44 m × 2.59 m × 10.67 m (8 ft 0 in × 8 ft 6.00 in × 35 ft 0 in) Kendall-K1 (talk) 17:42, 28 September 2016 (UTC)
{{convert|8|x|8.5|x|35|ft|m ftin|2|abbr=on|disp=out|order=out}} 2.44 m × 2.59 m × 10.67 m (8 ft 0 in × 8 ft 6.00 in × 35 ft 0 in) which is the reverse of {{convert|8|x|8.5|x|35|ft|m|2|abbr=on}} 8 ft × 8.5 ft × 35 ft (2.44 m × 2.59 m × 10.67 m). Peter Horn User talk 18:03, 28 September 2016 (UTC)
I think the following is what is wanted, except it has a small problem:
  • {{convert|8x8.5x35|ft|ftin m|abbr=on|order=out}} → 8 ft 0 in × 8 ft 6 in × 35 ft 0 in (2.4 m × 2.6 m × 10.7 m)
The small problem is that it shows two "0 in" when it would be cleaner if they were omitted. Unfortunately that can't be avoided. The trick of using order=out does effectively allow an input multiple unit like 8 feet 6 inches to be used in a range, but it won't cover everything wanted.
By the way, the disp=out used above is ignored. The fact that order=out is used means that only the output will appear. Except, if only one output unit is used, order=out does not make sense, and it is ignored. In that case disp=out does have an effect. For example:
  • {{convert|42|in|ft|abbr=on|order=out}} → 42 in (3.5 ft) (only one output unit: order=out is ignored)
  • {{convert|42|in|ft|abbr=on|disp=out|order=out}} → 3.5 ft (because order=out is ignored, disp=out is not ignored)
Johnuniq (talk) 07:48, 29 September 2016 (UTC)

Slash with thin spaces

  • without thin space (current behavior):
44/18
(7/−8) 		48/21
(9/−6) 		54/25
(12/−4) 		60/28
(16/−2) 		70/34
(21/1) 		79/40
(26/4) 		90/44
(32/7) 		89/42
(32/6) 		80/36
(27/2) 		68/28
(20/−2) 		52/22
(11/−6) 		42/18
(6/−8) 		47
(8)
  • with thin space:
44 / 18
(7 / −8) 		48 / 21
(9 / −6) 		54 / 25
(12 / −4) 		60 / https://wiki.riteme.site/wiki/Help:Introduction_to_referencing/128
(16 / −2) 		70 / 34
(21 / 1) 		79 / 40
(26 / 4) 		90 / 44
(32 / 7) 		89 / 42
(32 / 6) 		80 / 36
(27 / 2) 		68 / 28
(20 / −2) 		52 / 22
(11 / −6) 		42 / 18
(6 / −8) 		47
(8)

Could thin spaces be added around the slash range separator? I tried that at Module:Sandbox/Erutuon/Temperature arrays/doc and I think it's more readable than an unspaced slash. — Eru·tuon 03:20, 30 September 2016 (UTC)

We spent two weeks discussing that in August!
I changed the sandbox module to output a thin space around the slash. Please check the result and ask at the wikiproject and get someone to agree.
For testing, I added // (two slashes) which outputs an unspaced slash like the main module does now with a single slash. The double-slash range will be removed—it's just to allow quick comparisons of the two outputs:
  • {{convert/sandbox|12|/|20|C}} → 12 / 20 °C (54 / 68 °F)
  • {{convert/sandbox|12|//|20|C}} → 12/20 °C (54/68 °F)
Johnuniq (talk) 04:27, 30 September 2016 (UTC)
Your examples look good to me. I should've thought of it before; I guess I was just looking for a quick solution at the time. I posted at WP:METEO, and Dustin V. S. said it looks fine. Probably no one will object. — Eru·tuon 05:09, 30 September 2016 (UTC)
I have yet to check how it shows up with mobile interfaces, but at least the way it currently appears for me (FYI, I am using a desktop), I agree that the spaced version is a bit more legible. Dustin (talk) 05:13, 30 September 2016 (UTC)

I updated the module so it outputs thin spaces around the slash. It is still possible to use "//" with convert/sandbox but that will be removed in due course. I replaced the example above with fixed wikitext so it won't break when "//" is removed. The thin space looks good at Climate of California and Climate of Spain. Johnuniq (talk) 23:34, 30 September 2016 (UTC)

Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:Convert/Archive_September_2016&oldid=748600230"