Jump to content

Template talk:Convert/Archive August 2015

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


No editing the documentation sections

I see that section editing is possible for the /doc subpage, but why is is there no edit tags for the main page documentation? Why do I have to View /doc first, before I can edit the section I'm reading? — CpiralCpiral 06:07, 1 August 2015 (UTC)

What page are you looking at? What is an example section with a problem? What do you see or not see? Johnuniq (talk) 06:42, 1 August 2015 (UTC)
Template:Convert has no section editing at all. But Template:Convert/doc does, and it is accessible by View link on the first line of the doc box. There must be something wrong. — CpiralCpiral 16:16, 1 August 2015 (UTC)

{{documentation|page=Template:Convert}} does show the edit links in a sandbox once that sandbox is saved. And for example {{Val}} does show the edit links as it should. — CpiralCpiral 19:55, 1 August 2015 (UTC)

At Template:Convert#Ranges of values I see "[edit]" just after the "Ranges of values" heading, and clicking the edit link shows the edit window for that section. Perhaps clear your browser cache? Johnuniq (talk) 23:19, 1 August 2015 (UTC)
Turns out when a template's edit tab says "View source" instead of "Edit", ya hafta read the /doc page directly if you want to edit sections of what you read. (I found out by logging out and looking at Val.)
If you just want to edit the entire /doc, you can do that from the main page by pressing "edit" in the doc box; otherwise to edit sections you have to press "view" in the doc box and read the /doc directly. So it's a bug. Grate! I've reported it on phabricator https://phabricator.wikimedia.org/T107685?workflow=create — CpiralCpiral 04:53, 2 August 2015 (UTC)

New area unit: Feddan

I'm only very slightly proficient with template markup, and I'd appreciate someone adding the feddan (I edit Egypt articles from time to time).

The Egyptian standard feddan is 4200 square meters, or 0.42 hectares, or 1.038 acres. Sudan uses the same unit. Syria uses a smaller feddan, but it is less used as the dunam is also a common unit of land measurement there. I don't know which definition Oman uses. Lockesdonkey (talk) 21:58, 5 August 2015 (UTC)

@Lockesdonkey: I created the unit at Module:Convert/extra based on the modern definition apparently used in Egypt. That is a temporary work area for trying new units. If it is useful in an article, the definition can be moved into the main list of units. Units with no clear or universal definition are a problem for the convert template, and it might be better to just use words in an article to say what is wanted. The current definition works like this:
We can review the unit later because I am reluctant to add new units unless they are useful in articles. Johnuniq (talk) 10:17, 6 August 2015 (UTC)
I know already that it would be useful in at least one place: Economy of Egypt, as editing that page was what led me to come here. Other than that, there are a number of articles (at a minimum, a substantial proportion of the pages that link to the article feddan) which might be improved by such a template (particularly ones dealing with settlements and with Nasser's land reforms, of which there are several), and I have a plan, at some point when I have the time and can find a reliable source, to work on improving the infoboxes for various Egyptian settlements (as in towns/cities), and Egyptians usually quote the area of a settlement in feddans. Even if I won't be using it immediately for some of these purposes, I will be using it. Lockesdonkey (talk) 17:00, 6 August 2015 (UTC)
Good, there's no deadline! Johnuniq (talk) 23:25, 6 August 2015 (UTC)

Module version 12

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:
    • The new unit code au is like AU but displays "au" as the symbol (discussed here and more verbosely at MOSNUM):
      • {{convert|1|au|km|0|lk=in|abbr=on}} → 1 au (149,597,871 km) (lowercase "au" in output)
      • {{convert|1|AU|km|0|lk=in|abbr=on}} → 1 AU (149,597,871 km) (uppercase "AU" in output)
    • Some extra links have been added so automatic per units of these types will link to the articles shown, if lk=on applies (discussed here):
    • Units G (gauss) and K (kelvin) accept SI prefixes, mainly for {{val}}. Unit MK (megakelvin) has been removed as redundant given that K accepts the M (mega) prefix.
  • The processing of ranges is now uniform—the rules for a range of two values also apply to ranges of three or more values. Some minor processing for compatibility with the old templates has been removed—I don't think that will affect any converts in articles.
  • The option abbr=mos has a misleading name but it is used in a handful of articles and seems reasonable. If used, it causes the input unit name to be repeated for a range. An example is at Commodore Nutt#Death:
    • Nutt had grown from his original {{convert|29|to|43|in|cm|abbr=mos}} → Nutt had grown from his original 29 to 43 inches (74 to 109 cm)*
  • The range x is now MOS-compliant in that it always repeats the unit symbol when displaying a multiply symbol (×). Previously, that only occurred for a range of two items. For compatibility with current usage (x is used over 6,000 times in articles), the range shows "×" when units are abbreviated and "by" when they are in full. Displaying "by" means convert defaults to using natural language such as "2 by 3 feet" for the input.
  • The new by(x) range is for those who prefer showing more clearly that "by" is intended for the values first displayed. Examples:
    • {{convert/sandbox|1x2x3|m|cm|abbr=on}} → 1 m × 2 m × 3 m (100 cm × 200 cm × 300 cm)
    • {{convert/sandbox|1|by(x)|2|m|cm}} → 1 by 2 metres (100 cm × 200 cm)
    • {{convert/sandbox|1|by(x)|2|m|cm|abbr=on}} → 1 by 2 m (100 cm × 200 cm)
    • {{convert/sandbox|1|by(x)|2|m|cm|order=flip}} → 100 by 200 centimetres (1 m × 2 m)
  • Fixed bug in singular/plural unit name when rounding the input:
    • {{convert/sandbox|1.2|mi|adj=ri0}} → 1 mile (1.9 km) (result has "1 mile" rather than "1 miles")
  • New round=0.5 option to round the output to the nearest half, with the display being either N or N.5 where N is an integer (discussed here):
    • {{convert/sandbox|7x8x12|ft|abbr=on|round=0.5}} → 7 ft × 8 ft × 12 ft (2 m × 2.5 m × 3.5 m) (7 ft rounds to 2 m while 8 ft rounds to 2.5 m}
  • A new function (_unit) is exported and may be used by other modules to access convert's data (discussed here).
  • The html span output generated for sortable=on is now the same as that produced by {{ntsh}}. Module:Val uses the _unit function which can also produce a span element with a hidden sort key.

Module version history 1 (Dec 2013) • 2 (Jan 2014) • 3 (April 2014) • 4 (July 2014) • 5 (Sep 2014) • 6 (Nov 2014) • 7 (Dec 2014) • 8 (Feb 2015) • 9 (Feb 2015) • 10 (May 2015) • 11 (June 2015)

Johnuniq (talk) 09:43, 10 August 2015 (UTC)

Unit is repeated with the multiplication sign

The use of the template to convert mm to in produces 7 mm × 40 mm (0.28 in × 1.57 in). Is there a way to delete the first unit-output, & the spaces, & get 7x40mm (.28x1.57in), instead? It would be very useful in metric ammunition designations. TREKphiler any time you're ready, Uhura 18:41, 21 July 2015 (UTC)

See MOS ranges above. The problem is that the Manual of Style (MoS) says that abbreviations should be repeated when × is used—see WP:UNIT which includes "With the multiplication sign, each number should be followed by a unit name or symbol (if appropriate)." Perhaps ask at the talk page of WP:UNIT whether the guideline must apply for the example you mentioned, with links to one or more articles showing the issue. The question for MoS is whether those articles should repeat the unit, or whether an exception should be made due to [insert reason here]. I recently noticed Adrastea which includes "Adrastea has an irregular shape and measures 20×16×14 km across" as an example where WP:UNIT seems excessive. Johnuniq (talk) 22:32, 21 July 2015 (UTC)
Thx, I'll do that. In general, IMO the MoS gets it right, it just leaves templates unable to cope with the cases where the "general rule" doesn't apply. TREKphiler any time you're ready, Uhura 22:49, 21 July 2015 (UTC)
I would argue that the general rule does apply. Specialists is certain fields might use this convention or that but WP isn't written solely for the specialist. Jimp 08:55, 24 July 2015 (UTC)
And if there is a convention contrary to the MoS, the general rule of the MoS doesn't apply to it, does it? In this instance, the most common usage is interfering with a useful specialist application. TREKphiler any time you're ready, Uhura 14:26, 24 July 2015 (UTC)
re Trekphiler. MOS allows using 'by' this way: "7 by 40 mm (.28 by 1.57in)". -DePiep (talk) 22:17, 25 July 2015 (UTC)
Yes, but the ammo convention is to use the "x", so that's not a help. TREKphiler any time you're ready, Uhura 22:43, 25 July 2015 (UTC) (P.S. If you want to ping, just copy the whole username link; it should notify automatically.)
... and no spaces, and no pre-zero in .28. AFAIK, ammo does not folow MOSNUM. MAybe it has its own MOS. {{Convert}} does not serve that exception. And, quite importnat, isn't ammo classified or normalised, not calculated? -DePiep (talk) 22:58, 25 July 2015 (UTC)
I confess you've lost me, now. As I'm understanding you, you mean the usual output of the template being a non-starter is a given, because it isn't meant to conform. What I'm asking for is a "variant model" that doesn't require manual calculation of the conversions every time an editor wants to go from metric to Imperial. (Take a look just at 8 mm caliber to get some notion how many pages, how many entries, are at issue.) Is it a "separate MoS"? Technically, no, AIUI; the MoS isn't really in touch with usual usage in the firearms community (since it still demands spaces between # & unit, to wit "9 mm", which no gun mag I've ever seen does). That's why I suggest this needs addressing. TREKphiler any time you're ready, Uhura 23:22, 25 July 2015 (UTC)
First the numbers: can calibres be calculated or are they defined? Then the formatting: yes you can ask so. ANd {{Convert}} probably could produce that. But an ammo (calibre) formatting should be based on a MOS. (Sort of similar: track gauges are defined not measured). -DePiep (talk) 23:29, 25 July 2015 (UTC)
Again, I'm not completely clear how you mean "defined". Is the 9mm a dead-accurate measurement of the bore? Not usually. Is the case length? Yes. Do you mean we shouldn't bother to convert at all if both aren't dead accurate? That might be better, actually...but that appears to require a change in MoS--& certainly requires a change in attitude by uninformed editors, who will, I wager, continue to convert (template or no). TREKphiler any time you're ready, Uhura 00:48, 26 July 2015 (UTC)
One more try. Reading 9 mm caliber and 9×19mm Parabellum I get the impression that "9×19mm" is a name, not a size. The name does only refer to a size (or size range) and specifications, to be looked up. And a name we don't need to convert (that would be more like a translation, not a calculation). Also, being a name (and not a measurement or size definition), formatting is not prescribed by measurement formatting (like spacing, preceding 0). So the MOS rule for ammo would be like: "Caliber names are not converted. They may have non-measurement format". (Another checking question: is this 9×19mm ever being referred to as "(.28x1.57in)"? I mean, can one order it by that inches name?). Common unit conversion should be done when describing those specifications. -DePiep (talk) 09:36, 26 July 2015 (UTC)
♠"One more try." I'm not usually this dense. :(
♠You've gotten it, & I think we're agreed. In the case of, frex, the 9x19P, tho, the "19" is a measurement that bears converting...& that's why it's mentioned in the designation to begin with. Which is the problem I mentioned: people are going to want the case length (the 19mm) converted, & reasonably should.
♠The other way, the .28x1.57", is extremely rare except in wildcats. (I can only think of one, the .308x1.5".) As said, tho, the 1.57" 19mm case length matters: it differs from the 25 mm (0.98 in) of the 9mm Mauser or 23 mm (0.91 in) of the 9mm Bergmann...& the 9x25 differs from the 9x57mm rifle round...all of which are {nominally} 9mm...) In Europe, the case length measure is a standard add (& you can see why ;p ); in the U.S. & Canada, it's (almost) all Imperial without case length.
♠It's because of the highly common use of case length in European designations this arises at all. Since, as you point out, the caliber isn't (always) a true reflection of bore diameter, the conversion template probably shouldn't be used (& I agree), the issue of converting just the case length raises its own issues... Perhaps it should be 9x{{convert|25|mm|abbr=on}}? TREKphiler any time you're ready, Uhura 15:19 & 15:22, 26 July 2015 (UTC)
"I'm not usually this dense" - wtf does 'dense' mean? -DePiep (talk) 20:02, 26 July 2015 (UTC)
Just what it says: it doesn't usually take me so many passes to get it right... TREKphiler any time you're ready, Uhura 20:30, 26 July 2015 (UTC)
Whatever. What do you want, re format & conversion, by caliber? Is 9mm actually available by inches? -DePiep (talk) 20:51, 26 July 2015 (UTC)
Apparently, from the template, only removing the spaces; it's looking like this is something the MOS needs to address...but I don't want to move this whole thread there. (Not that anybody seems to be paying attention. :( ) It looks like the solution is to use the template for the case length only: 9x{{convert|25|mm|abbr=on}}, which gives this: 9x25 mm (0.98 in); for firearms, the space between "25" & "mm" is normally removed. TREKphiler any time you're ready, Uhura 00:21, 1 August 2015 (UTC)
Agree I would also appreciate a way to do this; it's a convenient and sometimes preferred abbreviation. In China Jinping Underground Laboratory have to jump through some hoops to get "The design provides four experimental halls, each 14×14×130 m (46×46×430 ft)." The default "14 m × 14 m × 130 m (46 ft × 46 ft × 427 ft)" is so lengthy it really disrupts the flow of the text. I can get no units, but I still get spaces around the multiplication signs, which is not wanted; it's the lack of spaces that emphasize that the multiplication binds tighter and the trailing units distributes across it. I'd really like to be able to write about a "4×8 foot (1.2×2.4 m) sheet of plywood" or a "88×176×6 cm (35×69×2.4 in) tatami". 71.41.210.146 (talk) 21:55, 15 August 2015 (UTC)

Possible Convert Problem?

Shouldn't "500 metres (1,600 ft)" (ie, {{convert|500|m|ft}}) be MORE (*NOT* LESS) than "492 metres (1,614 ft)" (ie, {{convert|492|m|ft}}? - iac - Enjoy! :) Drbogdan (talk) 01:45, 24 August 2015 (UTC)

Convert is doing what is expected there, although it can cause surprises. The point is that 492 has three significant figures, whereas 500 has only one. Accordingly, convert (using Jimp's very clever algorithm) determines how to round the output. The |0 in the third of the following examples overrides the default to round the output to zero decimal places. The last example shows that a range is handled correctly—that provides a clue to convert that extra precision is wanted.
  • {{convert|492|m|ft}} → 492 metres (1,614 ft)
  • {{convert|500|m|ft}} → 500 metres (1,600 ft)
  • {{convert|500|m|ft|0}} → 500 metres (1,640 ft)
  • {{convert|492-500|m|ft}} → 492–500 metres (1,614–1,640 ft)
Johnuniq (talk) 02:16, 24 August 2015 (UTC)
@Johnuniq: Thank You *very much* for your comments - and *excellent* clarification - it's *greatly* appreciated - Thanks again - and - Enjoy! :) Drbogdan (talk) 13:07, 24 August 2015 (UTC)

Question

Is there any way to make this template work along with the {{fraction}} template? --John (talk) 20:23, 25 August 2015 (UTC)

Convert already has {{fraction}}'s output functions (per the documentation), so you must mean using Frac as an input. But no, I predict the maintainers will maintain that human input like
{{convert|2+1//2|in|mm|1}} → 2+1/2 inches (63.5 mm) or {{convert|2+1/2|in|mm|1}} → 2+1⁄2 inches (63.5 mm).
(input as one field, with a + sign for a mixed numeral, and / or // for the bar) will be supported, while Frac's HTML output "{{frac|2|1|2}} → 2+1⁄2" which is actually 1=<span class="frac nowrap">2<span class="visualhide"> </span><sup>1</sup>⁄<sub>2</sub></span>, won't be supported.
You might have to change a bunch of Fracs to Converts using "find and replace" functions? — CpiralCpiral 21:46, 25 August 2015 (UTC)
A lot of that was over my head, I am a novice user of both these templates, trying for fractional input in inches and decimal mm output. In the end I manually converted to decimal inches, captured the output from the convert template, then pasted it without the convert template and reinserted the fraction template to get my desired output. Strikes me there must be an easier way. --John (talk) 22:16, 25 August 2015 (UTC)
@John: {{convert|1+7/8|in|mm|1}} → 1+7⁄8 inches (47.6 mm) or {{convert|1+3/4|in|mm}} → 1+3⁄4 inches (44 mm) would do what you wanted. Imzadi 1979 → 22:44, 25 August 2015 (UTC)
Thank you, User:Imzadi1979, that makes total sense. --John (talk) 22:47, 25 August 2015 (UTC)
For completeness, here is how to reverse the process with fractions in the output:
  • {{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)
Johnuniq (talk) 02:21, 26 August 2015 (UTC)
Thank you! I knew there had to be a way. --John (talk) 09:56, 26 August 2015 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Convert/Archive_August_2015&oldid=1124405032"