Template:Convert/old/doc/A plan to reduce Convert subtemplates

From Wikipedia, the free encyclopedia
Jump to: navigation, search
Discuss at Wikipedia_talk:A plan to reduce Convert subtemplates.

This essay, WP:A plan to reduce Convert subtemplates, describes a plan to modify the standard Template:Convert so that thousands of subtemplates can be avoided, and new options could be implemented by changing just a few subtemplates, rather than hundreds at a time. After analyzing Convert for 2 years, and addressing various user concerns, plus creating several hundred more subtemplates, it is clear that the current design has become unmanageable: there are over 3,400 Convert subtemplates, and many have become obsolete (see below: Listing Convert subtemplates).

The plan is to create a hybrid design, based on currently working prototype templates, as an extension within Convert (rather than a rival variation), because the reduction of subtemplates could span months rather than weeks, and a separate variation might diverge to become incompatible. Obsolete templates would be retired, until free from "What links here" and later deleted. This essay also explains how to calculate the number of old subtemplates needed to implement an option (such as 1,224 subtemplates needed for each separator between amounts).

Hybrid design to still allow new unit-conversions[edit]

The proposed design will use over 2,500 fewer display-subtemplates, but still allow new unit-name subtemplates to be added on-the-fly, such as {{Convert/ft}}, {{Convert/mpgus}} or {{Convert/kg/m3}}. We need to move to a simpler, hybrid Convert-subtemplate structure, so that adding a new option won't require 300-1200 new display-subtemplates (for each option added; see below "#Why 24,000 subtemplates have been needed"). Perhaps the prior explosion of subtemplates is a major reason why the current "missing thousand" subtemplates have never been finished. Some experienced users might have become demoralized, when realizing that a new option required creating another 1200 subtemplates.

Completing current Convert to allow old-versus-new testing[edit]

When proposing a new release, the system should be beta-tested against the older template, to ensure that the new logic generates similar results. Although more hundreds of missing templates could be added to the original Convert, only the most-likely should be created, as a baseline for comparisons, for a beta-test of a new {{Convertx}} (aka "Convert-2") with far fewer subtemplates. Unless the older template works for all major options, it would be more difficult to compare new-against-old to show the equivalent performance.

Prototyping with extended Convertx subsystem[edit]

Because the original subtemplates number over 3,400, and any improvements are a volunteer effort, the full task of condensing Convert might seem utterly overwhelming. However, the total task can be divided into tangible milestones, defined as sub-tasks to develop new condensed subtemplates, each as a proof-of-concept. Rather than attempt to "re-write Convert" in a few weeks, the task can be approached, in 16 or more smaller steps, by reducing each related group, of 290 subtemplates, in each step. These milestones are being coded as an extended subsystem, under top-level Template:Convertx. Already, there are 3 working prototypes for the condensed subtemplates:

To allow side-by-side comparison, the new design is coded as a subsystem of new condensed subtemplates, without changing the live Convert subtemplates. Each of those (condensed) subtemplates can then be tested, as a proof-of-concept, and compared against the live Convert to show equivalent results, using each single condensed subtemplate versus the old 290 (or more) related subtemplates.

Already, the prototyping has revealed a migration path for implementing the overall, hybrid design:

  • Each conversion-unit (ft, m, km, kg,...) can choose between using the old or the new condensed subtemplates.
  • Other unit-groups, such as imperial-unit or US-unit groups, will be unaffected while the first groups are changed.
  • Because some unit-groups have more complex conversions, there might be several condensed subtemplates for some unit-groups.
  • Expect, at least, 16 different sub-tasks for condensing the various unit-groups, such as multi2 with {{Convert/mpgus}}.

Those are the initial results of the current development.

Advantages of new Convert[edit]

There are many reasons to favor a simpler Convert:

  • ease of fixing features - when each option becomes 900x times simpler, then options could be fixed (or finished) much faster.
  • ease of adding features - when adding new options becomes 900x times easier, then options could be added more quickly.
  • ease of sandbox testing - with 2,500 fewer subtemplates, it will be easier to develop sandbox-versions of the subtemplates.
  • ease of understanding - it will be easier to explain subtemplates that contain several if-expressions (if-statements) rather than comprehend why 1224 subtemplates insert one separator (such as "or").
  • ease of analysis - it will be easier to diagnose a few subtemplates with if-expressions rather than analyze the workings inside 1224 subtemplates at a time.
  • current user-requests could be added within a few hours: it will be simple to add a new separator (such as the user-requested semicolon), plus adding abbr=in & abbr=out (to abbreviate only the input-units or output-units) can be handled within an hour, rather than creating 2,040 new subtemplates for a new abbreviation option.

Disadvantages of new Convert[edit]

There are some reasons why having a condensed, hybrid Convert could cause problems:

  • longer parameter list - most conversion modules will have a longer list of parameters, such as {{Convert/ft}} passing 10 more parameters.
  • higher probability of re-changing the top Convert - every time the top-level template is changed, then all articles using Convert must be reformatted.
  • ease of "creeping featurism" - when adding new options becomes 900x times easier, then there is the danger of too many, too soon.

However, currently, people have been quite insistent on getting new options, so new options have been partially implemented to help users expand live articles. The prior complexity of Convert did not thwart feature creep. Those are some of the concerns.

The new design[edit]

The Convert template can be changed into a hybrid design, combining the advantages of both old and new methods: some options can continue to be handled by using template-name parts, but others will be passed as live parameters into each subtemplate. Specifically, there will be 2 major methods:

  • unit-names as template-names - the current practice of naming templates with unit-suffixes will be retained, such as {{Convert/kg}}, {{Convert/lb}}, or {{Convert/km/h}}.
  • options as passed parameters - the display-options will become template parameters, such as abbr=xx, lk=xx, adj=xx will become {{{abbr}}}, {{{lk}}} and {{{adj}}}.

To avoid having 360 subtemplates to handle one option (such as inserting a separator "or" in the results), template Convert needs to pass parameters (such as separator "or"), from the top-level down to each subtemplate.

Also, there will be optional parameters passed to avoid specialized subtemplates for multiple wikilinks per unit-name, such as "liters per 100 kilometers" (for more about the "multi2-units" see: "Template talk:Convert/L/100_km_mpgimp"). Formerly, the Convert multi2 subsystem, based on 4-part unit names, with hundreds of specialized subtemplates, had been created to display multiple-wikilinks, such as using Template:Convert/floutmig. To avoid creating such specialized subtemplates, some unit-templates would specify wikilinked names (using new parameters "nw" & "npw" or "nhw"), rather than just the current singular, plural & hyphenated names.

New features[edit]

11-Nov-2009: Within 2 weeks, it became obvious that many new features have been wanted in Template:Convert, so those features should also be considered when condensing the existing subtemplates. Some new options should be implemented while coding the condensed subtemplates, including:

  • comma=off, comma=in, comma=out, comma=on (default)
  • round=in, round=out (default), round=on
  • order=reverse, or order=flip (to handle new "disp=flip")

By acknowledging those new options, it becomes even clearer that a condensed design is needed: in the old style of subtemplate-naming, the new options might have become 24 new template-name parts. Those 3 options could become template-name suffixes (such as "CoffRinOflip" or "CoutRoutOoff") to append to "LoffAoffDbSoff" (etc.). If those options were added into all existing display-subtemplates, then the total might become 3,240*24= 77,760 possible subtemplates. However, in the condensed design, those 3 options would simply become 3 more parameters (named: comma, round, order) passed into all of the condensed display-subtemplates.

Dynamic variations of display-subtemplates[edit]

In the old style of subtemplate naming, an option value could be added to quickly connect to a variation subtemplate. For example, using abbr=xyz, a custom variation can be coded as subtemplates named "LoffAxyzDbSoff" (and "LoffAxyzDorSoff" etc.). In the new hybrid condensed design, there could be a similar option named "v=xxx" to allow a custom variation to be quickly coded as a subtemplate named "Convert/DgenVxxx" (or for v=xyz, then "Convert/DgenVxyz"). Meanwhile, the preferred method to customizing (any subtemplate operation) would be to use options c1=xxx, c2=yyy, c3=zzz, which would be passed into all new condensed subtemplates (without altering or creating new subtemplate names). Consequently, there would be those 2 methods of passing new options:

  • change a subtemplate to use various values of c1, c2, or c3;
  • create a new subtemplate named for v=xxx as "Convert/DgenVxxx".

By supporting both methods, the hybrid design can simplify the addition of many new features being added to Template:Convert.

Example of a redesigned unit template[edit]

Below is an example showing a "worst-case" scenario, to handle units where each is wikilinked to multiple articles. For most units, the wikilinks would be automatically generated; however, a simplified Convert can allow special wikilink parameters to avoid coding 350 subtemplates to handle special wikilinks, such as with "miles per US gallon". A new parameter "npw" (for name-plural-wikilink) could link "US gallon" as linked separately, from "miles per" linked instead to article "Miles per gallon". The parameter setting would be:

npw = [[Miles per gallon|miles per]] [[US gallon]]

Currently, a miles-per-gallon conversion, uses Template:Convert/mpgus, as follows:

{{convert/{{{d}}}F|{{{1}}}|{{{2|}}}|{{{3|}}}|{{{4|}}}|s={{{s|}}}|r={{{r}}}
|y=m{{{r}}}g{{{e|}}}
|o=L/100 km mpgimp
|b=(480000/1.12903)
|j=5.628535755-{{{j|0}}}}}

Formerly, the parameter "y" has been used to trigger several customized subtemplates to generate the wikilinked names for that unit. Instead, new parameters would set the various wikilinked names, for the unit symbol, and for the unit name, plural & hyphenated:

{{convert/{{{d}}}|{{{1}}}|{{{2|}}}|{{{3|}}}|{{{4|}}}|s={{{s|}}}|r={{{r}}}
| y=m{{{r}}}g{{{e|}}}
| u  = USmpg
| uw = [[US gallon|US]][[Miles per gallon|mpg]]
| n  = mile per US gallon
| nw = [[Miles per gallon|mile per]] [[US gallon]]
| np = miles per US gallon
| npw= [[Miles per gallon|miles per]] [[US gallon]]
| nh = mile-per-US-gallon
| nhw= [[Miles per gallon|mile-per]]-[[US gallon|US-gallon]]
| o = L/100 km mpgimp
| b = (480000/1.12903)
| j = 5.628535755-{{{j|0}}}}}

Within that single template, it becomes possible to proofread the various multi-article wikilinks, which would be displayed for a mpgus-conversion, rather than wading through many other subtemplates, and avoiding a separate subtemplate (currently 215) being created to set each wikilinked-name.

The above example is only a worst-case situation. For most conversions, the parameters would be fewer and simpler: each wikilink would not be specified, because they would be auto-generated instead. For a typical conversion of feet & metres, the parameters would be only

| u  = ft
| n  = foot
| np = feet <!--plural-->
| nh = foot <!--adjective form, hyphenated-->
| tx = Foot (length)<!--article-->

However, to handle complex wikilinks, there should be those optional parameters to avoid creating the many hundreds of customized subtemplates, as in the Convert-multi2 subsystem.

Why 24,000 subtemplates have been needed[edit]

Some users, unfamiliar with the subtemplate naming, might wonder why there have been thousands of subtemplates. The original Template:Convert avoided the use of repeated, long if-expressions (or if-statements) by transforming option values into template-name parts to access the next subtemplate to be invoked. Each of those subtemplate names has consisted of special name-parts for each possible option. For example:

  • The lk option became 4 name-parts: Loff, Lon, Lin, Lout, for lk=off, lk=on, lk=in, lk=out.
  • The abbr option became 3 parts: Aoff, Aon, Anone, for the values abbr=off, abbr=on, abbr=none.
  • The adj option became 2 name-parts: Soff, Son, for the values adj=off, adj=on.

Combining just those 3 various name-parts, there were 24 (4x3x2) possible name-string suffixes, in the form "LoffAoffSoff" or "LonAnoneSon" or "LoutAonSoff" (etc.); however, those became multiplied by many other options.

This combining of template-name parts, which seemed relatively few at first, back in 2007, later exploded by 2009, into over 3264 combinations, based on over 6 different options. The basic 6 options included:

  • lk     - link type with 4 values (lk=off, lk=on, lk=in, lk=out)
  • abbr - abbreviated unit symbols, 3 values (abbr=off, abbr=on, abbr=none)
  • adj   - adjective mode with 2 values (adj=off, adj=on)
  • disp - display type with 8 values (disp=b, disp=s, disp=slash, disp=/, disp=comma, disp=or, disp=output only, disp=output number only)
  • group - the unit groups, with 17 values (regular, 2-unit, non-abbreviated, regular ranges, non-abbreviated ranges, temperatures, temperature ranges, USre (British), USer (American), imperial, multi2 (4-part), USre ranges, USer ranges, imperial ranges, per-n, per-n ranges, Eng engineering-notation)

The total of subtemplate name-part variations can be calculated as the product of all possible option-values, combined:

  • total subtemplates = #lk (4) x #abbr (3) x #adj (2) x #disp (8) x #group (17)
  • total subtemplates = 4 x 3 x 2 x 8 x 17
  • total subtemplates = 24 x 8 x 17 = 3,264

When more option values are added, then the total subtemplates increases quickly. For example, when the abbr=on option was expanded to simply allow abbreviating just the input-unit (abbr=in) or just the output-unit (abbr=out), then the prior 3 values of abbr increased to 5, plus abbr=comma as 6. However, the combined template-name parts increased by over 3,200 new subtemplate names:

  • total subtemplates becomes = #lk (4) x #abbr (6) x #adj (2) x #disp (8) x #group (17)
  • total subtemplates becomes = 4 x (6) x 2 x 8 x 17
  • total subtemplates becomes = 48 x 8 x 17 = 6,528

Hence, the addition of 3 new values (for abbr) then increased the total by 6,528 - 3,264 = 3,264 more subtemplates (as doubled).

Also, during summer 2009, people suggested adding a new display option as disp=semi (rather than disp=comma) to show a semicolon between the results (such as "10 m; 1,000 cm"). A new display-option value would increase the prior total of 9 to become 10 display-option values. The subtemplates would increase by nearly 816, for handling the new value (disp=semi):

  • total subtemplates with semicolon-separator = 4 x 6 x 2 x (10) x 17 = 8,160

The new total, to allow a semicolon, would become 8,160 (rather than 6,528) and add 1,632 more subtemplates.

If both of those requested option changes were implemented (abbr=in, abbr=out, abbr=comma & disp=semi), then the total subtemplates would increase by over 4,000 more subtemplates:

total subtemplates with abbr=in/out/comma & semicolon = 4 x (6) x 2 x (10) x 17 = 8,160.

However, still more options have been requested, such as rounding the input, as well as the output, for 3 other options round=in, round=out, round=off, 3 x 8,160 = 24,480. That's the reason why 24,000 subtemplates have been needed, even though there are only about 3,400 Convert subtemplates (in February 2011).

Why the subtemplates are so confusing[edit]

There are 2 major reasons why having over 3,400 subtemplates is so confusing for Wikipedia users, when modifying Convert:

  • To modify an option, a user must often modify up to 800 subtemplates to complete the work.
  • Most subtemplates are not written as obvious conditional logic that would use ordinary if-expressions or switch branches; instead, most subtemplates are written as invoking other Convert-subtemplates which in turn, invoke still more, and more, and even over 21 more, so that almost all appear to be written in "Convert-speak" or "Convert-lish" rather than simple markup language using #ifeq. An editor must be highly fluent in Convert-speak to be able to modify the templates correctly. It is possible to mismatch using the Convert-speak template names, and still get results, but not correct results. It is analogous to bolting a steering wheel as a car wheel for a tire (they're both "wheels" but the steering wheel breaks under the weight of the car).

The overall effect is much more complex than editing 3,400 articles about books and their authors. Instead of a book having one or more authors, those 3,400 subtemplates are nested in groups of 23 or more at a time. It is not possible to fully understand how a conversion is calculated, without understanding all 23 (or more) subtemplates that lead to a converted result. Since many people, in a part-time, volunteer effort, would have trouble remembering the inter-workings of perhaps 7 nested templates, the mental gymnastics needed to track the 23-nest-level groups is probably beyond the capability of almost all editors. It is only by having multiple people, working together, that the entire system can be partially maintained.

Listing Convert subtemplates[edit]

Most of the Convert subtemplates fall into the 17 major unit-groups, which depend on regular-unit, 2-unit (ft&inches), non-abbreviated or dual-range conversions, with temperatures, imperial-unit, US-unit, per-n, per-n ranges, or engineering-unit groups. The special-page "PrefixIndex" can be used to list names with the same prefix (the list varies for upper/lowercase letters). Some of the major listings of subtemplates are:

Unit subtemplates:
Link-display subtemplates: (370-470 per group)
Range subtemplates:
Multi-result subtemplates:
USre unit subtemplates:
Imperial unit subtemplates:
The immperial display subtemplates are "Template:Convert/*Imp".

See also[edit]

[ This essay is a general plan to be expanded later. ]