Jump to content

Template talk:Convert/Archive June 2018

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


output "long ton" as just "ton"

I am rolling out convert templates across a list of heritage properties in Queensland, Australia. Being historic sites and within the British Commonwealth, the unit for something heavy in these articles is "ton", which within convert is known as "long ton" (LT). As Australia now uses the metric system, the unit today is "tonne" known within this template as "metric ton" (MT).

But unfortunately, {{convert|40|LT}} produces:

40 long tons (41 t)

which is a problem. No Australian will recognise the unit "long ton", as we just call it "ton". As with all Australian articles, we are supposed to use Australian English, so putting out a unit nobody will know is a problem. How can I instruct the convert template to emit "ton" rather than "long ton"? Perhaps ideally to emit "ton" so Australians will be able to understand it immediately and anyone else who doesn't can click the link and find out it's the "long ton". Thanks Kerry (talk) 08:23, 2 June 2018 (UTC)

No, the only long ton units in convert are LT and lt. They are the same except that LT uses the name (long ton) as the symbol and lt uses LT as the symbol. The MOS guideline requires "long ton" or "short ton" or "tonne" or "metric ton". All I can offer is sympathy—it is a mess but there is not much that can be done because there is a good reason for MOS being the way it is. One possibility is to not have a conversion because when it boils down, 40 tons gives the reader a feeling for the value regardless of the long/short/metric issue. Johnuniq (talk) 09:18, 2 June 2018 (UTC)
If it's an article with strong national ties to Australia, the correct conversion in this case would be 41 tonnes (40 long tons), or just {{convert|40|LT|disp=out}} → 41 t. Would that solve the problem? Kendall-K1 (talk) 12:27, 2 June 2018 (UTC)
Yes, the articles are I working with are the heritage properties of Queensland, Australia, so very much Australian content and therefore subject to {{Use Australian English}}. Because we have a lot of mining in Australia, the term "ton" gets used a lot in connecting with heritage-listed sites associated with mines, smelters, and other infrastructure concerned with ore-handling (e.g. railways, ports, etc), so I have a lot of "tons" in the articles. However, when I look at the MoS on the topic of units, it says

Quantities are typically expressed using an appropriate "primary unit", displayed first, followed, when appropriate, by a conversion in parentheses ... The choice of primary units depends on the circumstances, and should respect the principle of "strong national ties", where applicable

Surely in the presence of a conversion, the MoS expectation of the use of one of specific set of units is met if one of the units involved is from that list (in this case, the metric ton that is output) and not a requirement of all of the units involved. Surely, that is the point of adding a convert template, to both preserve the original unit and provides something that we can all understand. So long as the target of the conversion is "metric ton", have we not satsified the MoS? My ideal solution remains emitting [[long ton|ton]] from the convert template, as that seems to meet both the need to be readable to one audience and precisely interpretable by all, but I realise that that's perhaps too difficult to code. But I think enabling a unit in a convert template to be linked to its definition would seem analogous to the need to sometimes spell out the number or present the measurement as an adjective (a rendering instruction appropriate to the article context). Kerry (talk) 01:37, 3 June 2018 (UTC)

Re the other workarounds suggestion. It's true I could remove the convert templates but unfortunately there is a history of well-meaning people who come along and add convert templates using "short ton" into these articles (presumably people who are from other parts of the world) which is of course erroneous as it changes the meaning, so doing nothing isn't really solving the problem. The drawback of flip or disp as a solution is that the output of the conversion is presented as if it was the original value and that has its issues due to the precision. As a general principle with writing about history, you stick with historic units (as that's what the primary sources would have used) and provide a conversion to modern units; there are obvious risks in overzealous misinterpretation (as illustrated with the folks who add "short ton" conversions) if you lose the original amounts (as found in the primary sources). Kerry (talk) 01:37, 3 June 2018 (UTC)
The problem of leaving the article as just the plain 'ton' is that it is ambiguous. As you say, Australians (including myself) will naturally think of the metric ton, while others may not. Being ambiguous is almost as bad as being outright wrong because you are sometimes interpreted wrong and don't even know it. The majority of readers will probably be Australian but we do have to think of non-Australian readers too. This is similar to the way that Europeans often say hp (745.7 watts) when they really mean the very similar PS (735.5 watts) - related figures that are nearly identical but are a few % off. If you think that a reader will have trouble understanding what a long ton is then make sure the first occurrence is linked to its article. Curious and/or exacting readers will follow it and understand fully. Non-curious and non-exacting readers don't really care about the difference and will mentally substitute their own idea of ton (short or long) and at least be close enough to the right answer.  Stepho  talk  01:56, 3 June 2018 (UTC)
I don't think there is any need to preserve the original unit in the article text, and using disp=out is just fine. Preserving the original unit in this case is just going to confuse the reader. The only people in the world who know what a "long ton" is are those in the maritime industries; ordinary US citizens are not familiar with that unit. So preserving long tons in the article makes no sense. You do need to be careful about which "ton" your sources are talking about. Kendall-K1 (talk) 10:12, 3 June 2018 (UTC)
Is there an [Australian] abbreviation (symbol) for "[Australian] ton"? (would be horrible if that were "t"). - DePiep (talk) 11:58, 3 June 2018 (UTC)
We use "ton" for the imperial unit (aka long ton) and "tonne" for the metric ton. Kerry (talk) 23:00, 3 June 2018 (UTC)
It's not just Australian. Everywhere that uses non-metric units (officially or otherwise) uses the "long ton" and calls it a "ton" except for the US and Canada. When I was younger it was occasionally referred to as an "imperial ton" (as with the "imperial gallon") when necessary to differentiate it from the short ton, but clearly that would be unacceptable today. There is a similar issue with hundredweight. Other than on Wiki I've never seen a "long hundredweight" and it looks deuced odd when used for bell weights! Martin of Sheffield (talk) 13:34, 3 June 2018 (UTC)
But all of those other countries have gone metric. I claim there is no one who would benefit from having a conversion to long tons, so that conversion should be left out. Kendall-K1 (talk) 15:17, 3 June 2018 (UTC)
It's about having a conversion *from* Australian ton (aka long ton) to metric ton. The articles are about Australian heritage properties therefore their measurements (which principally come from primary Australian sources written in the pre-metric era) will use "ton" (as it was known). Kerry (talk) 23:00, 3 June 2018 (UTC)
Remember that you are writing for a global audience. An American reading "ton" will assume 2,000 lb and not 2,240 lb or even 1,000 kg. The clarification is essential. --Redrose64 🌹 (talk) 21:17, 3 June 2018 (UTC)
And any Australian reading "long ton" will think "WTF?" as it was a term never used here. This is why I am suggesting that the solution is [[long ton|ton]] emitted from the convert template if that is possible. Kerry (talk) 23:00, 3 June 2018 (UTC)
We cannot guarantee that every reader of the article will be Australian. So we must assume that some of them are not. --Redrose64 🌹 (talk) 06:56, 4 June 2018 (UTC)
I think maybe you misunderstand the problem. I am discussing the naming of the input unit so it is recognisable to Australians. The output unit can be metric tonne (for those using the metric system) and "short ton" (or whatever) for Americans will understand. Kerry (talk) 07:10, 4 June 2018 (UTC)
It doesn't matter which is input and which is output. The unqualified word "ton" is ambiguous. --Redrose64 🌹 (talk) 22:31, 4 June 2018 (UTC)
As Redrose64 says, the key point is that "ton" alone is ambiguous in an international context, which always applies to the English Wikipedia. I find it disturbing when editors write as though an article in some way "belongs" to a country. There are articles about Australian topics; there are no "Australian articles". Peter coxhead (talk) 13:21, 5 June 2018 (UTC)
– also, there is a difference between a country (ie the government) going metric and the acceptance by all the people. Martin of Sheffield (talk) 21:47, 3 June 2018 (UTC)
Yes, Australia uses metric today, but has not always done so. I started my schooling with pounds, shillings and pence, and imperial units, and finished it in metric, so there's plenty of Australians my age and older who are familiar with the imperial units. And metric is a "going forward" thing. We did not rewrite our history into metric. Kerry (talk) 23:00, 3 June 2018 (UTC)
The old measurements were very context sensitive. It's true that "short ton" was only used in North America (mainly by the railways) (the same applies to the short/long hundredweight - there was no need to disambiguate outside North America); but the long ton was used in the maritime industries. So when an American hears of tons of oil, they know that long tons are meant. I always take the position that either you understand the old measurements or you don't. Hawkeye7 (discuss) 22:43, 3 June 2018 (UTC)
I'd bet the average American, when reading/hearing "ton of anything", thinks "2000 pounds". A small percentage of the US population might know what a long ton is. Despite the inconvenience of showing someone a unit they are not familiar with, I would say it is better to write "short ton", "long ton", or "metric ton[ne]", linking the first use in each section, removing the ambiguity. The link will be there to educate those who care. —[AlanM1(talk)]— 07:59, 6 June 2018 (UTC)

Warnings for ignored numbered parameters

In {{convert|12|m|ft|abbr=off}}, 12 + m + ft are numbered parameters and abbr=off is a named parameter. Since July 2017, convert has given warnings for invalid named parameters. I am planning a new release soon and am thinking that convert should also warn when numbered parameters are ignored. The only problem is that around 3900 converts in articles will light up with a warning and the articles will appear in Category:Convert invalid options.

The following are examples of problems which currently show no problem but which would give a warning:

  • Dagebüll lighthouse: {{convert|10.30|m|0|ft}} (the precision 0 finishes the convert so ft is ignored)
  • Burnsall: {{convert|2|mi|km|0|straight line per MOS}} (similarly, the comment is ignored)
  • Monopotassium phosphate: {{convert|-150|C|F|K}} (probably "F K" was wanted)
  • Oakland, Maryland: {{convert|0.1|in|m|2sigfig|disp=or}} (probably "sigfig=2" was wanted)
  • Philips E105: {{convert|1.7|in|mm|adj-on}} (probably adj=on was wanted)

In the first case, convert would accept |m|ft|0 (input unit, output unit, precision). If |m|0 is found, convert regards it as input unit, nil output unit (use the default), precision. Convert stops looking at the numbered parameters at that point. The first example would display 10.30 metres (34 ft)* in a saved page (it would show a big error message on preview). Holding the mouse over the asterisk shows Convert: Ignored invalid option "ft". The word "option" is not quite right because I re-used an error message but it will do.

  • Should there be a warning for ignored numbered parameters?
  • Even if 3900 converts show the asterisk warning?
  • It can be hard finding *. Should convert show two asterisks instead, for example 10.30 metres (34 ft)**, possibly temporarily until the 3900 problems are handled?

Johnuniq (talk) 05:41, 11 June 2018 (UTC)

I would say "yes", but I'm familiar enough with the template to see what the problem is. You get a similar warning if there is an invalid param in an infobox template, and I find that helpful. You may be asking in the wrong place, as the editors who would find this annoying probably don't follow this talk page. Kendall-K1 (talk) 11:05, 11 June 2018 (UTC)
I'm not sure if it is possible, but could it work like this:
  1. The 3900 articles are categorised for maintenance (in a hidden category), and
  2. In preview, the warning (message) is shown, for a search to be found (for example, like Module:Preview warning).
  3. When saved, no message is shown inline.
Best would be to report as many of these errors & mistakes as possible, because they can signal an intention not fulfilled by the editor.
This would remove "maintenance tasks" from rendered articles (good; they are non-content by nature, and so distracting the Reader), and make them helpfully available for those who want to clean them up (like, people who read this talkpage, or who go to the category). I think we should actively empty that category, not letting the messages exist there for years. DePiep (talk) 16:36, 11 June 2018 (UTC)
That would be possible but the asterisk is essentially invisible. See permalink as an example of an article with three converts flagged with an asterisk. They are not really a problem, even if you knew they were in the "Format" section. Johnuniq (talk) 01:34, 12 June 2018 (UTC)
I think this is a perfectly reasonable idea. I see no problem with the single asterisk...if the preview warning isn't enough to get the editor's attention, then they're probably not interested in fixing their errors. These types of drive-by edits are all too common. One or two asterisks aren't an issue. Folks who want to clean out those error categories will do so regardless. The asterisk is just a nice marker to more easily find where the error is located. — Huntster (t @ c) 01:53, 12 June 2018 (UTC)
I agree that showing the errors is good, alerting the user that the output is potentially not what they expected. As far as the indicator, how about this# big and superscripted pound sign or this? question mark (i.e. <big><sup>?</sup></big> or whatever the more current version of <big> is)? If Unicode is acceptable, there are things like U+2600☀, U+2620☠, U+2622☢, U+26D4⛔, and, of course, U+2639☹. —[AlanM1(talk)]— 02:45, 12 June 2018 (UTC)

Thanks all, I interpret that as to stick with the current single asterisk. The Unicode symbols are nice but it is easier to search for an asterisk. Johnuniq (talk) 09:52, 13 June 2018 (UTC)

What a pity. I tried to explain that an asterisk or whatever in a rendered content article does not make sense re error fixing. And also it disturbs the Reader. Cleanups should go through hidden maintenance categories and bot listings and etc. On top of this, I say {{Convert}} should not add/expand another variant error handling setup without need. - DePiep (talk) 23:22, 13 June 2018 (UTC)
It's not a change—convert has shown an asterisk for warnings about bad syntax since July 2017. The change is that it will warn about invalid numbered parameters whereas now it only warns for bad named parameters such as {{convert|12|m|abbr=ox}} → 12 metres (39 ft)*. Only alert readers would notice the asterisk and they are fixed quickly, although it will take a couple of months to clear the 3900 problems that will be added in this change. Johnuniq (talk) 01:16, 14 June 2018 (UTC)

Module version 23

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

The following examples use fixed wikitext to show the current output from {{convert/sandbox}} so it will not change in the future.

  • Ignore abbr=~ when used with order=flip
    • Workaround quirk reported by Quondum here. The problem arose with the combination of options in: {{convert|1|km|abbr=~|order=flip}}. Convert correctly showed the left-hand side unit as "miles" due to the flip, but incorrectly showed the symbol "km". When this combination of options occurs, convert now ignores abbr=~. Example:
      • {{convert|1|km|abbr=~|order=flip}} → 0.62 miles (1 km)
  • Currency will use automatic per units
    • Fix error using $=x (where x is any currency symbol) in a convert that uses a mixture of a defined unit and an automatic per unit. For example, {{convert|4|$/acre|$/km2|$=£}} gave the error Cannot convert "cost $ per unit area" to "cost £ per unit area" because the unit $/acre was defined in convert, whereas $/km2 was not. The problem is that the option $=£ only applies to automatic per units ($/km2 in this example). The fix consists of removing all units using a currency symbol. That means converts using currency will use automatic per units, and never a mixture of auto-per and defined units. The result is that all conversions using currency will be done in a consistent manner. Discussion here.
    • In addition to $, the following currency symbols are recognized by convert: € • ₱ • £ • ₽ • ¥. That means $=x is not needed with these symbols. For example:
      • {{convert|4|¥/acre|¥/km2}} → ¥4 per acre (¥990/km2)
  • Composite input units acre/rood/sqperch
    • Add acre/rood and acre/sqperch as composite input units per discussion here. Examples:
      • {{convert|1|acre|12|rood|20|sqperch}} → 1 acre 12 roods 20 perches (1.67 ha)
      • {{convert|1|acre|12+1/2|rood}} → 1 acre 12 1⁄2 roods (1.67 ha)
      • {{convert|1|acre|500|sqperch}} → 1 acre 500 perches (1.67 ha)
  • Changes to adj=pre and disp=preunit
    • There are some minor changes to the behavior of adj=pre (user-specified text before input unit) and disp=preunit (user-specified text before input and output units). Discussion here:
      • If the user-specified text is "+" or " + " (zero or more spaces before or after "+"), the inserted text is "+ " (a plus sign with a space after but none before). That will result in outputs like "5+ feet" instead of "5+feet" or "5 + feet" as sometimes occur now.
      • If the user-specified text starts with an ampersand (&) it is used without modification. For example, "&deg;" would display a degree symbol with no preceding space, "&nbsp;..." would show text starting with a nonbreaking space, and "&#32;+" would display a plus sign with a space before but not after.
      • Otherwise a space is inserted before the text. For adj=pre, a space is also added after the text (same as occurs now).
      • {{convert|5|ft||adj=pre|+}} → 5+ feet (1.5 m)
      • {{convert|5|ft||disp=preunit|+}} → 5+ feet (1.5+ m)
      • {{convert|5|ft||disp=preunit|&#43;}} → 5+feet (1.5+m)   (not desirable but illustrates what occurs with a leading ampersand)
      • {{convert|1|/ft|/m|disp=preunit|&deg; of span |&deg; |abbr=off}} → 1° of span per foot (3.3° per metre)
      • {{convert|1|/ft|/m|disp=preunit|&deg;-of-span |&deg; |abbr=off}} → 1°-of-span per foot (3.3° per metre)
    • Four articles use adj=on with "+": 1 + 2 + 3 + 4. For example,
      {{convert|7320|ft|-1|adj=on|disp=preunit|+}} →
      7,320+-foot (2,230+m)   (old output)
      7,320+ -foot (2,230+ m)   (new output)
      Neither of the above results are desirable. Using the new convert, these results could be achieved:
      {{convert|7320|ft||adj=on|disp=preunit|&#43;}} → 7,320+-foot (2,230+m)   (same as old output)
      {{convert|7320|foot||disp=preunit|+}} → 7,320+ foot (2,230+ m)   (better)
  • Warnings for ignored numbered parameters
    • When convert ignores numbered parameters, a warning message will appear and the article will be listed in Category:Convert invalid options. This will affect around 3900 converts in articles. Discussion here.

Release notes for earlier versions are listed here. Johnuniq (talk) 10:04, 13 June 2018 (UTC)

Multiple inputs

I have a series of articles on Queensland heritage properties. Because they are historic, their dimensions are often provided in combinations of acres, roods, and perches (sqperch as it is known in the convert template). I have successfully converted these units individually but I am stumped on Killowen, Rockhampton which talks about

2 acre 32 perch

which does not convert correctly when I use

{{convert|2|acre|32|sqperch}}

yielding

2 acres 32 perches (0.89 ha)

which I think is because it is not listed here as a multiple input. Can it be made to work? The conversion is relatively straightforward 1 acre = 4 roods = 160 sqperch. I also need a multiple input for acre, rood, and sqperch since I have instances of these in Kurrowah. Is this possible? Thanks Kerry (talk) 23:25, 29 May 2018 (UTC)

In your example, the 32 is interpreted as the precision so convert gives junk.
The good news is that the following works:
  • {{convert|1|rood|4|sqperch|sqft|0}} → 1 rood 4 perches (11,979 sq ft)
It is easy to add combinations for acre/rood and acre/sqperch but that will require a new release of the module (it's more complicated than just adding a new unit). I'll look at doing that in the near future but it won't be for a week or two. I'll ping you when it's done. Johnuniq (talk) 03:13, 30 May 2018 (UTC)
This works too:
  • {{convert|1|rood|4|sqperch|sqft m2|0}} → 1 rood 4 perches (11,979 sq ft; 1,113 m2)
Note: in {{convert}} the unit is named sqperch because perch (unit) can also be used as a length unit (not area):
  • {{convert|4|perch|ft m|0}} → 4 perches (66 ft; 20 m)
BTW, Johnuniq, what is the best wording used for these "multiple unit units" (ft, in; rood, sqperch)? To check documentation for consistency & clarity (They do not appear in SI). - DePiep (talk) 08:27, 30 May 2018 (UTC)
- DePiep (talk) 08:27, 30 May 2018 (UTC)
In {{convert|1|rood|4|sqperch|sqft m2}} convert regards the rood/sqperch as a composite input unit, and the sqft m2 as a combination output. Johnuniq (talk) 09:52, 30 May 2018 (UTC)
A "composite unit" it is named then (ft, in). -DePiep (talk) 01:14, 31 May 2018 (UTC)
Thanks, folks! I'll await your ping! Kerry (talk) 04:52, 1 June 2018 (UTC)
@Kerry: The units are now available in convert. See my edits at Kurrowah as an example. Johnuniq (talk) 10:21, 15 June 2018 (UTC)
@Johnuniq: thanks for this. I am on holidays at the moment with just an iPad, so not able to roll it out for a few weeks but will get onto it once I am home again. Kerry (talk) 18:55, 15 June 2018 (UTC)

Typo:

"The rounding tales place after conversion" should be "The rounding takes place after conversion". Someone able to unlock the page will need to adjust. Icefield (talk) 15:42, 21 June 2018 (UTC) EDIT: Thanks to Johnuniq, I fixed the typo. Icefield (talk) 05:40, 22 June 2018 (UTC)

Request: Make "sing" on for values of less than 1

Would it be possible to change the template so that the output of (for example) {{convert|0.1|sqmi|km2|abbr=on}} is "0.1 square mile (0.26 km2)"? —DocWatson42 (talk) 02:51, 18 June 2018 (UTC)

Option adj=1 made the unit name singular when the value was 1 or less, but above 0. However, that option was deprecated and removed in January 2018. The wanted output is available, with hyphens, using:
  • {{convert|0.1|sqmi|km2|adj=on}} → 0.1-square-mile (0.26 km2)
Johnuniq (talk) 03:38, 18 June 2018 (UTC)
Darn. As it stands, IMHO that solution looks messy. —DocWatson42 (talk) 05:21, 21 June 2018 (UTC)
Note with OP DocWatson42: regular output for {{convert|0.1|sqmi|km2|abbr=on}} is 0.1 sq mi (0.26 km2). Am I missing something? Why would you expect the name written out when explicitly setting |abbr=on?
The plural/singular issue is visible in: {{convert|0.1|sqmi|km2}} is 0.1 square miles (0.26 km2). (or set |abbr=off). - DePiep (talk) 10:17, 21 June 2018 (UTC)
Removal discussion is at Feb 2018. The option was deprecated for a long time. btw, what is grammatically correct? - DePiep (talk) 10:26, 21 June 2018 (UTC)
I think some people are used to regarding 0.1 something as needing a singular something and I assumed that was the issue. Re grammar, "The option was deprecated for a long time" is good, if that is what you were asking. Johnuniq (talk) 10:46, 21 June 2018 (UTC)
I can't find any experts weighing in, but the usual blog pontificators seem to agree that anything with a decimal is plural, including both ".1 somethings" and "1.0 somethings" but "1 something". That's also what WP says, at English plurals#Decimals are always plural, without citing a source. Ask me about fractions next, that gets really complicated. Note we say "2⁄3 of the pizza was eaten" but "2⁄3 of the visitors were men". Kendall-K1 (talk) 15:01, 21 June 2018 (UTC)
looks reasonable. Of course, the deprecation & deletion of "sing" is based on literal plurals: 3 meters. Not 0-1 numbers this OP is about. DePiep (talk) 22:12, 21 June 2018 (UTC)
  1. 2⁄3 of the pizza was eaten – There was one pizza of which 2⁄3 was eaten and a large slice was left.
  2. 2⁄3 of the pizzas were eaten – There were 3n pizzas, 2n of which were eaten.
  3. 2⁄3 of the visitors were men – There were several visitors with 2 men for every woman.
  4. 2⁄3 of the visitor was man – What was the other third of this individual?
There is no complication, you are comparing chalk and cheese. Martin of Sheffield (talk) 21:07, 21 June 2018 (UTC)
correct and useless. Like a broken watch. DePiep (talk) 22:00, 21 June 2018 (UTC)
No, I found the post insightful as I had not thought about it like that. Johnuniq (talk) 00:44, 22 June 2018 (UTC)
How do these pizzas and visitors relate to {{Convert}} units? DePiep (talk) 02:37, 23 June 2018 (UTC)

Ranges question

If a range is given in the convert template is it by a dash – or a hyphen - eg 5–10 miles (8.0–16.1 km) or 5–10 miles (8.0–16.1 km) ? Thanks Keith-264 (talk) 08:41, 28 June 2018 (UTC)

I put some background in the reply at my talk. In brief, a hyphen is easier to type so it is the recommended way to get a dashed range in convert. The first of the following uses an en dash while the second uses a hyphen. The outputs are identical.
  • {{convert|1000|–|2000|ft|m|abbr=on}} → 1,000–2,000 ft (300–610 m)
  • {{convert|1000|-|2000|ft|m|abbr=on}} → 1,000–2,000 ft (300–610 m)
It is useful for editors to see the simple syntax supported by convert so they don't have to wonder how to type an unusual character. For the same reason, my preference is to omit ° for temperature conversions:
  • {{convert|100|C}} → 100 °C (212 °F)
Johnuniq (talk) 09:26, 28 June 2018 (UTC)

Adding sources

The values and conversion factors in the tables used by convert come from published national and international standards. I am going to add the sources to the documentation at Module:Convert/documentation/conversion data/doc along with some explanation. The four sources I currently have are:

  • Organisation Intergouvernementale de la Convention du Mètre (2014) [2006]. The International System of Units (SI) (PDF). Bureau International des Poids et Mesures. Retrieved 26 June 2018.
  • Thompson, Ambler; Taylor, Barry N. (November 2008). Guide for the Use of the International System of Units (SI) - Publication 811, 2008 Edition, 2nd printing (PDF). National Institute of Standards and Technology, U.S. Department of Comerce. Retrieved 26 June 2018.
  • "CODATA 2010 Table at NIST" (PDF). From Mohr, Peter J.; Taylor, Barry N.; Newell, David B. (2012). "CODATA recommended values of the fundamental physical constants: 2010". Reviews of Modern Physics. 84 (4): 1527–1605. doi:10.1103/RevModPhys.84.1527.
  • "CODATA 2014 Table at NIST". From Mohr, Peter J.; Newell, David B.; Taylor, Barry N. (2016). "CODATA recommended values of the fundamental physical constants: 2014". Reviews of Modern Physics. 88 (3). doi:10.1103/RevModPhys.88.035009.

Are there values in the tables that come from other sources? StarryGrandma (talk) 15:49, 28 June 2018 (UTC)

I have a source for historical measures, etc.
  • Fenna, Donald (2002). A Dictionary of Weights, Measures, and Units. Oxford University Press. ISBN 978-0-19-107898-9.
StarryGrandma (talk) 16:09, 28 June 2018 (UTC)
Thank you for putting this together. Praemonitus (talk) 18:12, 28 June 2018 (UTC)
I didn't see solar mass in the 2008 NIST, and the value here (1.98855e30) differs from the one in the article (1.98847e30). A possible reference for astronomical constants may be the IAU Division I Working Group values.[1] Praemonitus (talk) 20:24, 28 June 2018 (UTC)

Sources could be added to Module:Convert/documentation/conversion data/doc but please put them in a new section with no footnotes or any other changes to the current sections. The wikitext from that page is read by a script (Module:Convert/makeunits) and it is already horrendously complex and won't be able to cope with edits. It might be better if sources were on a separate page with a link to the sources added to the main page. The current /doc title was chosen as a trick to avoid MediaWiki trying to interpret the wikitext in Module namespace as a module. That is not needed now because the content model for any page can be set to "wikitext". Therefore a cleaner title could be used for a sources page. Johnuniq (talk) 23:31, 28 June 2018 (UTC)

I was planning to add them to Module:Convert/documentation/conversion data introduction/doc, the introduction, which is transcluded on the page. I believe the script doesn't see the contents of that page, but I could be wrong. StarryGrandma (talk) 02:26, 29 June 2018 (UTC)
That's a good place, thanks. Johnuniq (talk) 03:16, 29 June 2018 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Convert/Archive_June_2018&oldid=1138525517"