Jump to content

Template talk:Convert/Archive October 2014

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


Practical roundoff with feet and inches for sensible sentence structure

How does one get 0.9m expressed as 3 feet proper using some kind of rounding or tolerance control? To actually specify that the target units should be feet seems a step too far -- hardly any different from writing the figures verbatim, and one might still want inches for 1.0 metre (3 ft 3 in) but prefer a 5% tolerance where it can make the sentence flow better.

{{convert|0.9|m}} gives 0.9 metres (2 ft 11 in) at time of writing (now: 0.9 metres (2 ft 11 in)). The S-mine page is peppered with 11in roundoff glitches for figures I suspect were at some point imperial and loosely converted back to metric. --sh1 (talk) 19:57, 30 September 2014 (UTC)

The m unit is a bit odd: its default output is normally ft (feet), but is ftin (feet and inches) if the m value is between 0 and 3. The rounding can be controlled as in these examples:
  • {{convert|0.9|m|ft}} → 0.9 metres (3.0 ft)
  • {{convert|0.9|m|ft|0}} → 0.9 metres (3 ft)
  • {{convert|0.9|m|ft|3}} → 0.9 metres (2.953 ft)
  • {{convert|1.0|m|ftin}} → 1.0 metre (3 ft 3 in)
  • {{convert|1.0|m|ftin|2}} → 1.0 metre (3 ft 3.37 in)
  • {{convert|1.0|m|ftin|frac=2}} → 1.0 metre (3 ft 3+1⁄2 in)
It's true that convert does not add much value in this case, but people like to use it because it outputs the proper non-breaking space before the output unit symbol (but a standard space before a unit name). If there is a problem I've missed, please be more specific. Johnuniq (talk) 22:56, 30 September 2014 (UTC)
Well, maybe if we start by removing the 0 in from this to improve readability:
  • {{convert|0.3048|m}} → 0.3048 metres (1 ft 0 in)
After that, the problem is where you generally want feet and inches for most figures, but find that 2 ft 11 in is an unnecessarily verbose way of approximating 90cm (or, conversely, that 91cm is an unnecessarily verbose way of approximating 3 ft). One way of addressing this would be to dynamically suppress precision (for brevity) as far as possible while fitting within a tolerable error margin -- eg.:
  • {{convert|0.9|m}} → 0.9 metres (2 ft 11 in)
  • {{convert|1.0|m}} → 1.0 metre (3 ft 3 in)
  • {{convert|0.9|m|tol=5%}} → 0.9 metres (3 ft)
  • {{convert|1.0|m|tol=5%}} → 1.0 metre (3 ft 3 in)
So include inches only if they're necessary to express the value to within 5% of actual. This might logically extend to rounding the number to only a couple of significant figures. The goal here is to improve readability by removing unnecessary detail (most particularly when it's an historical rounding aberration), so it's all fairly subjective.
Another approach might be to tweak the original unit (0.91 metres) but to round that version for display as well. --sh1 (talk) 06:58, 1 October 2014 (UTC)
I don't think anything needs to be fixed—just use the wanted output unit, and if you don't like the default precision, specify one:
  • {{convert|0.3048|m}} → 0.3048 metres (1 ft 0 in)
  • {{convert|0.3048|m|ftin}} → 0.3048 metres (1 ft 0 in)
  • {{convert|0.3048|m|ft}} → 0.3048 metres (1.000 ft)
  • {{convert|0.3048|m|ft|6}} → 0.3048 metres (1.000000 ft)
  • {{convert|0.305|m|ftin}} → 0.305 metres (1 ft 0 in)
  • {{convert|0.305|m|ftin|frac=64}} → 0.305 metres (1 ft 1⁄64 in)
In the above, the first and second have identical results because ftin is the default for 0.3048 m. It would be misleading to omit "0 in" because that indicates the precision of the measurement (it's to the nearest inch rather than the nearest foot). Johnuniq (talk) 09:00, 1 October 2014 (UTC)

Conversion of board foot and cord (unit)

For Petrograd Standard: {{convert|1000|BF|m3|abbr=on|lk=on}} 1,000 BF[convert: unknown unit] {{convert|1000|bf|m3|abbr=on|lk=on}} 1,000 bf[convert: unknown unit] {{convert|1000|fbm|m3|abbr=on|lk=on}} 1,000 fbm[convert: unknown unit] Ditto for cord (unit) Peter Horn User talk 13:08, 24 September 2014 (UTC)

It would be handy if the text "A complete list is at the full list of units" were more prominent on the documentation page, although it is hard to see how that could be done in a reasonable way. Anyway, search Template:Convert for "full list", click the link, then search for "board" and "cord". Johnuniq (talk) 02:42, 25 September 2014 (UTC)
Yes. By the way, for current {{Convert/doc}}, I stole everytihng usable from Help:Convert. So far about unit lists -DePiep (talk) 22:39, 26 September 2014 (UTC)
I haven't been paying attention because I need a longish break from convert tedium, but it sounds like convert/doc and help:convert now have a lot of duplicated material. Ugh! You created help:convert and I was skeptical at first, but then got enthusiastic because there is sufficient material to justify making help pages, and help pages are more suited for displaying a lot of stuff than a doc subpage IMHO. I think convert/doc should have a very brief statement of the facts with examples of the more commonly used options, and perhaps the units list, and a link to help:convert. Whatever happens, there must not be a significant duplication of documentation because that confuses everyone, and will lead to inconsistencies. Johnuniq (talk) 00:13, 27 September 2014 (UTC)
I am surprised to remember that I created the Help page :-) . It was in the building days a year ago, to illustrate the documentation setup was done for {{cite ref}} templates. Then it was you who filled it with full module materiel; the /doc kept old stuff during the transition process. The Help page had the more complete & current situation. So far so good. Recently I started bringing the template:Convert/doc page into current Module description (getting rid of old wikicode references). It has a slightly different approach (namely, aimed at the editor who wants to use the template).
I have the opinion the /doc page should be a concise overview, not complete into every detail. For units presented there, there should be a short list (top-50 or so), and a folded longer list or even complete list (searchable, sortable). IMO the unit lists can be improved into this.
Of course there can be an overlap in the two pages. The pages have a different approach. The Help-page can be more complete (e.g., as it is about line wrapping), maybe with MOS links and other backgrounds. Help is about conversion, /doc about the conversion template. -DePiep (talk) 10:35, 27 September 2014 (UTC)
Let me put it this way.
The Template:Convert/doc page shall be the first port of call for any {{convert}}-using editor. It shows, up to the max of convenience, the top units and top parameters+options. For details, there is the link option (expect a Help-page).
The Help:Convert page shall be more complete, describing: MOS, glossary (precision, rounding, sigfig), defaults, extremes (hands), full unit list, unit-type understanding (dimension), wording issues (plural vs singular, grammar, spelling), and all subtleties discovered (by Johnuniq mostly, and in this talkpage's archives) in the process, deprecated parameters, ...
-DePiep (talk) 19:54, 27 September 2014 (UTC)
Yes, that sounds great. Since I have a list of all converts in articles, I could work out which are the commonly used units, and perhaps even the commonly used combinations of options—then we could make sure convert/doc covers those points. I'll ponder that. Johnuniq (talk) 01:50, 28 September 2014 (UTC)
As for lists of units we need, I have this live example. For {{Track gauge}} (which does conversions in a way), I made module:Track gauge/autodocument that reads the core module:Track gauge/data page to produce overviews like Template:Track gauge/doc/input options. For convert/data, it could have options like "use a top-50 unit list", or "type=area only". Smartly, it should not be in the main module, to prevent 650k transclusions. (And this is to cheer us up: [1]) -DePiep (talk) 18:36, 29 September 2014 (UTC)
So no resolution yet? Peter Horn User talk 22:52, 5 October 2014 (UTC)
If you tried what I said at 02:42, 25 September 2014 above and there is still a problem, please explain what it is. Johnuniq (talk) 23:31, 5 October 2014 (UTC)
Will try. Peter Horn User talk 20:06, 6 October 2014 (UTC)
Eureka! {{convert|1000|bdft|m3|sigfig=4|abbr=on|lk=on}} 1,000 bd ft (2.360 m3), giving it to the nearest litre or dm3. Thanks for the directions. Peter Horn User talk 20:44, 6 October 2014 (UTC)

Rate of progress per day.

For Track gauge conversion#Conversion rate: {{convert|20|km/day|mpd|abbr=on}} 20 km/d ([convert: unknown unit]) instead of 20 km/day. In the mean time I used {{convert|20|km|mi|abbr=on|disp=or}}/day 20 km or 12 mi/day. Peter Horn User talk 23:03, 5 October 2014 (UTC)

  • In general, use {convert/f} or {convert/per} for denominator conversions: There have been so many combinations of units, and hence inserting the literal "/day" with Template:Convert/f is the easiest general solution. Also, for conversions in the denominator, then the Template:Convert/per is the general solution to the thousands of various possibilities. Examples:
  • {convert/f |20|km|mi|x2=/day|x5=/day}} - 20 kilometres/day (12 mi*/day)
  • {convert/f |140|km|mi|x2=/week|x5=/wk}} - 140 kilometres/week (87 mi*/wk)
  • {convert/per|4|stops|km|mi}} - 4 stops per kilometre (6.4 stops/mi)
  • {convert/per|1|dog|km2|sqmi|out=dogs}} - 1 dog per square kilometre (2.6 dogs/sq mi)
There is no feasible alternative to all the myriad combinations. -Wikid77 (talk) 16:26, 6 October 2014 (UTC)
or use {{convert|20|km/d|mi/d|abbr=on}} Frietjes (talk) 17:37, 6 October 2014 (UTC)
  • Well, km/d works, but beware problems such as "USgal/d" whereas Template:Convert/f can show USgal to litres in the same manner as km to mi. Compare:
  • {convert|20|km/d|mi/d|abbr=on}} - 20 km/d (12 mi/d)
  • {convert|33|USgal/d|abbr=on}} - 33 US gal/d (1.4×10−6 m3/s)
  • {convert/f |33|USgal|L|x2=/day|x5=/day}} - 33 US gallons/day (120 L*/day)
Convert has been showing 33 USgal/day as "1.4×10−6 m3/s". In general, {convert/f} allows more flexibility for other units per day. -Wikid77 (talk) 16:13, 13 October 2014 (UTC)

Odd balls

For Indian locomotive class WAG-9#Technical specifications:
{{convert|1.6|mg/m3|abbr=on}} 1.6 mg/m3 (0.00070 gr/cu ft)
or perhaps {{convert|1.6|mg/m3|lb/cuyd|abbr=on}} 1.6 mg/m3 (2.7×10−6 lb/cu yd)
But {{convert|0.0016|mg/L|abbr=on}} 0.0016 mg/L (5.8×10−11 lb/cu in) works.
{{convert|4|kg/t|abbr=on}} 4 kilograms per tonne ([convert: unknown unit])
{{convert|6|kg/t|abbr-on}} 6 kilograms per tonne ([convert: unknown unit])
{{convert|20|kN/s|abbr-on}} 20 kilonewtons per second ([convert: unknown unit])

Peter Horn User talk 02:13, 19 September 2014 (UTC)

Recent edits to Indian locomotive class WAG-9 show that the following technical specifications were changed from the no-convert text shown to use converts which do not work because the units are not defined:
  • Dust concentration in terrain
    1.6 mg/cubic meter
    {{convert|1.6|mg/m3|abbr=on}}
  • Starting resistance of BOXN wagons excluding locomotive on level track
    4 kg/ton
    {{convert|4|kg/t|abbr=on}}
  • Starting resistance of locomotive on level track
    6 kg/ton
    {{convert|6|kg/t|abbr=on}}
  • Rate of change of tractive effort
    20 kN/sec
    {{convert|20|kN/s|abbr=on}}
  • Rate of change of braking effort
    100 kN/sec
    {{convert|100|kN/s|abbr=on}}
Something could be done about the first because it is a simple density, but the others are rather mysterious and would need planning. What would they be converted to? How many articles would use the units? Is there an article on the type of unit?
Regarding the first, the density units need thought. What is the unit normally used for dust concentration? What would it be converted to? Is density the right article for a link?
I'm a bit of a wet blanket on issues like this because I don't think it's worthwhile to use the convert template for everything, and would prefer to consider a range of articles that would use new units both to see that the effort would be worthwhile and that we plan for the big picture. Johnuniq (talk) 04:30, 19 September 2014 (UTC)
"The others" (4) may be the product of the imagination of Indian mechanical engineers and as such may be found only in articles about the electric and diesel electric Locomotives of India.

. Peter Horn User talk 14:07, 19 September 2014 (UTC)

A time consuming solution would be to go through the revision history of Indian locomotive class WAG-9 and find out which user/contributor added those units and then post a request on his/her talk page asking him/her for an explanation on this talk page. Peter Horn User talk 14:18, 19 September 2014 (UTC)
"The others" (4) appear to have been added at some point by User:Swapnilshelatkar User talk:Swapnilshelatkar Peter Horn User talk 15:40, 19 September 2014 (UTC)
Make that User talk:Swapnilshelatkar#Clarify. Peter Horn User talk 15:47, 19 September 2014 (UTC)
I'm thinking. There could be a covering {convert-compose} module that uses the {convert} units & calculations & facts, and then formats the outcomes as needed (allowing more juggling). -DePiep (talk) 18:49, 21 September 2014 (UTC)
So why do we not simply get rid of the other 4 which do not appear to make sense? 22:57, 5 October 2014 (UTC)Peter Horn User talk
Hello Peter Horn User talk,I received your notification. I agree with you that the BOXN wagons resistance needs to be removed but others are quite relevant to the engine. They describe the performance of the engine. If you mention these in the Locomotives of India, the article is quite lengthy and there's no need to go in detail about WAG9 in that article.07:21, 14 October 2014 (UTC)Swapnilshelatkar (talk)
The whole idea is to be able to convert these units into ones that are more universally understood and accepted and be able to be documented/explained in an appropriate article/page. The name of the game is to inform and enlighten. Peter Horn User talk 14:39, 14 October 2014 (UTC)

Missing gaps

It seems that comma=gaps is failing to add gaps after the decimal point. Compare {{convert|12.3455467|in|comma=gaps}} to {{val|12.3455467|u=in}}. Jimp 06:12, 16 October 2014 (UTC)

Pluralisation override

MOS:DECIMAL says "Nouns following a number expressed as a decimal are plural" so wouldn't it make sense to ditch adj=1? Jimp 06:25, 16 October 2014 (UTC)

No comma

Whilst I'm at it, I'd like to mention abbr=comma, disp=nocomma and adj=nocomma. Here we have another feature which was forced to use inappropriate parameters (note how disp=nocomma is not opposite to but entirely different to disp=comma). The reason that there were three ways of getting no commas was in case users wanted to combine this with another function of one of these parameters. We don't have to do things like this with the new version. Let's introduce the more logical and consistent option of comma=off (c.f. comma=gaps, comma=5, comma=gaps5, etc.) and eliminate these misuses. Jimp 06:06, 16 October 2014 (UTC)

In the documentations, I did this one for being counter-intuitive: "abbr=comma is deprecated. Use adj=nocomma instead". Discussion about |adj=nocomma can continue. -DePiep (talk) 10:10, 16 October 2014 (UTC)

Template:Convert/numdisp

Template:Convert/numdisp (edit | talk | history | links | watch | logs)
Resolved
 – Template deprecated; old code continues at {{hands}}, outside of {convert}

-DePiep (talk) 11:25, 18 October 2014 (UTC)

it looks like this template is used in under 500 articles (about half are from the {{hands}} template). I suggest we move it to a more generic name, since it's not used by {{convert}}. another option would be to expose this sub-feature in the LUA module? Frietjes (talk) 14:53, 15 October 2014 (UTC)

IMO: First we should replace instances with {convert} where possible in content space (articles, maybe WP-ns).
Then, if all its features are covered by {convert} then it should be deprecated (and kept alive for archives, harmless). But remaining article transclusions indicate features that are not (yet) in {convert}'s module. These can either be left alone (with continued full support by the template) or turned into hardcoded text. In this case of potential article usage, documentation must be (brought) up to standard quality.
I don't think this we should rename/move. There are more similar templates #like {convert/text2} with uncovered features, albeit exotic or zero in usage. It is good for overview & recognition if their names fit a pattern. -DePiep (talk) 15:48, 15 October 2014 (UTC)
Complication. In horse, the template is used but indirectly: {{Hands}} calls this one (and maybe others in the article too). So {Hands} is relying on those subtemplates.Maybe it makes more sense to turn {hands} into a {convert}. Anyway, renaming a template in such a spaghetti calling requires some analysis first. -DePiep (talk) 15:59, 15 October 2014 (UTC)
Frietjes already wrote this, my bad - sorry. Adding: also used by {{convert/per}}, see rocket. -DePiep (talk) 16:10, 15 October 2014 (UTC)
yes, in theory, {{hands}} can be replaced by convert in about 95% of the cases. however, in practice, any changes to horse articles will be swiftly reverted. Frietjes (talk) 16:20, 15 October 2014 (UTC)
I see. Ouch. Still, I think renaming is not a good idea. [2] /numdisp is used all over the old wikicode convert scheme. My preference is to keep the name pattern (we'll notice the warning it has), and keep them in check from this page (reduce need & usage whenever possible). Should we create a "Category:convert/xxx subtemplates that are (potentially) used in mainspace"? I expect a dozen or two. -DePiep (talk)
Category:Subpages of template:convert that are potentially used in mainspace. - A more serious cat name suggestion. Is this the way to keep an eye on them? -DePiep (talk) 20:01, 15 October 2014 (UTC)
I'd been meaning to deal with that one but it slipped my mind. Yes, {{hands}} could be replaced by {{convert}} but if the attitude is that we should keep our hands off, it probably isn't worth pushing for. I think I recall noticing that there were only a very small number of articles which seem to be be using {{convert/numdisp}} without going through {{hands}} and that those could probably be standardised to use the normal {{convert}}. Here's what I'm suggesting. Move {{convert/numdisp}} to {{hands/numdisp}} (along with its subpages) leaving redirect and let {{hands}} call {{hands/numdisp}} instead of {{convert/numdisp}}. Then we be able to clearly see what is calling {{convert/numdisp}} via channels other to {{hands}} and decide whether {{convert/numdisp}} is worth even keeping. If it is and this I doubt, we could duplicate it. Then we could do a bit of tidying up (the full {{convert/numdisp}} as it is is a bit of an overkill for what's required by {{hands}} anyway). Jimp 00:25, 16 October 2014 (UTC)
Sounds good. This /numdisp is also in article-grade templates (i.e., with features not in {covert}): {{Convert/f}}, {{Convert/per}}, {{convert/flip2}} (series, see top section), and maybe more. Given that tranc numbers are low, the move & copycode plan can be done. -DePiep (talk) 01:30, 16 October 2014 (UTC)
;-) I'm glad you followed my advice even before I wrote it [3]. -DePiep (talk) 15:44, 16 October 2014 (UTC)

Content page has been moved to {{hands/numdisp}} (an active subtemplate in non-Lua wikicode serving {hands}), here remains {{convert/numdisp}} for old convert usage; a redirect. However, this one is not used at all, and so is deprecated. -DePiep (talk) 11:21, 18 October 2014 (UTC)

Old templates in quarantine

I have created this category, for old {convert/...} subpages that may appear in mainspace ('old' = in non-Lua code). That is, they have features that are not covered by Lua-{convert}. This is to keep an eye on these. It does not claim any intention with these templates (incorporate into module:convert, deprecate, TfD, don't touch, move outside {convert} space, ...).

These old templates should not enter the {convert} documentation - full stop. Their documentation is below standard anyway (missing, wrong, outdates, incomplete).

Recently old templates {{convert/spell}} and {{convert/numdisp}} were on this list, but these have been deprecated successfully. DePiep (talk) 11:57, 18 October 2014 (UTC)

Nomination for deletion of Template:Convertx

Template:Convertx has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Frietjes (talk) 17:56, 18 October 2014 (UTC)

Rounding the input

As I've mentioned a few times in the past, the structure of the old version made it difficult to add new parameters which meant that new functions were often added using (or abusing) the existing ones. This resulted in a whole bunch of counter-intuitive codings. Here are three of them: adj=ri1, adj=ri2 and adj=ri3. These had nothing at all to do with adjectives verses nouns but were for rounding the input. This is a useful option but doing it this way is less than ideal. Besides being counter-intuitive we limited to rounding to 1, 2 or 3 decimal places. Perhaps we could create a new parameter for rounding the input to allow any precision we choose then we could eliminate this particular set of odd balls. Jimp 05:51, 16 October 2014 (UTC)

I support getting the three mentioned replaced.
Currently, output can be rounded by |round=5, |round=25, |round=each (each is for ranges). Can we allow more integers rounding for output too, and with similar pattern (same for editor)?
New parameter name |roundin=? Add another parameter that rounds both in and out (which would be redundant but easifying; |roundall=)? signed, late: -DePiep (talk) 19:23, 18 October 2014 (UTC)

Spelling out numbers and units

Currently {{convert|10|mi|m|spell=on}} is giving us "ten miles (sixteen thousand m)". Besides just looking wrong MOSNUM says it is wrong: "Do not spell out numbers before unit symbols ..." spell=on should apply to the unit as well and give us "ten miles (sixteen thousand metres)". We shouldn't expect users to have to go to the trouble of adding the abbr=off just to get something sensible. Jimp 05:15, 16 October 2014 (UTC)

Looks like Template:Convert/words (edit | talk | history | links | watch | logs) is active in this area. -DePiep (talk) 23:15, 18 October 2014 (UTC)
{{Convert/words}} is another thing altogether but no less dodgy. It wants its own section. Jimp 02:43, 19 October 2014 (UTC)

Old templates cleanup

I have asked a botoperator here to produce this list: Template:Convert... pages used in mainspace. The numbers shown may be a bit outdated.

I suggest that if you have worked on a template, you add a note to this list. No Red tape needed.

Warning: The numbers seem to be incorrect. To be researched first, more will follow. Table is updated. -DePiep (talk) 22:38, 18 October 2014 (UTC)

The corrected table 15:32, 19 October 2014 (UTC):

Template Mainspace pages transcluding
{{Convert}} 658760
{{Convert/CwtQtrLb_to_kg}} 35
{{Convert/E}} 2
{{Convert/TonCwt_to_t}} 286
{{Convert/numdisp}} 1
{{Convert/per}} 1
{{Convert/words}} 12
{{ConvertAbbrev}} 40086
{{ConvertAbbrev/ISO_3166-1/alpha-2}} 40086
{{ConvertAbbrev/ISO_3166-1/alpha-3}} 629
{{ConvertAbbrev/ISO_3166-2/US}} 39457
{{ConvertAbbrev/ISO_639-1}} 629
{{ConvertAbbrev/ISO_639-2}} 1
{{ConvertIPA-hu}} 372
  • Cause 1: First pipe missing. Some redlinks in the lsit are cause by a forgotting first pipe (right after "{{convert". That way, instread of intended "{{Convert|3800|...}}" template "{{Convert 3800|...}}" is used (non existing of course). That made a red template link on the article page!: {{Convert 3800|...}}. See [4], [5], [6]. Funny, we'd never see these red errors. Those are edited by now. -DePiep (talk) 23:09, 18 October 2014 (UTC)
See section below. I propose same for Template:Convert/TonCwt to t (edit | talk | history | links | watch | logs) and Template:Convert/CwtQtrLb_to_kg (edit | talk | history | links | watch | logs).They need a swap with their redirect. (Or did I miss a talk outcome here?). -DePiep (talk) 09:36, 19 October 2014 (UTC)
  • {{Convert/TonCwt to t}} and {{Convert/CwtQtrLb_to_kg}} don't really belong here. I was thinking of merging them both into a new template separate from {{convert}}. Jimp 05:36, 22 October 2014 (UTC)
Indeed. This plan is mentioned discussed two sections below. -DePiep (talk) 09:30, 22 October 2014 (UTC)

Deprecated: disp=2, disp=u2

I have just deprecated these two options:

  • disp=2 is deprecated. Use disp=output only instead
  • disp=u2 is deprecated. Use disp=unit2 instead

An alternative is available, and their coding is not fit for memorizing. No need to load documentation with these clueless redundancies. -DePiep (talk) 00:01, 17 October 2014 (UTC)

I agree. disp=2 and disp=u2 may be short but they are unclear. What we really need now is someone with a bot which could go through and remove these deprecated codings from transclusions and once this is complete they sould be removed altogether. Jimp 05:27, 18 October 2014 (UTC)
Thanks for the support (btw, "their coding" is to say that they are code-words, not English words; nothing with lua code; e.g., we use "out" not "2").
As for the bot task, this would be an non-disruptive way: as param options, eight now are declared deprecated in documentation. I suggest we wait some weeks or months until that red list is fleshed out and complete, (via this talkpage or by sandbox). Better to have strong and stable statements about deprecation first. Then, a bot can do a single run (650k pages) for all these param changes. And then within day someone puts the prepared sandbox code into live (with option support removed). -DePiep (talk) 06:55, 18 October 2014 (UTC)

More deprecations

As a matter of interest, I once saw a statement that a reason for choosing options like "2" or even "u2", apart from brevity, is that if convert is copied to another Wikipedia, they don't like using English names for the options. That consideration no longer applies because the module can be customized to use whatever localized names are wanted, so deprecate away. I don't see why we would inflict disp=output only on users when disp=out does the job, and where "out" is similar to usage such as lk=out. If we do remove unwanted options, we'll have to think what to do with non-article pages. For example, would a bot "fix" a convert on an archive of this page? I'll catch up with other points on this page later. Johnuniq (talk) 09:16, 18 October 2014 (UTC)
I'd be happy to deprecate more of these, but these two were the easy, low hanging fruit. For me it also had the benefit of getting rid of specific Irish music associations (how low can fruit be?!).
For other deprecations like disp=output only, we'd have to take a look at the whole set of showing the result partially (units-in, number-in, measurement-in; ditto -out; all units only; all numbers only, ...). Their resulting (future) option names should be systematic to be editor-friendly. Extra confusion (and bugging me on how to document this well) is that order=flip mixes "input" with "left-hand output". -DePiep (talk) 10:29, 18 October 2014 (UTC)
Without examples: I have the impression that "out" is used both meaning 1. "output" as in full template-result, and 2. "outcome" of the core calculation. -DePiep (talk) 10:32, 18 October 2014 (UTC)
Johnuniq, I am thinking about proposing new parameter(s). Are there any reasons beforehand that would make even a proposal useless ("won't happen at all")? If so I don't need to spend time on it. Of course, after I've written a proposal a talk outcome can be that it is not a good idea, but at least shouldn't be doa. -DePiep (talk) 09:51, 22 October 2014 (UTC)
That's interesting, as that is the second time in recent days that I've seen what looks like a correct post for which I did not see a notification. In your next comment, please test: [[User:Johnuniq|Johnuniq]]

Some parameters are easy to implement, and some may require major refactoring. I'm still a bit burnt out, but am happy to look at anything. Perhaps if you would outline one proposal I would let you know what might be involved. The main problem you would face with me is that I favor simplicity—what people are used to is simple, even if, in retrospect, it would have been better done a different way. Johnuniq (talk) 10:12, 22 October 2014 (UTC)

OK, I'll write a broad outline before spending too much time. And I'll slow tha pace (last week a lot of posts/topics were added here).
Here is the ping (I learned that a ping only is sent if it is saved together withe a ~-signing):
pingtest 1: Hello Johnuniq -DePiep (talk) 21:38, 22 October 2014 (UTC)
Thanks, that ping worked (I was notified shortly after you posted, but haven't got around to responding until now). Your previous ping (diff) used {{U|Johnuniq}} and seemed to have a signature, and per WP:ECHO, {{U}} is supposed to ping, so I don't know what happened.

I suggest a quick outline just to give the flavor—I don't want to comment on how I'd feel about new options without some idea of the plan. Details can come later. Johnuniq (talk) 02:45, 24 October 2014 (UTC)

Using {convert/per} and singulars

Template:Convert/per (edit | talk | history | links | watch | logs)
  • The single use of {{convert/per}} was added recently. {{convert|1|PD/km2}} which gives "1 inhabitants per square kilometre (2.6 /sq mi)" was replaced by {{convert/per|1|person|km2|out=persons|abbr=on}} which gives "1 person/km2 (2.6 persons/sq mi)". Unfortunately, neither are really adequate: "inhabitants" should be singular, there should be no space before the slash and "person/km2" and "2.6 persons/sq mi" should be spelt out. Jimp 05:51, 22 October 2014 (UTC)
No one has noticed the plural problem before [update: the following now works]:
  • {{convert|1|PD/km2}} → 1 inhabitant per square kilometre (2.6/sq mi)
That needs fixes at the definitions: per unit area units. I can do that later (I have made a to do note) if no one beats me to it. Johnuniq (talk) 08:42, 22 October 2014 (UTC)

I updated Module:Convert/documentation/conversion data/doc and Module:Convert/data with the new units and with fixes to "inhabitants" as mentioned by Jimp above. Are you saying that there should be no space before the "/sq mi" in the above? It probably works like that for compatibility with the old template, but I haven't looked. Should it be changed? Johnuniq (talk) 09:45, 23 October 2014 (UTC)

The old version put the space in simply because it was too much trouble to get rid of but it doesn't belong there. Jimp 03:39, 24 October 2014 (UTC)

Old {convert/...} templates not covered (e.g. {convert/text2})

With modern {{convert}}, multi-dimensional conversions usually look like:

  • {{convert|12|x|10|x|5|in|mm}} → 12 by 10 by 5 inches (300 mm × 250 mm × 130 mm) Green tickY
  • {{convert|12|x|10|x|5|in|mm|adj=on}} → 12-by-10-by-5-inch (300 mm × 250 mm × 130 mm) Green tickY

Below is a list of multi-dimensional old {convert/...} template usages, that are not covered by the {convert} template (module:convert). So these are old wikicode templates, that today cannot be replaced by the module, functionally. In brackets is the number of articles using it today.

demo: Fort McHenry: A {{Convert/3|18|, |24|, and| 38|lb|kg|adj=on}} cannon
demo: ThinkPad X Series: {{convert/flip4|12|x|8.2|x|0.5|-|1.5|in|mm|abbr=on}}
demo: 1980 eruption of Mount St. Helens: {{convert/text2 |23|across by|19|mi|km|long}}

Notes

- Even when usage is zero, the functionality is not present in current {convert}.
- The current 28 articles in here, are the result of a manual cleanup by me (where possible, modern {convert} was used). The remainning situations are the real differences.
- There may be other wikicode {convert/...} subtemplates in the same situation. I did not check. {{convert/spell}} is deprecated.

What to do? Nothing! I do not propose any consequence. This is just an overview. My impression is that it is not feasible to incorporate these options into current {convert}. (If I needed such a text myself, I'd construct it in a sandbox and then hardcode it in the article). -DePiep (talk) 22:00, 10 September 2014 (UTC)

I agree: hard-coding is generally the best option when it comes to stuff like this. Most of the instances of these seem to have been in place just for the sake of it but a lot of the time the result was far less than ideal. I've just got rid of them. The only thing that might possibly be worth considering hanging on to could be some way of naming the dimensions: i.e. somehow to give something along the lines of "12 in long by 10 in wide by 5 in high (300 mm × 250 mm × 130 mm)".
P.S. As noted below, it would be better (I reckon) if the template went back to the old practice of following the MOS i.e. giving the unit each time when giving dimensions combined by a multiplication sign. Jimp 09:46, 22 September 2014 (UTC)
I'm the guy who put convert/flip4 into ThinkPad X Series, after coming here to ask how to do it. A little disappointed it's no longer possible but I guess I can live with that. Kendall-K1 (talk) 16:22, 22 September 2014 (UTC)
Sorry to disappoint. Jimp 22:13, 22 September 2014 (UTC)
You guys have always been very helpful, and the new convert is overall better than the old. I appreciate the work you do here, please keep it up. Kendall-K1 (talk) 11:06, 23 September 2014 (UTC)

I may not have been quite as bold as Jimp but I agree with the conclusion because I have seen some of the template invocations while wondering whether the module should attempt to support them. A very small number of cases seemed natural and useful, but too complicated to add to the module. Several other cases used a syntax that the vast majority of editors would never want to grasp. I can see the sense of "long by wide by high" in Jimp's example above, and a standard way of saying that may be worthwhile. Johnuniq (talk) 01:22, 23 September 2014 (UTC)

seems these have now been deleted (or rather deleted, then archived). Frietjes (talk) 00:15, 27 September 2014 (UTC)
Plastikpork reinstalled them at (e.g.): {{Convert/old/2}} (with no redirect from {{convert/2}}. I don't know yet their intention. -DePiep (talk) 00:23, 27 September 2014 (UTC)
  • I have restored the original pagenames, as those templates are not "old" but rather more-advanced than the Lua-based Convert. The intention of {convert/2} or {convert/4} is to allow ANY text between the converted amounts; note well how any text can be inserted between the multiple amounts. Compare and note the words "up to" between amounts:
  • {convert/2 |4|up to|5|ft|m}} - {{convert/2|4|up to|5|ft|m}}
  • {convert |4|up to|5|ft|m}} - 4 up to[convert: unknown unit]
  • {convert/4 |2|, |4|, |6|, or rarely|8|mi|km}} - {{convert/4|2|, |4|, |6|, or rarely|8|mi|km}}
  • {convert |2|, |4|, |6|, or rarely|8|mi|km}} - 2, 4, 6 , or rarely[convert: unknown unit]
Hence such templates, as {convert/2} or {convert/4}, add extra functionality beyond the current capabilities of the Lua-based Convert. -Wikid77 (talk) 17:19, 6 October 2014 (UTC)
They are 'old' wrt most standard usages (I was able to replace dozens of them with simple {convert}). Their documentation should be checked no to say that params & options are fully equal to those of {convert}. -DePiep (talk) 23:10, 6 October 2014 (UTC)
Wikid77: please do not revert turn hardcoded text into old {convert/xxx} templates. Hardcoding is OK, the templates are documented bad if at all, they are diverting from main {convert} documentation (params & options), and very unfriendly for the incidental editor. -DePiep (talk) 06:46, 8 October 2014 (UTC)
Please do not disrupt Wikipedia by edit-warring to remove conversion templates and re-hardcode the amounts, which has been shown to cause mismatches when hardcoded amounts are changed by hand. Hey, all conversions could be hardcoded, but templates exist to reduce the manual conversion errors, which have been documented in numerous cases for years. Also, you can claim those templates are "old" but they post-date the Lua Convert, as new templates or newer options than provided by the Lua version, such as avoiding nonsense ranges:
     • {convert |105|-|106|F|C }} - 105–106 °F (41–41 °C)
     • {convert/2|105|-|106|F|C}} - {{convert/2|105|-|106|F|C}}
I assure you the view as "very unfriendly" is in your own mind, or attitude, and several users have noted the full documentation for Convert has been overwhelming to incidental editors, compared to shorter, direct documentation for templates such as Template:Convert/2. -Wikid77 (talk) 15:51, 13 October 2014 (UTC)
{convert |105|-|106|F|C|sigfig=3}} → 105–106 °F (40.6–41.1 °C)
Solved once & for all. -DePiep (talk) 18:52, 13 October 2014 (UTC)
is in your own mind, or attitude, - don't be a dick. -DePiep (talk) 22:35, 13 October 2014 (UTC)
Of course you know those editors who came to you to say documentation for Convert has been overwhelming. That is because, until a few weeks ago, it was the old documentation unchanged for the old {convert} template: mostly as it was left a year ago. Also, the compactness of that specific documentation you mention assumes knowledge of the general usage of {convert} and its main params. You won't fool me: no incidental editor can make anything out of a first encounter with say {{convert/2}} + /doc. -DePiep (talk) 22:52, 13 October 2014 (UTC)
-DePiep (talk) 12:15, 18 October 2014 (UTC)
  • About hardcoded conversion numbers (to allow more complicated grammatical constructions).
I have documented the subst:-solution for this (do {subst:convert} and then edit the plain code for grammar). see Convert/doc. Took the example from Fort McHenry:

The American defenders had 18-, 24- and 32-pounder (8, 11 and 15 kg) cannons.

  • In the process I discovered this edit that changed the input (38 pound to 32 pound) but left the conversion unchanged (17 kg). Lesson: subst: and any hasrdcoded conversion can go unchecked. -DePiep (talk) 13:43, 24 October 2014 (UTC)

E notation

{{Convert/E}} handles input using e-notation (it converts it into normal scientific notation). Could this function be added to the main template? Jimp 05:58, 26 October 2014 (UTC)

That's tricky. I explained in one of the archives that the module should be more modular, but it is extremely complex and doing everything "properly" would have made it quite a bit longer, more complex and slower. My main concern was to get it working efficiently while being very close to what the old templates did for compatibility. I can look at translating e notation into something properly formatted, and I agree it should be done. But, can we please make a wish list because I won't get around to serious work on some items (like this one) for quite a while. Johnuniq (talk) 07:02, 26 October 2014 (UTC)
Don't let yourself be hurried. These talkpage archives are patient. -DePiep (talk) 10:30, 26 October 2014 (UTC)
I understand where you're coming from. There's always been more work to be done on this template than was humanly possible and this is one of the less urgent issues. Jimp 12:11, 26 October 2014 (UTC)
Postpone this a year: code change for deprecated options. Once decided "deprecated", an option is marked such in the documentations (red text + the alternative). Any code consequences can be postponed years without any damage. -DePiep (talk) 19:25, 26 October 2014 (UTC)

Move Convert/TonCwt and Convert/CwtQtrLb_to_kg out of {convert} space

Resolved
 – Both have been moved out of {convert} sphere. See {{Long ton}}. -DePiep (talk) 19:44, 26 October 2014 (UTC)
Template:Convert/TonCwt to t (edit | talk | history | links | watch | logs) (286 transc's)
Template:Convert/CwtQtrLb_to_kg (edit | talk | history | links | watch | logs) (36 transc's)

I propose to move them to outside {convert}-space. I note that targets Template:TonCwt to t and Template:CwtQtrLb to kg now are their redirects, so this would need a swap.

These conversions have not been incorporated in module:convert. Whenever Lua-{convert} has these, they can be deprecated. Now, they are addressed directly from mainspace while being subtemplates, that is confusing. They are stand-alones. -DePiep (talk) 14:41, 19 October 2014 (UTC)

yes, good idea. Frietjes (talk) 17:15, 19 October 2014 (UTC)
To research this kind of issues, I've added the Search Archives box in the top of this page. For example, I discovered that in Cwt the two sub-talkpages contain discussions too. -DePiep (talk) 08:23, 20 October 2014 (UTC)
I've moved them out merging them both to {{long ton}}. Jimp 08:02, 24 October 2014 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:Convert/Archive_October_2014&oldid=1139590547"