Jump to content

Template talk:Convert/Archive December 2014

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


Proposed new units

Richie765 has added several new units to Module:Convert/data/sandbox and Module:Convert/documentation/conversion data/doc. New units:

  • ls : light-second
  • lm : light-minute
  • lh : light-hour
  • ld : light-day
  • lw : light-week
  • m/year : metre per year
  • km/year : kilometre per year

New aliases:

  • m/y = m/year
  • m/yr = m/year
  • km/y = km/year
  • km/yr = km/year

There are currently 680 units plus 420 aliases (many of which are unused) and I think we should proceed slowly before adding more. Is there a need to convert the above units? In which articles? There are hundreds of units that could be added, but I think we should stick to units that will be used. The quick way to add a unit that will be used now is in Module:Convert/extra (but please only add units that are needed). Johnuniq (talk) 01:48, 8 December 2014 (UTC)

As you write, Jonuniq: only when used. I don't see any mentioning of these in light-year. -DePiep (talk) 11:54, 8 December 2014 (UTC)
Light seconds are often used in relativity theory as the basic unit of distance because they make the speed of light numerically equal to 1. The others are probably very uncommon.GliderMaven (talk) 17:00, 8 December 2014 (UTC)
That makes sense but it sounds unlikely that convert would be useful. Unless something firm clarifies, I'll remove these when I next update the modules. Johnuniq (talk) 01:40, 9 December 2014 (UTC)

Module version 7

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

The changes are:

  • Singular/plural names: Fix bug generating correct name when abbreviation is off with certain rounding that gives a value which the code regards as 1 times a power of ten, per discussion above.
  • Singular/plural names: Remove some compatibility with the old templates in order to give more consistent results. For example, −1 (as well as 1) is now regarded as singular, and the "use name" units such as acre do not have unusual exceptions to the singular/plural rules.
  • Show input unit name and symbol (abbr=~): Give a result more consistent with WP:UNIT, although convert uses square brackets (that could be reconsidered after we try the new code for a while), per discussion above.
  • Change html generated by disp=table and disp=tablecen per Module talk:Convert#Obsolete HTML (permalink).

Module version history

The output in the following examples uses fixed wikitext so the displayed text will not change when future updates occur.

Convert Version 6 output Version 7 output
{{convert|1/2|ft|ft|frac=2|abbr=off}} 1⁄2 foot (1⁄2 feet) 1⁄2 foot (1⁄2 foot)
{{convert|1/2|mi|mi|abbr=off|frac=2|spell=on}} one-half mile (one-half miles) one-half mile (one-half mile)
{{convert|999|ft|ft|abbr=off|sigfig=1}} 999 feet (1,000 foot) 999 feet (1,000 feet)
{{convert|9|ft|ft|abbr=off|-1}} 9 feet (10 foot) 9 feet (10 feet)
{{convert|1.0|ft|ft|abbr=off|sigfig=2}} 1.0 foot (1.0 feet) 1.0 foot (1.0 foot)
{{convert|0|sqyd|acre}} 0 square yards (0 acre) 0 square yards (0 acres)
{{convert|-1|acre|sqyd|abbr=out}} −1 acres (−4,800 sq yd) −1 acre (−4,800 sq yd)
{{convert|0.1|ha|acre}} 0.1 hectares (0.25 acre) 0.1 hectares (0.25 acres)
{{convert|1.04|m|ft|2|abbr=~|sp=us}} 1.04 meters (m, 3.41 ft) 1.04 meters [m] (3.41 ft)
{{convert|9|kPa|abbr=~}} 9 kilopascals (kPa, 1.3 psi) 9 kilopascals [kPa] (1.3 psi)
{{convert|9|kPa|disp=sqbr|abbr=~}} 9 kilopascals [kPa, 1.3 psi] 9 kilopascals [kPa] [1.3 psi]
{{convert|2.3|MeV|abbr=~}} 2.3 megaelectronvolts (MeV, 0.37 pJ) 2.3 megaelectronvolts [MeV] (0.37 pJ)
{{convert|12|m|ft|disp=table}} align="right"|12
|align="right"|39		 style="text-align: right;"|12
|style="text-align: right;"|39
{{convert|12|m|ft|disp=tablecen}} align="center"|12
|align="center"|39		 style="text-align: center;"|12
|style="text-align: center;"|39

I was hoping to do something about a couple of other recently discussed issues, but it looks like they will have to wait. Please speak up if you think there is a problem! Johnuniq (talk) 03:50, 5 December 2014 (UTC)

Formatting of deprecated examples

I recently made a series of edits to some of the templates which are transcluded in the documentation to adjust the formatting of deprecated options from the {{!xt}} template (red serif text) reserved for incorrect examples of style to the {{xtd}} template (grey serif text) reserved for deprecated examples; I then tried the {{bxtd}} template (boldface grey text) to avoid the serif font which obscures the <code> mono-spaced formatting. I have subsequently created {{mxtd}} (mono-spaced grey text) and then found {{deprecated code}} (grey text with hidden <del> markup and optional red formatting).

DePiep reverted my changes and helpfully explained why on my talk page. I explained my position but have not received a reply there, so I thought I would open it up to wider discussion here.

By way of comparison, I present these various formatting options below:

Wikitext Renders as Notes
{{!xt|1=abbr=comma}} abbr=comma Current formatting
{{xtd|1=abbr=comma}} abbr=comma
{{bxtd|1=abbr=comma}} abbr=comma
{{mxtd|1=abbr=comma}} abbr=comma
{{dc|1=abbr=comma}} abbr=comma
{{dc2|1=abbr=comma}} abbr=comma
{{dcr|1=abbr=comma}} abbr=comma My proposed format

Of these, I propose that the {{dcr}} template is the neatest and correct format as it: (1) renders in red; (2) preserves mono-spaced formatting; (3) uses the correct <del> markup intended for deprecated text (although the strikethrough is hidden, it helps for accessibility reasons).

Similarly, it seems that the {{xt}} template (green serif text) is inappropriate and unnecessary and should simply use <code> formatting to indicate correct options, as with the rest of the documentation. For example:

abbr=comma, adj=nocomma, disp=nocomma are deprecated. Use comma=off instead

—sroc 💬 00:28, 8 December 2014 (UTC)

First response: no; Red/green says it all. I'll be back for a 2nd impression. (I really don't know what grey font means, and I can't ever read it as a significance). -DePiep (talk) 00:33, 8 December 2014 (UTC)
I admit: a second, better reading is needed. DePiep (talk) 00:41, 8 December 2014 (UTC)
See here for how this would look. Simple: red means no, default colour means yes. (Note: for accessibility reasons, colour alone should not be used to convey meaning, per WP:COLOR.) —sroc 💬 00:47, 8 December 2014 (UTC)
Please stop. The {{convert/doc}} and Help:Convert are build up by serious and consistent background. If you want to promote any other version, do so from a /sandbox version. -DePiep (talk) 00:59, 8 December 2014 (UTC)
Sorry, I won't persist while the discussion continues, but please engage in the issue on the merits, not I don't like it reasoning. —sroc 💬 01:25, 8 December 2014 (UTC)
"I admit: a second, better reading is needed." I'm not sure what you mean. Do you have any objections to the proposed formatting? If so, why? —sroc 💬 01:27, 8 December 2014 (UTC)
Convert and its documentation are big and complex, so let's proceed slowly. I'll try to examine the issue and offer some opinions later, but we're not talking about fixing a WP:BLP violation so let's take due time. Johnuniq (talk) 01:54, 8 December 2014 (UTC)
Yes, of course, there's no need to rush, but remember this is only a proposed change in formatting the documentation to use the appropriate templates, not substantive changes to the text nor any change to the operation of {{convert}} itself. —sroc 💬 02:17, 8 December 2014 (UTC)
re, short. The old version is OK to me. For changes: convince me. The red/green diff supports MOS page style (the way MOS is written). Using grey font or bold font for deprecated options I bark against. {convert} documentation is build up well and consistently. -DePiep (talk) 01:24, 9 December 2014 (UTC)

At the moment I'm just trying to document the issue because I have not paid any attention to the convert documentation for a long time as DePiep handles all that. The proposed edits are to three documentation templates:

Currently, each of the above is as it was prior to Sroc's edits. The first seems to involve using <code> and {{dcr}} and removing two MOS links (while leaving one). The second and third involve changing {{!xt}} → {{bxtd}} and {{xt}} → {{mxt}}.

These documentation templates are used at:

The first of these uses them like this: 

==Ranges of values==
...
{{Convert/doc/range separator list}}

==Parameter list==
{{convert/doc/parameter list}}

==Deprecated options==
{{Convert/doc/deprecations list}}

My first impression is that the issue is not sufficiently important to fuss over. DePiep is maintaining the documentation, so unless there is a significant problem it would be best to leave it to him. The only firm opinion I have other than that is that the gray coloring is too subtle to show a deprecated option, particularly when the list is sorted. Re the MOS links: it is overlinking, but I guess DePiep's reasoning is that someone would be looking for a specific option (perhaps by searching the page), rather than reading it through, so a link on the line of interest might be valuable. We could debate that but it does not seem important.

I have not examined the convert documentation for quite a while, but on skimming it now the only thing that I noticed was that {{navbox convert}} perhaps should have "(area ∙ energy ... volume)" moved so it does not appear after "Full list of units" because as it is, the "area" link should show the full list of units for area. Johnuniq (talk) 02:41, 9 December 2014 (UTC)

Do not misrepresent me: I'm no longer proposing grey or bold fonts. I propose the use of {{dcr}} for deprecated options, which renders as plain red text. This is appropriate for several reasons:
  1. It renders in red to indicate "wrong" (although colour should not be "the only method used to convey important information" and the fact that options are deprecated are indicated by the text in any case);
  2. When used with <code>, it preserves mono-spaced formatting (like this) as used for code, rather than substituting a serif font (like this), which is inconsistent with the formatting used for code throughout the documentation;
  3. It uses the correct <del> markup intended for deprecated text (although the strikethrough is hidden), so the documentation is correctly formatted for accessibility reasons.
  4. The {{xt}} and {{!xt}} templates are the wrong templates to use in this instance, as they are intended for examples, not code or template parameters. The documentation for those templates states:

    For cases where the serif typeface is not desirable (e.g. in blocks of computer code), use {{bxt}}, which substitutes boldfacing, or {{mxt}}, which substitutes a mono-spaced font.

    However, the documentation also explicitly states:

    The {{xtd}} template exists for deprecated examples. Its alias {{xtg}} (for "grey") can be used to indicate uncertain, unavailable, disabled, lorem, etc., examples without implying deprecation. The bold, sans-serif equivalent is {{bxtd}} (and {{bxtg}} alias). The mono-spaced equivalent is {{mxtd}}.

    So you are, in fact, advocating to maintain templates which are considered incorrect within their own documentation.
Other than a vague sense of "red, bad; green, good", what is your reasoning to buck the correct formatting? —sroc 💬 04:18, 9 December 2014 (UTC)
Quick & short: not only do did I rewrite the documentations, I did that with a coherent philosophy (ongoing). For the reader (that is: the editor who is using {{convert}} at that moment), the documentation should be crisp. As I wrote it, the deprecations follow MOS-style (style in which MOS is written. red=bad, green=good). I do not see any problem with that, and I don't know what is "vague" about that. Next, I did not make the "color only" error: in b/w print the text (sentence) says the same. My aim is to get the documentation right for the editor. (In detail: I can not accept the !-less template name(s), because I can not memorize it). I think the solution you are looking for is: class=deprecated. -DePiep (talk) 22:54, 9 December 2014 (UTC)
Does MOS actually state to use {{xt}} (green is good) and {{!xt}} (red is bad), or is it only by convention? More particularly, are these templates expressly advocated for use in code, and if so, why do the other template variations exist?
Why are you adamant that these templates using serif fonts should be used for code which is ordinarily presented in mono-spaced font? "I can not accept the !-less template name(s), because I can not memorize it" seems lazy ({{dcr}} is only three letters standing for "deprecated code red") and, more troublingly, a symptom of WP:OWN and WP:IDONTLIKEIT, neither of which justifies using the correct formatting. With all due respect for the work that you have done, that should not mean that others cannot question why things are the way you have done them. —sroc 💬 10:03, 10 December 2014 (UTC)
Don't know about MOS-about-MOS guidelines. I use them because of that convention, as I want to convey the same thing as MOS conveys. With this, I have don't need to contemplate why other templates exist.
Parameter switches making an alphabet soup don't work (with me, and in general), because the abbreviation is arbitrary and it mixes format & semantic (font & 'deprecated') meaning. It is not a memorisable setup. (I have made thousands of edits in template discussions, and I still do not know the list that should be clarified in {{tl/doc}}; for these reasons).
I note that you have not presented an alternative for the green=good format (you write it plain b/w). Leaving the red/green & bad/good juxtaposition does not help the reader IMO. Must say, since we write parameter names & options in <code> often, I assume the red/green values should strive to do that too. (In this, {{dcr}} is an improvement versus {{!xt}}).
As I said, there could be a class for such deprecated parameters (<del> means deprecated?). Still, I'd expect a helpful format with that. I don't expect an improvement for the documentation when using class only. -DePiep (talk) 14:41, 11 December 2014 (UTC)
Adding: If I understand it well, <del> tag is meant for deleted text (usually shown stricken). I'm not sure this is what we want to say in these {{convert}} deprecations; MOS-emulation looks better to me. -DePiep (talk) 14:46, 11 December 2014 (UTC)
Thanks for clarifying that when you referred to red/green being "MOS-style" you were not indicating that these are actually advocated by MOS for use throughout Wikipedia but rather that they are used for examples in MOS. Because {{xt}} and {{!xt}} are intended for example text (say this, not that) and they do not respect the monospaced fonts given by <code>, they are neither applicable nor ideal for use in code.
You accept that {{dcr}} is an improvement over {{!xt}} for use in deprecated parameters. I have not proposed a specific alternative for the {{xt}} format precisely because none is needed: the correct options should simply be given by plain <code> formatting just as they are throughout the documentation. What could be simpler or more intuitive than using the same format already used throughout the documentation? We don't need to pander to users by not only saying "abbr=commais deprecated, use comma=off instead" but having to put the correct version in green (as if to imply they cannot understand the words "use... instead"). Once again, it is necessary to use words to indicate where an option is deprecated rather than relying on colour alone, so it is redundant to insist on green being used in this instance where additional markup (that is, in addition to <code>) is not required. (Colours and serif fonts are used by the {{xt}} template to set it apart from the surrounding text; this is unnecessary when <code> already uses colours and fonts, and adding more colour/font combinations is unwieldy.)
I don't understand why you would suggest using a class to mark deprecated examples (and having to remember all of the code that goes with it) instead of simply using one of the templates provided for the specific purpose. For one thing, using templates makes it easier to update formatting uniformly in the future when required; having rogue classes is not as easy to deal with and, I dare say, would not be as easy for other contributors to use as templates. (By the way, the templates often mark formatted text with specific classes, which allows users to customise their appearance using CSS; using classes unexpectedly instead of using the proper templates for their intended purpose may have unintended consequences and undermine users' ability to control formatting on their screen.). —sroc 💬 15:25, 11 December 2014 (UTC)
So you understand what I wrote about style-used-for-MOS, but you did not read what I wrote right with that? That is a core of my point. re "accept that {{dcr}} is an improvement over {{!xt}}": I did not write that. You are putting words my mouth. re WP:COLOR: I answered that already; and also that answer is present in the formatting (so even if one missed my answer to this, one can check the guideline against the existing text, and rule this objection out). btw, do I read you conclude the opposite for the un-greened text? re all: these are three diversions from what I wrote. If that is the way you want to discuss, I cannot help or answer you; I'd be repeating myself. I'll leave your class & template paragraph to be answered later. -DePiep (talk) 11:22, 13 December 2014 (UTC)
I'm confused. You wrote: "In this, {{dcr}} is an improvement versus {{!xt}}". I wrote: "You accept that {{dcr}} is an improvement over {{!xt}} for use in deprecated parameters." You wrote: "I did not write that. You are putting words my mouth." Please clarify how what I wrote is not what you meant.
You wrote: "do I read you conclude the opposite for the un-greened text?" I don't understand what you mean? What is the "opposite"? What is "un-greened text"?!
I thought we were having a productive conversation, but I'm afraid I can't make much sense of your latest post. —sroc 💬 15:35, 13 December 2014 (UTC)
re 0. About my MOS-reply: In what I wrote about these red/green texts MOS lies about the core of my motivation, all thread long. It is disappointing you did not pick up that to continue on. 1. As you quote, I wrote In this (= in the previous sentence). You left that out, and then concluded wholesale agreement for me. That is incorrect. I pointed to one specific aspect of dcr. 3. "you conclude the opposite": we both know that we should not use meaning-by-color-alone. So the logic is: if one uses color, that same fact should be communicated in another way too. But you write: "... so it is redundant to insist on green being used ..." - Yes, it is redundant, but no that is no reason to remove the green. There can be a reason to use green. In fact, from your reasoning all colors are in WP redundant and so removable. (You're saying like: it's not required, so it can be removed. Removal may be your opinion, but it is incorrect as logical conclusion).
4. Yes the discussion was moving forward, but at this point I was asked to repeat my earlier texts to cut out these misreadings. That is not forward.
5. Simplified short, my reasoning is: I want to document these deprecations for the article editor who arrives at that template page (not a template technician). For that I use a MOS-internal standard to explain that. I think that is short & to the point: if it is good enough for a MOS-page, I am humble enough to copy-use it. (Versus: these are "deprecated" values rather than "example" values when looked from template-development, but going into that that does not benefit or help the visiting editor in any way). -DePiep (talk) 10:37, 15 December 2014 (UTC)
I must say that the numbering in your latest post is confusing as I don't understand what it relates to.
I think I understand that you believe that it is important to use green for good and red for bad because this is how examples are presented in MOS, and this is the crux of your resistance to change. Is that right?
What I think you are missing is the font styles that are used for particular purposes.
  • Example formatting: The {{xt}} and {{!xt}} templates are specifically designed to illustrate examples of correct and incorrect usage. For example, from MOS:

    Capitalize the title's initial letter (except in rare cases, such as eBay), but otherwise follow sentence case, not title case; e.g., Funding of UNESCO projects, not Funding of UNESCO Projects.

    In this context, the examples are set out from the surrounding text by a serif font in addition to the relevant colour.
  • Code formatting: As you know, code such as template parameters is formatted using <code>. For example, from Template:Convert/doc:

    {{convert|2|km|mi}} → 2 kilometres (1.2 mi)

    This sets the code apart from the surrounding text by formatting it in a monospaced font, in dark grey colour, with a light grey background and with a dark grey background.
The {{xt}} and {{!xt}} templates are not a suitable substitute for <code> markup because they do not format them as code and do not facilite their use in wider examples. For example, it does not lend itself to providing examples which include code alongside other text:

Don't use {{convert}} in titles: write The Proclaimers' "I'm Gonna Be (500 Miles)", not The Proclaimers' "I'm Gonna Be ({{convert|500|Miles}})"

Even when {{xt}} and {{!xt}} are used within <code>, the proper formatting (in particular, the monospaced font for code) is lost:

disp=u2 is deprecated. Use disp=unit2 instead

That is because the templates are used for a distinct purpose (example text) which is incompatible with <code> which is used for a distinctly different purpose (code). This is why the {{deprecated code}} template (and its cousin {{dcr}} for deprecated code red) exist for the exact purpose of indicating code options which are deprecated:

disp=u2 is deprecated. Use disp=unit2 instead

It is unnecessary to apply a separate colour to the <code> format for the correct code option because all correct code options use the same monospaced grey formatting to set it off from the surrounding text, just as serif green formatting is used consistently to set off examples from surrounding text. Adding a third colour to the sequence (red, green and grey) would be redundant as green and grey both indicate available code options.
I'm not sure I can put it any more clearly than that. —sroc 💬 11:52, 15 December 2014 (UTC)

Formatting of deprecated examples (break)

It looks like this discussion in a deadlock. Someone made shiny new templates and now we don't use them. (In fact, this is what I was afraid of by having so many different formatting templates.) Here's my take: we want to show example code; we now have three templates we can use: {{mxt}}, {{!mxt}} and {{mxtd}}; which are good, bad and deprecated. Strangely, we don't seem to have an example template for black monospaced text... Hmm. Anyway, these are your choices. -- [[User:Edokter]] {{talk}} 12:28, 15 December 2014 (UTC)

That's mixing format, semantics and intention again (plus alphabet soup - having to look what that "m" meant is not a pleasure. Same horror as is the as {{tl}} documentation). Someone might come along or be here already and claim that "bad" and "deprecated" are the same, which puts us back to square one. Plus, formally these are not examples but options, and wikitext not code. BTW, I note that the grey {{mxtd}} text on documentation background (light green) fails the AAA contrast check (5.18:1). -DePiep (talk) 13:00, 15 December 2014 (UTC)
(edit conflict)But you're trying to equate bad examples (shown in {{!xt}}) with deprecated code by using the same formatting for both. Crying because you had to look up what "m" means (when someone else points out the correct template you should use) is lazy and ignorant, and insisting that we should stick to the format you used because you did it (in the face of rational arguments that your format is wrong) contravenes the Ownership policy and is an example of I just don't like it. —sroc 💬 13:18, 15 December 2014 (UTC)
And there is the root question: why is {{xt}} using a different font? (yeah 'because it's something different' I know, duh, then let's answer this: why not give them the same font?) -DePiep (talk) 13:08, 15 December 2014 (UTC)
"why not give them the same font?" Which? Are you proposing to make {{xt}} and {{!xt}} all monospaced or <code> serif across the whole Wikipedia? Why should they change? What are you on about?!
The purpose of formatting examples in serif font is so they are set apart from their surroundings. The purpose of formatting code in a monospaced font is to that it is set apart from its surroundings and, perhaps more significantly, so that it appears in uniform width to enable code across multiple lines to be lined up. They serve distinctly different purposes and are not meant to be the same. I went to great pains to explain this to you above. Can you still not see that? —sroc 💬 13:23, 15 December 2014 (UTC)
"Crying"? The documentation is horrible. And, as I already wrote, it does not clarify the need for difference. -DePiep (talk) 15:00, 15 December 2014 (UTC)
Well, if you don't understand a question I write, just ask don't judge & conclude. "Why should they change? What are you on about?!" and linking to a WP page is not a contribution. Or, if you understand this: it's WP:IDIDNOTHEARTHAT. sroc, when you are back into civil talking I might take time to respond. -DePiep (talk) 15:08, 15 December 2014 (UTC)
  • I tend to conclude that we should use the red/green templates Edokter mentions here (but not the deprecated one). I'll have to swallow some of my objections, since we cannot solve this without a compromise. To be fair, I'll take another serious look first at the whole sroc proposals process in this thread. -DePiep (talk) 11:00, 16 December 2014 (UTC)

Deprecation of adj=1

|adj=1 makes the unit name singular when number is 1 or less, but not zero. This is in conflict with MOSNUM which states "Nouns following simple fractions are singular ... Nouns following mixed numbers are plural ... Nouns following a number expressed as a decimal are plural". Let's deprecate it and get rid of it. Jimp 03:24, 3 December 2014 (UTC)

Deprecate. I understand that the applicable MOS-prescription can be derived from the actual number, in a complete algorithm. No need for manual exceptions then. -DePiep (talk) 11:11, 3 December 2014 (UTC)
Will change documentation after a Johnuniq response on this. -DePiep (talk) 12:35, 5 December 2014 (UTC)

Looking at the converts used in May 2014, there are only four places where omitting adj=1 would make a difference. In each of the following, omitting adj=1 would make the input unit plural:

I'm inclined to think that singular is correct in the first two converts, although a justification would be difficult. The second two probably should be plural. I guess that means I'm sitting on the fence again. However, deprecation is fine as (last May) it was only needed twice out of 1.8 million converts, and now that I look again, perhaps the first two would be fine with plural. Johnuniq (talk) 03:11, 6 December 2014 (UTC)

I'm inclined to think that they all should be plural. The only justification of the singular for nouns after decimals between 0 and 1 I've ever seen seems to rest on a confusion between decimals and fractions. However, what we may or may not think isn't relevant here, MOSNUM states clearly that they should be plural. If MOSNUM has it wrong, then the discussion belongs on WT:MOSNUM. Once upon a time this template followed the MOS, that is we took it as a given that the MOS should be followed, and where the MOS was unclear or just wrong it was fixing not evading which the MOS needed. I hope we can return to this ethos. So, I urge that |adj=1 be removed (not just from the documentation but from the code). If some day MOSNUM is changed, we should deal with it then (but not using |adj= since it hasn't anything to do with adjectives). Jimp 01:00, 12 December 2014 (UTC)
In documentation:
  • adj=1 is deprecated. No need to deviate from MOS regarding plurals
On how & when to remove deprecations from code, we've talked before. -DePiep (talk) 10:39, 17 December 2014 (UTC)

How do I put (the same) text before both input and output units?

Is there a way to put the adjective before both the input and output units?

e.g. {{convert|3.5|ha|acre|million|adj=pre}} produces:

3.5 million hectares (8.6 acres)

Which is patently not the right conversion. I of course want:

3.5 million hectares (8.6 million acres)

(I realise this is a little contrived but there are real examples when I want to do similar things, and this is a simple example of the general problem.)

It was probably not a good idea to shoehorn this "add arbitrary text" feature into the adj= parameter; but we have what we have (and I for one am glad that we have it and use it a lot, bless all who sail with her: if this is any recommendation, when I translate articles from other Wikipedias that are in metric, I can totally rely on convert giving me the right answer and all I ever need to do is knock the precision or something trivial like that to make it read nicer). Si Trew (talk) 15:55, 4 December 2014 (UTC)

I tried adj=both but that didn't work. It would be cool if it did, though. Si Trew (talk) 16:10, 4 December 2014 (UTC)
A problem you introduce is that part of the number is turned into an (ineffective) word. "million" has a meaning in the measurement (to compare: use "cultivated" hectare). This next one would keep the maths right, but does no allow you to control-format the result:
{{convert|3.5|e6ha|e6acre}} → 3.5 million hectares (8.6×10^6 acres)
-DePiep (talk) 16:16, 4 December 2014 (UTC)
Nice to see you DePiep.
Oh I'm "introducing" problems ? I was trying to solve them! :) (Or rather, moan about them and let someone else solve them...)
But I don't want engineering units of ten to the power of six. Yes, I understand those. Yes, they make no sense in a general article: I want "million".
Take your example "cultivated": I might still want "cultivated hectares" and "cultivated acres", to be absolutely clear that I am not talking about cultivated hectares but then about run-to-seed (or general-purpose) acres, but a specific kind of acre. As it stands, I rescan the sentence to "he cultivated {{convert|whatever|acres}}", but that is not quite the same thing if the "cultivated hectare" or "cultivated acre" is a well-known unit of measure in the field of cultivation.
This is not the same kind of qualifier as "long ton" or a "light year" where these are just compound adjectives for the units and are inseparable words (in many languages they would be just one word, I would argue they are one word that happens to have a space in the middle, but that's a linguistic argument).
Let's pretend that a banana ton is the weight/mass of a crate of bananas, including the weight of the crate but minus the monkey. A banana pound, banana kilo etc are defined with the ratios to the SI kilo, etc. So there is no point in us generating a whole series of banana unit conversions when we can prefix each with "banana" to mean "add crate, remove monkey, whichever unit you use". It is not so much "ineffective" but "descriptive", and presumably we could link (in the descriptive text where "million" goes above) [[Banana units of measurement|Banana]] which would describe how a banana ton differed from a ton or tonne.
It just seems like Occam's razor not to have to clutter {{convert}} with these kind of derived "descriptive" units, which are very common. Si Trew (talk) 16:54, 4 December 2014 (UTC)
1. With "ineffective" I meant to say "has no effect on the measurement value" (as "cultivated" has not). 2. You can define a "banana ton" that way, but are we supposed & allowed to convert that to "banana stone", as if that one is defined? 3. Within SI, the rule is: don't alter the value (number nor unit) with qualifiers, but add it to the quantity: "Weightbanana Trew's way without Trew's pet monkey = x ton (y stone)". 4. A "million hectare" is still not equal to "Trew's hectarewithout the monkey", for the number/definition difference. 5. think the issue is not within {{convert}} per se, but what you intend to write even without {convert}. Nothing of this all answers your question. -DePiep (talk) 17:19, 4 December 2014 (UTC) (don't edit this post. -DePiep (talk) 12:14, 5 December 2014 (UTC))
Excuse me for putting my answers inline, hope that is OK with you. No, I don't think it does answer it. I hope you take it as a compliment that I rarely come here now because convert does a great job. I have not put this tiny niggle I have with it very well, but I think it is easily fixed if I could express myself better. Si Trew (talk) 17:38, 4 December 2014 (UTC)
Inline answering didn't work so here goes:
  1. Fair enough, I agree with that.
  2. Deliberately I made up a definition. There are others in real life but I have terrible trouble finding examples when I need them. You have to take my word for it, it crops up a lot.
  3. Wikipedia is not SI. It depends. If the article is technical, sure, SI units and so on are the way to go: in a general purpose article that is not metrological or scientific, to put it in "human" units is more important. Sometimes I say "about a kilometre, or half a mile", for that reason. You and I both know that a statute mile is 1609 metres by definition, but it doesn't help to say so.
  4. No idea what you mean here. I want a million Trew's hectares (banana hectares), and a million Trew's acres, to be in the same ratio as an SI hectare to an SI-derived acre.
  5. It's difficult to give a concrete example, because I rescan the sentences to avoid jumping out of the frying pan, into the fire, as Fowler has it (odd that it is not mentioned there; I may add it; if nothing else some good has come of this!)
Si Trew (talk) 17:51, 4 December 2014 (UTC)
Rather than adding a |adj=both, perhaps |adj=pre should be deprecated and |prefix= & |suffix= added? -- WOSlinker (talk) 18:57, 4 December 2014 (UTC)
The documentation for this is at Help:Convert#Extra words. DePiep had it right, but you want abbreviation off.
  • {{convert|3.5|ha|acre|disp=preunit| cultivated |banana }} → 3.5 cultivated hectares (8.6 banana acres)
  • {{convert|3.5|e6ha|e6acre|abbr=off}} → 3.5 million hectares (8.6 million acres)
Johnuniq (talk) 21:46, 4 December 2014 (UTC)

I would have to agree that it "was probably not a good idea to shoehorn this 'add arbitrary text' feature into the adj=". In fact I would go so far as to say that it was an incredibly bad idea. I could explain how it happened (I could even take the blame for creating the framework which prompted it ... prompted not necessitated) but with the Lua version there's no reason to do things this way any more. WOSlinker has it right, no |adj=both should be added and |adj=pre should be deprecated. |disp=preunit has also got to go. Now that we have the capability to add new parameters (strictly speaking, the capacity was there in the old version, it was just a little tricky) we need not continue abusing existing parameters to do jobs which have nothing to do with their purpose. Instead it's time to start reversing the abuses of the past. Abusing a parameter like this not only makes certain uses impossible (e.g. you can't have |disp=preunit and |disp=table in the same call) but it makes the template unnecessarily perplexing for the user. What we really need are new parameters like WOSlinker suggests. However, I'm not sure that |prefix= & |suffix= would be sufficient. We may want to add text in front of the number, between the number and the unit or after the unit. We may want the text added to the input or to the output. The first three options multiplied by the second two give six places to add text (as were possible with {{convert/f}}). For convenience, though, adding text to both input and output could be considered a third option and thus I'd be asking for nine new parameters (things get a bit more complicated still when we start considering the case of multiple output units). So, for example, |prefix=+ would add a "+" in front of all numbers, |suffix_in=&nbsp;long would add " long" after the input unit and |midfix_out=&nbsp;cultivated&nbsp; would add " cultivated " between the number(s) and unit(s) in the output. Jimp 02:15, 12 December 2014 (UTC)

Quick notes: yes, a general redesign for these additions would be good. Possible other points to think of:
  • There are not six, but seven places to add text. The seventh would be the very end suffix.
  • A solution for whitespace is needed (add/prevent space, linebreak)
  • |adj=on affects spelling & punctuation (or must I manuyally change the word added)?
  • Adding a reference might imply a different handling (for that same position)
  • Multiple output units to be considered
  • Word interacts with brackets?
This is not to discourage us, but to reach a comprehensive set of options (complete, systematic, easy to remember, flexible, ...). -DePiep (talk) 13:32, 17 December 2014 (UTC)

Odd lack of pluralisation – bug?

I recently discovered that some combinations of options can produce singular unit names in contexts where that is not appropriate. For example, {{convert|600|mi|km|order=flip|sigfig=1}} produces this output: "1,000 kilometres (600 mi)" (it should obviously read "1,000 kilometres"). But if I change the unit order manually to {{convert|1000|km|mi|sigfig=1}} then it's fine: 1,000 kilometres (600 mi). Archon 2488 (talk) 14:20, 24 November 2014 (UTC)

Archon 2488, the funny quirk is that {{convert|600|mi|km|order=flip|sigfig=1|adj=1}} fixes it, but shouldn't really do anything in this case since the values are greater than 1. Frietjes (talk) 21:31, 24 November 2014 (UTC)

Interesting bug—this is the first example of broken code that I recall so thanks for reporting the problem. It occurs when the output is not abbreviated and sigfig causes the value to sort-of overflow. These examples use foot/feet to show it is nothing to do with km:

  • {{convert|999|ft|ft|abbr=off|-1}} → 999 feet (1,000 feet) [good: output is plural "feet"]
  • {{convert|999|ft|ft|abbr=off|sigfig=2}} → 999 feet (1,000 feet) [good: output is plural "feet"]
  • {{convert|999|ft|ft|abbr=off|sigfig=1}} → 999 feet (1,000 feet) [bad: output is singular "foot"]

I'll have to examine the history of the code that determines whether the value is singular/plural because at the moment I can't see how it would ever work with sigfig. I'll slowly ponder that soon. Using adj=1 forces different code to be used; that code uses the singular unit name when the value v satisfies:

(−1 <= v and v < 0) or (0 < v and v <= 1)

The adj=1 code works independently of sigfig so it does not suffer from the bug. The standard code (when adj=1 is not used) inspects the rounded output and only regards "1" or values like "1.00" to be singular. The bug occurs with sigfig because it regards "1000" as "1" with an exponent, and stupidly uses the "1" to conclude it is singular. Johnuniq (talk) 01:36, 25 November 2014 (UTC)

While examining the code, I see it is also possible to trigger the bug like this:

  • {{convert|9|ft|ft|abbr=off|-1}} → 9 feet (10 feet) [bad: output is singular "foot"]

The cause is exactly as described above—this unusual rounding also gives a result regarded as "1" with an exponent. The fix is easy but I'll take a while pondering it. Johnuniq (talk) 06:39, 25 November 2014 (UTC)

Singular bug fixes

I found another problem with how singular unit names work with output fractions and have put fixes for all the problems in the sandbox. I also implemented a change suggested by Jimp at #What happened with abbr=~ ? above (where I will put an example). Examples of the singular/plural issue follow (these use the live convert and convert/sandbox templates and so will change when the modules change). The example using 1+1/2 is just to show that "feet" is used when fraction > 1 (same for old and new code).

Convert convert output convert/sandbox output
{{convert|1/2|ft|ft|frac=2|abbr=off}} 1⁄2 foot (1⁄2 foot) 1⁄2 foot (1⁄2 foot)
{{convert|1/2|mi|mi|abbr=off|frac=2|spell=on}} one-half mile (one-half mile) one-half mile (one-half mile)
{{convert|1+1/2|ft|ft|abbr=off|frac=2}} 1+1⁄2 feet (1+1⁄2 feet) 1+1⁄2 feet (1+1⁄2 feet)
{{convert|999|ft|ft|abbr=off|sigfig=1}} 999 feet (1,000 feet) 999 feet (1,000 feet)
{{convert|9|ft|ft|abbr=off|-1}} 9 feet (10 feet) 9 feet (10 feet)
{{convert|1.0|ft|ft|abbr=off|sigfig=2}} 1.0 foot (1.0 foot) 1.0 foot (1.0 foot)

@Jimp: Is there a reason that −1 uses a plural name while 1 uses singular? The question is purely academic because I don't think the issue arises, however it may as well be fixed, if wanted. The following shows what convert (and convert/sandbox) do:

  • {{convert|1|ft|ft|abbr=off}} → 1 foot (1.0 foot) (singular foot)
  • {{convert|-1|ft|ft|abbr=off}} → −1 foot (−1.0 foot) (plural feet)

Around 2000 converts in articles use negative temperatures (where singular/plural does not arise because symbols are used), and another 400 use negative values with other units. That's more than I expected, but none of them involve −1 with a unit name so the issue does not matter. However, should the module be changed so the second example above uses "foot" for input and output? Johnuniq (talk) 03:14, 1 December 2014 (UTC)

I can't think of any good reason fort −1 to use a plural name. It must be an error. Jimp 22:22, 2 December 2014 (UTC)

Singular by unit name

I ran into these examples:

  • {{convert|2|foot|m}} → 2 foot (0.61 m) -- ? Singular by input name
  • {{convert|2|feet|m}} → 2 feet (0.61 m)
  • {{convert|2|ft|m}} → 2 feet (0.61 m)
  • {{convert|2|metre|cm}} → 2 metres (200 cm) -- Into plural
  • {{convert|2|metres|cm}} → 2 metres (200 cm)
  • {{convert|2|m|cm}} → 2 metres (200 cm)

The first example appears to be singular because of the input name only ('foot' is singular). This may be a feature not a bug (and so we better document it). But I find it unexpected, and does not work consistently seeing the metre demo. I remember we discussed this earlier this year, but I thought I'd mention it. Especially since I really was wrongfeeted when writing about these plurals in HELP:Convert. -DePiep (talk) 07:45, 2 December 2014 (UTC)

The foot unit is specifically intended to give "foot" as the plural name. I forget where I saw it mentioned, but apparently there are situations where that usage is followed. There are several other "foot" units where the same rule applies, examples: board foot and cufoot and foot/s. There are hundreds of converts using these, although it is hard to know if they are intentional (perhaps an editor used "foot" without realizing what it would do). Johnuniq (talk) 09:28, 2 December 2014 (UTC)
So there is a grammatical background for this? To cover intentional/unintentional use (as I ran in to), the singular form better be covered by |adj=1. Reduce exceptions in documentation. -DePiep (talk) 09:37, 2 December 2014 (UTC)

These were introduced (as Johnuniq mentions) to handle the fact that some use "foot" as a plural. This is a different situation to what |adj=1 was introduced for. There are a couple of problems with using |adj=1 here.

  • |adj=1 applies to all units (input and output).
  • |adj=1 only applies to number between −1 and +1.
  • |adj=1 contravenes MOSNUM and should be ditched.

Jimp 22:13, 2 December 2014 (UTC)

So, let me check:
  1. In the outside world, "foot" can be used as plural (equal to: "feet")
  2. This is correct by English language
  3. This is correct for writing measurements
  4. This is valid for all English variants (ENGVAR: en-US, en-GB, ...)
  5. There is no restriction (like: when sourced only, or in era X–Y only)
  6. This wiki accepts that as being correct (though not written in a MOS)
  7. {{convert}} uses the word spelling 'foot' to implement this
-DePiep (talk)
As far as I'm aware this is correct (though "foot" as plural might be a mainly British thing). Jimp 02:19, 12 December 2014 (UTC)
I have added this foot exception to the /doc, but not prominently. -DePiep (talk) 14:20, 17 December 2014 (UTC)

What happened with abbr=~ ?

Technically, we can |abbr=~ to have both name and symbol returned:

  • {{convert|100|Mm|nmi|abbr=~}} → 100 megametres [Mm] (54,000 nmi)

Document or deprecate? -DePiep (talk) 14:40, 18 November 2014 (UTC)

It's a strange option and I don't see how it helps. In May 2014 it was used in the following.
  • Chupaca Province {{convert|297|km|0|sp=us|abbr=~}} → 297 kilometers [km] (185 mi)
  • Constant linear velocity {{convert|18.96|m/s|abbr=~}} → 18.96 metres per second [m/s] (62.2 ft/s)
  • Dots per inch {{convert|0.22|mm|in|abbr=~}} → 0.22 millimetres [mm] (0.0087 in)
  • Festuca porcii {{convert|0.7|–|1.2|mm|abbr=~}} → 0.7–1.2 millimetres [mm] (0.028–0.047 in)
  • Mariner 1 {{convert|1.04|m|ft|2|abbr=~|sp=us}} → 1.04 meters [m] (3.41 ft)
  • Pell City, Alabama {{convert|27.2|sqmi|km2|abbr=~}} → 27.2 square miles [sq mi] (70 km2)
  • Puerto Errado {{convert|30|MW|hp|-2|abbr=~}} → 30 megawatts [MW] (40,200 hp)
  • Road signs in New Zealand {{convert|10|km/h|mph|1|abbr=~}} → 10 kilometres per hour [km/h] (6.2 mph)
  • Sarnia Photovoltaic Power Plant {{convert|247|MW|-2|abbr=~}} → 247 megawatts [MW] (331,200 hp)
  • Wolverine (train) {{convert|110|mph|0|abbr=~}} → 110 miles per hour [mph] (177 km/h)
Someone (Jimp?) may like to check those and decide whether they are useful. I would deprecate. Johnuniq (talk) 02:42, 19 November 2014 (UTC)
I'd like to use it as a debug-option (return both to explain what happens). -DePiep (talk) 11:25, 19 November 2014 (UTC)
I s'pose I get the idea behind it but you'd have to admit that it just doesn't look right. It'd be pretty hard to figure out what these are trying to say unless you already know ... and in that case there's no point. I can only assume that the lack of use is a reflexion of its undesirability. I'm not going to miss abbr=~. Jimp 07:32, 23 November 2014 (UTC)
Deprecated in the /docs then. (Jimp, I think Johnuniq suggested you take a look at the list & code it out. Better not me). -DePiep (talk) 21:13, 24 November 2014 (UTC)
Conclusion
  • abbr=~ is deprecated. Use abbr=on/off/in/out. (|abbr=out is default behaviour)
DePiep (talk) 21:13, 24 November 2014 (UTC)
Turned over: OK again. See discussion + outcome below. -DePiep (talk) 12:36, 21 December 2014 (UTC)

Update I just noticed the hidden Category:Pages using duplicate arguments in template calls on this page and have edited the above to remove the cause (the convert in Mariner 1 had sp=us duplicated). I was going to remove the duplicate from the article as well while removing the strange abbr=~, but looking at the article I can now see the point of the option: it's in a sentence saying:

Mariner 1 consisted of a hexagonal base, 1.04 meters (m, 3.41 ft) across and 0.36 m thick (1.2 ft)

and omitting abbr=~ wouuld give:

Mariner 1 consisted of a hexagonal base, 1.04 meters (3.41 ft) across and 0.36 m thick (1.2 ft)

which might cause readers to wonder why the first value says "meters" but the second says "m"—are they different? At any rate, I fixed the duplicate argument on this page and will leave the article for another time. Johnuniq (talk) 10:25, 25 November 2014 (UTC)

Looks like this enters the MOS/style area of "spell in full at first mentioning, after that use the symbol". A neighbouring area, not limited to wiki, is: "Always introduce the abbreviation/symbol together with its full name". With lesser-known units this looks like good editorship. An example sentence:
"The engine had a capacity of 1,000 horsepower [hp] (0.75 MW), later upgraded to 1,200 hp (0.89 MW)."
Punctuation could be improved, maybe into:
"1,000 horsepower [hp] (0.75 MW)"
For now, I think we should keep it deprecated and first redesign its styles & workings. Let's try to get the style advice first (documentation/MOS text on usage). -DePiep (talk) 13:26, 25 November 2014 (UTC)
I think the sentence would read a whole lot better if either both were spelt out in full or both were abbreviated (i.e. "1.04 meters across and 0.36 meters thick (3.41 by 1.2 ft)" or ""1.04 meters across and 0.36 m thick (3.41 by 1.2 ft)"). Were aren't in the business of accommodating bad style (and using bad style to do so is a dubious improvement). I don't believe "spell in full at first mentioning, after that use the symbol" was ever meant as a strict rule never to be bent or broken and in this case I'd argue that clarity trumps this. "1,000 horsepower [hp] (0.75 MW)" would be an improvement. Jimp 11:56, 27 November 2014 (UTC)
Within one sentence - OK, but that misses my point. Let me refine my example: think the two instances sentences apart, maybe even in a different section. For that an editor would like to have the option to introduce a lesser known symbol/abbreviation. (Sort of the 'link once at first mentioning' habit; this one textual only).
Eh, {convert} is accomodating styles isn't it? What bad style do you mean wrt introducing the abbreviation/symbol? Please explain.
I do not propose adding a strict rule or obligation. I do propose too introduce a style-based option. For cases an editor wishes to use one. For that, I first want us to describe that style (instead of setting code for it). -DePiep (talk) 13:04, 27 November 2014 (UTC)
I would treat spelling out of unit names as inelegant. Common units like m and kg are familiar enough to even Americans. Some of them may not know exactly how long or heavy it is but at least they know we are talking about length and weight. And since there is a nice familiar mile/foot/inch or ton/pound/oz figure right next to it, there should be no confusion. For units that are more obscure to the layman (e.g. P for Pascals) we can use links.  Stepho  talk  13:43, 27 November 2014 (UTC)
Yes, and no changes in this.
The topic is: can an editor add an introduction of the symbol? Note that the link (to exemplary Pascal, horsepower here) does not serve this purpose. Question: should {convert} make possible to introduce the symbol with the name? (symbol = 'abbreviation' in {convert} speech). That is, allow {convert} to write
  • "1,000 horsepower [hp] (0.75 MW)" Question?
Consider this primarily a textual issue (like one could meet in print). It is not the question "what is Pascal", but "written 'Pascal' here, further it will be written as symbol P". -DePiep (talk)
I hope it would be written as "Pa" ;) Archon 2488 (talk) 18:56, 27 November 2014 (UTC)
Correct, I should have said "Pa" for Pascals.  Stepho  talk  22:17, 28 November 2014 (UTC)
Yes, we should be accommodating but up to a point. There should be no need to accommodate that which is undesirable. The bad first style I was referring to here is spelling a unit out in full in one part of the sentence and then abbreviating it in another. The second bad style is the confusing system of putting both the abbreviation and conversion(s) inside the same set of brackets. Of course, if you're introducing a lesser know unit which you'll be using later on, then you'll want something like this, but "1,000 horsepower [hp] (0.75 MW)" or "1,000 horsepower (hp) (0.75 MW)" is better than "1,000 horsepower (hp, 0.75 MW)".
I wonder, though, whether using abbr=~ is the best way to do this. Perhaps it would be better to have (a) parameter(s) to insert text into the output (like was done with {{convert/f}}). We could use the parameter not only to add the abbreviation but to add anything, e.g. "wide" or "per year". Jimp 01:08, 30 November 2014 (UTC)
please' stop talking about spelling out/not spelling out. That has nothing to do with |abbr=~.
I object to adding such text manually. {Convert} has the right symbol available! Leaving it to the editor as free text allows unchecked mistakes. Also the formatting will not be alike. -DePiep (talk) 12:38, 1 December 2014 (UTC)

Need opinions on abbr=~

As an experiment, I have put Jimp's above idea in the sandbox (the possibility of having a more general syntax will have to wait). Examples:

Convert convert output convert/sandbox output
{{convert|1.04|m|ft|2|abbr=~|sp=us}} 1.04 meters [m] (3.41 ft) 1.04 meters [m] (3.41 ft)
{{convert|9|kPa|abbr=~}} 9 kilopascals [kPa] (1.3 psi) 9 kilopascals [kPa] (1.3 psi)
{{convert|9|kPa|disp=sqbr|abbr=~}} 9 kilopascals [kPa] [1.3 psi] 9 kilopascals [kPa] [1.3 psi]

Should this change be permanent? Also, please see #Singular bug fixes below for a question regarding singular/plural. Johnuniq (talk) 03:15, 1 December 2014 (UTC)

  • So, bring the symbol outside of the brackets: yes. (Guess that is the core proposal).
However, I do not appreciate the brackkets being the same for [symbol] and [number * other symbol]. In measurement values, they are not the same. Simply, use "[]" always or, less simple, use the opposite of the chosen brackets (use "(Hp)" when editor asks for sqbr).
The inverse order "9 kPa [kilopascals] [1.3 psi]" is not possible (because abbr is used already). Just noting.
I propose to drop the unconnected |abbr=~ and add parameter option |abbr=intro for this. -DePiep (talk) 12:46, 1 December 2014 (UTC)
The use of disp=sqbr is very rare (118 instances out of 1.8 million converts in May 2014, none of which used abbr=~), so let's forget about optimizing its appearance. It would be easy to always use square brackets, so the question is which of the following is better:
Mariner 1 consisted of a hexagonal base, 1.04 meters (m) (3.41 ft) across and 0.36 m thick (1.2 ft)
Mariner 1 consisted of a hexagonal base, 1.04 meters [m] (3.41 ft) across and 0.36 m thick (1.2 ft)
The first balloon burst at pressure 9 kilopascals (kPa) (1.3 psi) and the second at 12 kPa (1.7 psi)
The first balloon burst at pressure 9 kilopascals [kPa] (1.3 psi) and the second at 12 kPa (1.7 psi)
I'm happy with either, although perhaps inclining towards [...]. Johnuniq (talk) 01:31, 2 December 2014 (UTC)
I prefer "[ ]" too, because of the alternation with the "( )" brackets for the regular converted output. And indeed no need to alter.
Then I stumbled upon this in WP:MOS#Units_of_measurement: "Potentially unfamiliar unit symbols should be introduced parenthetically at their first occurrence in the article, with the full name given first: for example, Her initial betatron reached energies of 2.3 megaelectronvolts (MeV), while subsequent betatrons achieved 300 MeV." (and in slightly different words in WP:UNIT). So MOS already supports the point of introduction. However, it uses round brackets, in absence of any conversion value. This would be against my reasoned preference, so I think I'll have to talk with MOS. -DePiep (talk) 06:47, 2 December 2014 (UTC)
  • @Johnuniq:, did you consider the suggestion for |abbr=intro (or another option value) for |abbr=~? -DePiep (talk) 12:32, 5 December 2014 (UTC)
    • Yes, I thought about it, but I can't see something that would really fix the problem. We agree that abbr=~ is peculiar and uninformative. Perhaps abbr=intro is an improvement, but I think it would still be puzzling to people looking at the wikitext, so it's not a perfect solution. The code calls it "also symbol", but as mentioned, I don't like long options such as abbr=name and symbol or abbr=also symbol, and abbr=+sym or abbr=namsym are too weird. On principle I think we should avoid adding an option which seems to be merely better because if someone got used to it, we would cause trouble if we ever find a "perfect" solution (like when we decided to use order=flip). I don't oppose adding intro, but I'm not sure we should. Anyone want to offer an opinion? Johnuniq (talk) 02:49, 6 December 2014 (UTC)
1. Only just read that you have postponed these topics, not denied. OK. No hurry then.
{{collapse top}}
2. Indeed, no long (spaced!) option names, nor uncommon code-like shortcuts. 3. I respectfully disagree about "let's skip Better until we have Perfect". Simple: if a more dedicated solution would occur, the habit must change whatever. So it's a change needed from |abbr=~ too; the problem is there already. 4. An editor looking in wikicode seeing "|abbr=intro" is more puzzled then when seeing "|abbr=~"? 5. If you have plans to make it a dedicated parameter as you suggest, please tell us. -DePiep (talk) 10:28, 6 December 2014 (UTC)
{{collapse bottom}}
(I fold & postpone, to reduce time pressure this might introduce). -DePiep (talk) 18:01, 7 December 2014 (UTC)

Un-deprecated

Per the above discussion, and per version 7 of the module (10 December 2014 changes), it is an accepted option.

  • abbr=~ is deprecated. Use abbr=on/off/in/out (|abbr=out is default behaviour)

So, it is available and documented as such. Details of the discussion might be open still. -DePiep (talk) 12:02, 16 December 2014 (UTC)

non-breaking hyphen

When using |adj=on, there is a hyphen between value and unit - that's what it's all about. However it is possible for the text to wrap, so that you can get, for instance, 18-
acre sanctuary. = not good. Instead of a soft hyphen, can you use a non-breaking hyphen {{nbhyph}} or at least make it specifiable? Unbuttered parsnip (talk) mytime= Wed 15:51, wikitime= 07:51, 17 December 2014 (UTC)

I'm not sure about that. Jimp will probably notice this and explain the MOS background, but there is a design decision that, for example, "18 kg" uses a nonbreaking space, while "18 kilogram" does not. The same applies to all units: using the name means there may be a break, while using the symbol means there will not be a break. Applying that principle to hyphens suggests that a break would be recommended by MOS (and adj=on is generally ignored when abbr=on applies). Johnuniq (talk) 08:48, 17 December 2014 (UTC)
I would say that the style should be the same as for any other compound adjective. MOS:HYPHEN says that the use of soft hyphens within compound adjectives is broadly discouraged unless they are extremely long, because they can make the source hard to read, but of course that is not a problem for the template. Glancing over it, I don't see any general guidance about when to allow a compound adjective to be line-wrapped. My instinct is to avoid line breaks in the middle of such compound expressions except in rare cases where they are extremely long (in which case they should probably be reformatted anyway) – this should give the most readable result. Archon 2488 (talk) 15:42, 20 December 2014 (UTC)
When's it going to happen? MOS:HYPHEN says it should be a nonbreaking-hyphen {{nbhyph}}, so what's the big deal? I don't see how re-formatting has anything to do with it, because pages on my pc look quite different from on my phone.--Unbuttered parsnip (talk) mytime= Tue 19:53, wikitime= 11:53, 23 December 2014 (UTC)
As noted above, the hyphen belongs there per MOS:HYPHEN (which is merely a reflexion of standard English punctuation). I would agree that a non-breaking hyphen would be an improvement. (No, you can't predict where the line is going to end.) Jimp 14:06, 23 December 2014 (UTC)
MOS:HYPHEN merely says that &#8209; is a code that can be used for a non-breaking hyphen. The wikitext for the examples uses "-" (normal hyphen), and it does not say that the examples should use a non-breaking hyphen. I recall Jimp explaining a long time ago that cases like "18 kilograms" use a breaking space, and I thought that Jimp would extend that reasoning to conclude that "18-kilogram" should use a breaking hyphen. That kind of issue is not something that should be resolved here—the question should be explored at MOS talk. If the decree is that a non-breaking hyphen should be used, I just ask that some rationale be provided to explain why the space would be breaking but the hyphen not. Johnuniq (talk) 22:24, 23 December 2014 (UTC)

Obscure units

Many new articles have recently been created, each on an obscure unit. They are off-topic for convert, but people with an interest in units may want to look at an overview of the articles I put here (permalink). Johnuniq (talk) 22:48, 23 December 2014 (UTC)

Fractional length units

Whenever I use |spell=in for fractions, I get frustrated by the output, for example:

  • One-quarter mile (400 m)
  • Three-quarters mile (1.2 km)
  • One-half mile (800 m)

I think a quarter-mile and half-mile would be a better unit to use, especially for the 3⁄4-mile conversion. Three quarter-miles reads better to me than three-quarters mile. –Fredddie™ 15:07, 20 December 2014 (UTC)

I'm not sure there is going to be one method of spelling fractions that works for all cases. I don't recall the details now, but when I was making spell work I found examples where the output would need a lot of tweaking to suit common usage, and that common usage probably depends on the style of the reader (particularly UK/US), and sometimes depends on context. Before I think about this, would you please edit the following table to spell out how you propose the output should appear. Johnuniq (talk) 06:42, 21 December 2014 (UTC)
I'm not so sure about one-fourth mile. In my part of the US, we say quarter and not fourth. –Fredddie™ 12:48, 21 December 2014 (UTC)
Would a new unit be a better option? I added them to the table below. I don't have any ideas for a better unit notation, though.
Convert Output Proposed output
{{convert|1/4|mi|m|spell=in}} one-quarter mile (400 m) one-quarter mile (400 m)
{{convert|1/4|mi|m|spell=in|sp=us}} one-fourth mile (400 m) one-fourth mile (400 m)
{{convert|3/4|mi|spell=in}} three-quarters mile (1.2 km) three-quarters mile (1.2 km)
{{convert|3/4|mi|spell=in|sp=us}} three-fourths mile (1.2 km) three-fourths mile (1.2 km)
{{convert|1/2|mi|m|spell=in}} one-half mile (800 m) one-half mile (800 m)
{{convert|1|1/4|mi|m|spell=in}} (syntax not currently supported) one quarter-mile (400 m)
{{convert|3|1/4|mi|spell=in}} (syntax not currently supported) three quarter-miles (1.2 km)
{{convert|1|1/2|mi|m|spell=in}} (syntax not currently supported) one half-mile (800 m)
{{convert|1|d4mi|m|spell=in}} (syntax not currently supported) one quarter-mile (400 m)
–Fredddie™ 23:59, 21 December 2014 (UTC)

Continuing the discussion from above the table. Convert outputs "one-quarter mile" and originally you were thinking that should be changed to "one quarter-mile". Now the suggestion is that a new option or unit might be introduced so the normal output would be unchanged, but when the new option is used, the result would be "one quarter-mile". A feature of using convert is that it produces standard output, as agreed by WP:MOS and WP:MOSNUM. For historical reasons, convert has some options which produce non-standard output, and this talk page has a couple of sections where people are arguing the non-standard options should be removed. The problem with regard to this proposal is that MOSNUM includes "Spelled-out fractions are hyphenated: seven-eighths." Ultimately this proposal needs to be sorted out at MOSNUM, and then we should consider how convert could comply with a change. If desperate, it is always possible to fake it:

  • The bridge is one quarter-mile ({{convert|1/4|mi|m|disp=out}}) long. → The bridge is one quarter-mile (400 m) long.

We need other opinions and examples of the text in articles with spelled-out fractions (examples of "three-quarters mile" are in Capture of Wadi el Hesi and Iowa Highway 38 and Iowa Highway 98 and Mount Haystack and U.S. Route 6 in Iowa). Johnuniq (talk) 04:29, 22 December 2014 (UTC)

A similar thing was discussed earlier. I would agree that "a half-mile", "a quarter-mile" and "three quarter-miles" are better but how about "a third-mile", "two third-miles", "a fifth-mile", "two fifth-miles", etc. or how about different units: "a half-foot", "a half-kilometre", "a half-horsepower", "a half-calorie", etc.? I'm suggesting an alternative approach to making these fit into normal English usage: put the article ("a"/"an") after the fraction. This way we'd have "half a mile", "a quarter of a foot", "three-quarters of a kilowatt", "two-fifths of a hectare", etc. This I propose should at least be the default and if there really is a need to talk in half-this and quarter-that, add a parameter for it. Jimp 14:36, 23 December 2014 (UTC)
If it's not cut and dried English (and |sp=us can not solve it), then a MOS decision is required. -DePiep (talk) 21:35, 23 December 2014 (UTC)
Really now? wrong conversions corrected. Peter Horn User talk 02:07, 30 December 2014 (UTC)
Tweaked. Peter Horn User talk 03:43, 30 December 2014 (UTC)
Thanks but the table was trying to show a proposed syntax. I removed the calls to convert which were showing a misleading error message (misleading, because we know the syntax is not currently supported). Johnuniq (talk) 04:30, 30 December 2014 (UTC)
And what's there isn't even the syntax I originally used ({{convert|1|1/4mi|m|spell=in}}). I'm just thinking out loud, but would something like how e6 can be added to a unit for scientific notation be workable? Maybe "d4" (for denominator=4)? –Fredddie™ 04:48, 30 December 2014 (UTC)
Sorry, that was my fault. I was trying to correct what I thought was a mistake. Jimp 07:11, 30 December 2014 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Convert/Archive_December_2014&oldid=644336412"