Wikipedia:A plan to reduce Convert subtemplates Information & Wikipedia:A plan to reduce Convert subtemplates Links at HealthHaven.com

This essay contains the advice or opinions of one or more Wikipedia contributors. Essays may represent widespread norms or minority viewpoints. Consider these views with discretion.

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 hundreds more subtemplates, it is clear that the current design has become unmanageable: there are over 3,060 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 300 subtemplates needed for each separator between amounts).

1 Hybrid design to still allow new unit-conversions
2 Completing current Convert to allow old-versus-new testing
3 Prototyping with extended Convertx subsystem
4 Advantages of new Convert
5 Disadvantages of new Convert
6 The new design
7 Why 4,000 subtemplates have been needed
8 Why the subtemplates are so confusing
9 Listing Convert subtemplates
10 See also

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

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-700 new display-subtemplates (for each option added; see below "#Why 4,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 700 subtemplates.

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

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.

[edit] Prototyping with extended Convertx subsystem

Because the original subtemplates number over 3,060, 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 13 or more smaller steps, by reducing each related group, of 250 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:

{{Convertx/LxAxDxSx}} - handles the regular style, such as ft-to-m.
{{Convertx/LxAxDxSx2}} - handles 2-unit style, such as feet-&-inches to cm.
{{Convertx/Dual/LxAxDxSx}} - handles dual ranges, such as 2-to-9 feet.

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 250 (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, 13 different sub-tasks for condensing the various unit-groups, such as multi2 with {{Convert/mpgus}}.

Those are the initial results of the current development.

[edit] Advantages of new Convert

There are many reasons to favor a simpler Convert:

ease of fixing features - when each option becomes 300x times simpler, then options could be fixed (or finished) much faster.
ease of adding features - when adding new options becomes 300x 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 300 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 300 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) could be handled within an hour, rather than creating 1,400 new subtemplates for abbreviations.

[edit] Disadvantages of new Convert

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 300x times easier, then there is the danger of too many, too soon.

Those are some of the concerns.

[edit] The new design

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 300 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.

[edit] New features

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 2500*24= 60,000 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.

[edit] Dynamic variations of display-subtemplates

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.

[edit] Example of a redesigned unit template

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 = feet <!--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.

[edit] Why 4,000 subtemplates have been needed

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, eventually exploded into over 2,300 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 12 values (regular, 2-unit, ranges, temperatures, USre (British), USer (American), imperial, multi2 (4-part), USre ranges, USer ranges, imperial 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 (12)
total subtemplates = 4 x 3 x 2 x 8 x 12
total subtemplates = 24 x 8 x 12 = 2,304

When more option values are added, then the total subtemplates increases quickly. For example, if the abbr=on option were expanded to simply allow abbreviating just the input-unit (abbr=in) or just the output-unit (abbr=out), then the current 3 values of abbr would increase to 5. However, the combined template-name parts would increase by over 1,500 new subtemplate names:

total subtemplates becomes = #lk (4) x #abbr (5) x #adj (2) x #disp (8) x #group (12)
total subtemplates becomes = 4 x (5) x 2 x 8 x 12
total subtemplates becomes = 40 x 8 x 12 = 3,840

Hence, the addition of 2 new values (for abbr) would increase the total by 3,840 - 2,304 = 1,536 more subtemplates.

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 current total of 8 to become 9 display-option values. The subtemplates would increase by nearly 300, for handling the new value (disp=semi):

total subtemplates with semicolon-separator = 4 x 3 x 2 x (9) x 12 = 2,592.

The new total, to allow a semicolon, would become 2,592 (rather than 2,304) and add 288 more subtemplates.

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

total subtemplates with abbr=in/out & semicolon = 4 x (5) x 2 x (9) x 12 = 4,320

That's the reason why 4,000 subtemplates have been needed, even though there are only about 3,060 Convert subtemplates (in November 2009).

[edit] Why the subtemplates are so confusing

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

To modify an option, a user must often modify up to 300 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. An editor must be highly fluent in Convert-speak to be able to modify the templates correctly.

The overall effect is much more complex than editing 3,060 articles about books and their authors. Instead of a book having one or more authors, those 3,060 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 maintained.

[edit] Listing Convert subtemplates

Most of the Convert subtemplates fall into the 12 major unit-groups, which depend on regular-unit, 2-unit (ft&inches), or dual-range conversions, with imperial-unit, US-unit, 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: