Template talk:Convert/Archive October 2015

Fractions

Why can't the Lua module handle proper unicode fraction symbols like ½ ? Using -1⁄2 is odd. John Vandenberg ^(chat) 13:44, 3 October 2015 (UTC)

I'm not involved in the coding of templates, but my guess would be that an article that contains one fraction is likely to contain others. Unicode fractions are only available for a few possible fractions. An article that contains 1⁄2 is likely to also contain 7⁄16 or other fractions for which no Unicode is available. It would both complicate the programming, and provide inconsistent appearance in the article, to use different approaches depending on whether a Unicode character happened to be available for a particular fraction. Jc3s5h (talk) 15:31, 3 October 2015 (UTC)

Well I ask because I was working on Phineas Gage (most are {{Convert}}ed, but some are pending discussion here or on the talk page), which only uses fractions that can be expressed using unicode's provided vulgar fractions. I very strongly suspect there is a very large cohort of similar articles that would be able to use only unicode provided symbols, as it contains the most commonly fractions used in normal situations, as 1/8 is about as much accuracy as a person typically would need to describe something sufficiently accurately for historical records using equipment they have and can competently wield. It is these historical topics which would benefit from supporting the simple unicode fractions.

Of course you are right Jc3s5h, for articles where present-day accurate technical descriptions are needed, greater precision is appropriate, and appropriate equipment was used correctly to obtain said greater precision. 7⁄16 isnt easily expressed using unicode symbols, except by using the magic ⅟ numerator to advantage, such as ⅜+⅟₁₆ or ½-⅟₁₆ , but using calculation symbols like that suffers the same legibility problem as it means the source code is subtly different from the rendered text (which for example means 'copy & page text search' fails). John Vandenberg ^(chat) 21:36, 3 October 2015 (UTC)

MOS:FRAC says to not use special characters such as ½. Convert allows a fraction in the input and/or output, see Help:Convert#Fractions. Examples:

• {{convert|2+1/2|in|mm}} → 2+1⁄2 inches (64 mm)
• {{convert|3+7/8|in|mm}} → 3+7⁄8 inches (98 mm)
• {{convert|48|mm|in|frac=8}} → 48 millimetres (1+7⁄8 in)
• {{convert|44|mm|in|frac=8}} → 44 millimetres (1+3⁄4 in) (frac=4 or frac=8 give the same result here)
• {{convert|70|mm|in|frac=128}} → 70 millimetres (2+97⁄128 in)

Does this cover what is wanted? Johnuniq (talk) 00:59, 4 October 2015 (UTC)

Hi John, I wouldnt want to contradict MOS:FRAC with regards to what is output, but I can see a small usability gain in allowing 2½ as an input. I'd be happy to try implementing that, but only if there was a general feeling it was appropriate. John Vandenberg ^(chat) 04:42, 5 October 2015 (UTC)

The input code is monstrous already, although it would be pretty easy to special case a half with text = text:gsub('½', '+1/2') but in general I don't think that offering multiple ways of doing things is always desirable because too many options leads to confusion with people wondering why 2½ works but 2¼ doesn't. There are around 3000 converts in articles with input numbers using "1/2" (half), and another 3000 using other fractions like 1/4 or 3/8, and it's probably better that people get used to the fact they have to enter fractions like that. Johnuniq (talk) 05:27, 5 October 2015 (UTC)

One vs A and An

{{convert|1|oz|g|spell=in}}

is

one ounce (28 g)

I believe it should be possible to use 'an ounce' rather than 'one ounce'. Is there some hidden option for that?! John Vandenberg ^(chat) 14:16, 3 October 2015 (UTC)

No, sorry that's not possible. There are several quirky points about spelling numbers that made me give up when contemplating the issue. I can't recall what they are now, but Module:ConvertNumeric (which does the spelling) is able to handle "two and one half" or "two and a half" or "two and an eighth", although convert does not expose that option. The workaround is:

• an ounce ({{convert|1|oz|g|disp=out}}) → an ounce (28 g)

Johnuniq (talk) 01:13, 4 October 2015 (UTC)

Thanks for saving me dig around in the code to find something that doesnt exist.

Would there be any reason why offering articles (i.e. an ounce) as an option would be bad for the user/reader/someone? (i.e. ignoring the complexity of implementing the beast) John Vandenberg ^(chat) 04:48, 5 October 2015 (UTC)

There are two aspects: (1) what reasonable syntax could be used?; (2) how often would it be used [is the effort/complexity worthwhile]? It was (2) that persuadaed me to not worry about it when implementing spelling. I might search my notes sometime and see if I left any clues about what options might also be wanted—I vaguely recall there being a few corner cases, particularly for UK/US differences, where people might not be happy with how numbers are spelled. There are about 2300 converts in articles which spell a number, and 150 of those involve fractions, and when I looked at some samples of usage I think I decided the way it was done was ok. That would need more thought because I haven't looked at spelling for two years. It is true that "an ounce" would be better in some cases, but the workaround exists. Johnuniq (talk) 05:52, 5 October 2015 (UTC)

Problems with spell=out

Using spell=out does not seem to be working, but shown below =on and =in both work.

• spell=out: 82.1 gigametres (51,000,000 mi)
• spell=on: eighty-two point one gigametres (fifty-one million miles)
• spell=in: eighty-two point one gigametres (51,000,000 mi)

Quick testing seems to suggest this is independent of units or values

• spell=out: 82.1 miles (132.1 km)
• spell=on: eighty-two point one miles (one hundred and thirty-two point one kilometres)
• spell=in: eighty-two point one miles (132.1 km)
• spell=out: 1,000 litres (220 imp gal; 260 US gal)
• spell=on: one thousand litres (two hundred and twenty imperial gallons; two hundred and sixty US gallons)
• spell=in: one thousand litres (220 imp gal; 260 US gal)
• spell=out: −1 pound per square inch (−6.9 kPa)
• spell=on: negative one pound per square inch (negative six point nine kilopascals)
• spell=in: negative one pound per square inch (−6.9 kPa)

Independently of this, the "spell" parameter needs adding to TemplateData for VisualEditor use. Thryduulf (talk) 16:34, 6 October 2015 (UTC)

There is no spell=out because it is hard to see what use it would be.

The following options are documented as working:

• |spell=in spell input
• |spell=In same, starting with uppercase letter
• |spell=on spell input and output
• |spell=On same, starting with uppercase letter

The order can be flipped to spell the output, but it appears first and is a bit dubious because the rounded result might read strangely when spelled. Example of something that works:

• {{convert|8|ft|in|0|spell=In|order=flip}} → Ninety-six inches (8 ft)

Is there really a need for |spell=out? What about |spell=Out? Johnuniq (talk) 01:05, 7 October 2015 (UTC)

I'm not sure about a need. I found what I was actually intending to achieve can be done with {{convert|82.1|Gm|e6mi|abbr=off}} → 82.1 gigametres (51.0 million miles). Thryduulf (talk) 00:51, 8 October 2015 (UTC)

Adjectival format and Google Search speech-to-text

The adjectival form for measurements seems to cause problems for Google Search's text-to-speech. I recently search for Panama Canal and when it read out the intro it spelled out the measurement, i.e. referred to it as "a seven seven point one dash k-i-l-o-m-e-t-r-e canal". I guess really it's more Google's problem than ours, but I was wondering if there was anything that could be done to improve accessibility in the meantime? Keepstherainoff (talk) 16:00, 9 October 2015 (UTC)

@Keepstherainoff: I put a summary of the issue at Project Accessibility and suggest that further discussion occur there because it is much more likely that the people at that project would be able to help. If that discussion has a suggestion for how convert might be modified, please mention it here. By the way, I moved the new comment to the botttom of this page—it's best to use "new section" at the top when adding a new topic. Johnuniq (talk) 22:45, 9 October 2015 (UTC)

An option to suppress conversion

When user's preferred system is Si, multiple imperial equivalents, automatically inserted by conversion, clutter majority of the articles, really ruining their readability. I suspect it is the same for the users accustomed to imperial units. It would be perfect if user could make wikipedia display all measurements, presented through conversion templates, in only one, preferred, system. I've been searching through the wikipedia user settings for related options and through the wikimedia RFCs for their discussions, but found only discussion of the preferred order here and old/abandoned discussion of "Auto unit conversion" which, as I understand, is different template and, even if finished, won't affect the behavior of Convert templates. Does anything like this already exist? Right now it seems to me it does not and I'm considering creating an RFC at mediawiki project, but feature seems so obvious that I wanted to double-check for the case I missed it. Thanks Darkdiatel (talk) 10:13, 5 October 2015 (UTC)

I can't recall anything precise, but there have been occasional suggestions that an editor should be able to specify a preferred method of spelling (most commonly, UK/US for colour/color), or preferred method of dates (1 April 2015 or April 1, 2015 or 2015/04/01, and so on), or preferred system of units, and that articles would then be displayed accordingly. Apart from the complexity of how such a system would work, there is the issue that readers see a cached copy of pages because it takes a significant amount of computer effort and time to translate from the wikitext used on a page to the HTML required by the user's browser. The caching system would be much more difficult if people could request different versions. At any rate, I don't think the idea has ever got anywhere. There was a very early attempt to automatically convert between units (with, for example, both miles and km being displayed for a distance specified only in miles or only in km), but it also got nowhere when the complexity of the project was considered. Johnuniq (talk) 10:54, 5 October 2015 (UTC)

Since date format is largely a US vs. rest of the English-speaking world, like SI, I think a proposal to change units based on reader preference will be met with outright hostility. One of the reasons this capability was opposed was that only logged-in users could express a preference, and logged-in users are mostly editors. Thus, editors were seeing something different than most readers, so were not motivated to make articles look right for the majority of readers. These are some of the discussions on the issue:

• Deprication of date linking
• Wikipedia:Requests for arbitration/Date delinking

Jc3s5h (talk) 12:57, 5 October 2015 (UTC)

thanks a lot for both replies, you brought the aspects I wasn't aware of.

There're several ways to solve it without altering page content, to satisfy caching constraints:

1) output inline javascript that displays either version based on preferences, e.g:

Fossils of very large dragonfly ancestors ... these had wingspans of up to about <script>document.write((userPrefs.system == 'si')?'750 mm':'30 in');</script>

2) output several versions one after another, wrapped in inline elements with measurement system specified in an attribute of each, e.g.:

... these had wingspans of up to about <span msystem='si'>750 mm</span><span msystem='imperial'>30 in</span><span msystem='si(imperial)'>750 mm (30 in)</span>

and have single CSS of user preferences for entire wikipedia, which would make only one of those three visible

Yes, most readers are not registered. And I dislike the idea of such basic option requiring a site-specific account setting. In ideal future preferred measurement system would be detected from the respective http header. For now, using cookies could be a solution. The very last minimalistic resort, that requires nearly 0 development efforts, is to at least format output similar to:

750 mm<span class='imperial-equivalent'> (30 in)</span>

30 in<span class='si-equivalent'> (750 mm)</span>

and let geeks suppress it with custom CSS / grease-/tampermonkey etc.

Date issue, I believe, is not as severe. Yes, it must be a pain when you are focused on specific dates. But the issue with alternate version of the measurement is that you get extra unneeded information all the time, and this is distracting.Darkdiatel (talk) 16:24, 5 October 2015 (UTC)

Custom CSS maybe- has Visual Editor got anything under their sleeve? But I don't see much of a problem being delivered a full page and then refreshing to clear the cache to get a newly regenerated page with options. The spelling issue is more pertinent- particularly page name, some artificial fibres have the word fibre in their name- indeed the fibre page- this desperately needs a {{convert|fiber|fibre|EN-US|EN-Other}} template. -- Clem Rutter (talk) 17:58, 5 October 2015 (UTC)

Darkdiatel, a user preference would need to be added to the MediaWiki software or a MediaWiki extension, so that makes many parts of this suggestion largely beyond the scope of this template. However, this template could easily add some CSS classes which could allow WP:User CSS and WP:Gadgets to provide users with some level of control. We might even go further and implement parts of http://microformats.org/wiki/measure , which may also have some accessibility benefits. ;-) John Vandenberg ^(chat) 00:38, 6 October 2015 (UTC)

As a possibility for using CSS classes to let people choose either unit in converts, the template could use output syntax like this:

<span class="convert-si convert-imperial"><span class="imperial">10 mi</span><span> (</span><span class="si">16 km</span><span>)</span></span>

This way, logged-in users could display only the measurement system of their preference using either

.convert-si span:not(.si) {display:none;}

or

.convert-imperial span:not(.imperial) {display:none;}

in their user-specific CSS. It would also work with more than two systems of units. There may be ways to allow for simpler selectors to work, to ease switching units for those unfamiliar with CSS. SiBr₄ (talk) 22:45, 6 October 2015 (UTC)

As a minor point, that would still render the SI enclosed with (), but that can also be resolved easily enough.

The hard part is allowing this to be customised so that imperial or SI is not hidden when it is actually necessary. For example, when an article is referring to an imperial unit very explicitly, the imperial needs to be shown, even if the user doesnt prefer imperial, in order for the surrounding prose to make sense. John Vandenberg ^(chat) 00:02, 7 October 2015 (UTC)

The brackets would actually be hidden, since they are in a <span> that matches the .convert-si span:not(.si) selector.

I understand your point about the occasional need to display a unit regardless of user preference. It should be possible for the template to produce output that doesn't match the CSS selector based on the value of a parameter. With my suggested code, removing the convert-si class prevents the imperial units from being hidden (SI units could still be omitted if imperial units are chosen), which is kind of counter-intuitive. SiBr₄ (talk) 17:54, 7 October 2015 (UTC)

Conversions are there to inform. People not familiar with imperial units would like to see the metric equivalents and vice versa. This is especially true for infoboxes. As for the texts, the conversions could be added as a list at the end of an article or at the ends of the sections. Peter Horn User talk 19:37, 19 October 2015 (UTC)

Ton-mile and passenger-mile

For Alabama Great Southern Railroad: 3854 million net ton-miles {{convert|3654000000|STmi}} 3,654,000,000 STmi 10.5 million passenger miles {{convert|10500000|prmi}} 10,500,000 prmi. Peter Horn User talk 18:31, 19 October 2015 (UTC)

For the one: {{convert|105|e6mi|km|adj=pre|passenger}} → 10.5 million passenger miles (16,900,000 km), or

{{convert|105|e6mi|km|disp=preunit|passenger }} → 10.5 million passenger miles (16,900,000 passenger km). Imzadi 1979 → 18:51, 19 October 2015 (UTC)

The text at Alabama Great Southern Railroad was:

In 1970 AGS reported 3854 million net ton-miles of revenue freight and 10.5 million passenger miles

I don't see a source, but it probably means an equivalent of moving 3854 million net short tons over 1 mile, where "net" would mean the value is the weight of the freight carried, not including that of the train. A horrible complication is that convert supports LT = long ton = 2240 pounds and ST = short ton = 2000 pounds and MT = metric ton = 1000 kg = tonne. In principle convert could define a unit or units to cover these, but they are unlikely to be helpful because an article might not want to say "short ton-mile" so it would have to be "ton-mile" with the article text making it clear that it is talking about short tons. As a kludge I have edited the article to manually insert a conversion. If anyone has a proposal for a new unit, please look at Units of transportation measurement and Rail usage statistics by country and see if it would really help, then comment here. Johnuniq (talk) 03:39, 20 October 2015 (UTC)

Using abbr=in or abbr=out with order=flip

When abbr=in or abbr=out is used with order=flip, this template reverses the term to be abbreviated. Either this should be corrected, or the parameters in and out should be changed to first and last. Yours aye,  Buaidh  15:41, 21 October 2015 (UTC)

Here are some examples showing the issue with various options:

• {{convert|1|ft|in|abbr=in|order=flip}} → 12 in (1 foot)
• {{convert|1|ft|in|abbr=out|order=flip}} → 12 inches (1 ft)
• {{convert|1|ft|in|lk=in|order=flip}} → 12 inches (1 ft)
• {{convert|1|ft|in|lk=out|order=flip}} → 12 inches (1 ft)
• {{convert|1|ft|in|spell=In}} → One foot (12 in)
• {{convert|1|ft|in|spell=In|order=flip}} → Twelve inches (1 ft)
• {{convert|1|to(-)|2|ft|in}} → 1 to 2 feet (12–24 in)
• {{convert|1|to(-)|2|ft|in|order=flip}} → 12 to 24 inches (1–2 ft)
• {{convert|1x2x3|ft|in}} → 1 by 2 by 3 feet (12 in × 24 in × 36 in)
• {{convert|1x2x3|ft|in|abbr=in}} → 1 ft × 2 ft × 3 ft (12 by 24 by 36 inches)
• {{convert|1x2x3|ft|in|abbr=in|order=flip}} → 12 in × 24 in × 36 in (1 by 2 by 3 feet)

One problem is that convert has used "in" and "out" like this for many years and it's too late for a change to occur now because dozens of editors are used to how it works. Out of the total of 2 million converts in articles, roughly 200 use flip with abbr=in/out so it's not a big problem. For my curiosity, I found an example:

The 1883 eruption ejected approximately {{convert|6|mi3|abbr=in|order=flip}} of rock. →

The 1883 eruption ejected approximately 25 km³ (6 cubic miles) of rock.

There have been brief discussions about whether some improvement on "in" and "out" was possible, but I think it would be better to tolerate the quirks than try to change it. Johnuniq (talk) 01:34, 22 October 2015 (UTC)

We should at least update the documentation to warn users of potential anomalies when using order=flip. Yours aye,  Buaidh  01:00, 26 October 2015 (UTC)

Angles again

I was just looking for a way to convert angles, and so thought I should revive Template_talk:Convert/Archive_September_2015#Angle_conversions. What I am looking for is a conversion in the manner of roadsigns for the steepness of a road. For instance, one might see "1 in 3 (33%)", but ideally it should also be able to convert into degrees and radians. -mattbuck (Talk) 13:38, 20 October 2015 (UTC)

Please link to two or three articles where convert might help, and it would be good to see some examples of the wikitext for a convert and its wanted output. Not every conversion has to be done by this template, and it sounds as if "1 in 3 (33%)" would be a candidate for a dedicated solution because the syntax would not fit well with how convert works. People here might be able to help with a dedicated template to handle gradients if they are used uniformly in several articles. Johnuniq (talk) 02:39, 21 October 2015 (UTC)

I was writing the Patchway railway station article, and that uses "1 in X" for some line gradients to explain why the station was resited. I just thought it might be handy to convert that into degrees or something. Not a need or anything, but would have been nice. -mattbuck (Talk) 20:23, 27 October 2015 (UTC)