Template talk:Val

Request: remove duplicate link

When the linked unit (|ul= or |upl=) is duplicated in a product by {{val}}, the link is duplicated unnecessarily, for example:

23 m × 12 m × 10 m

Can this be changed to linking only the first occurrence of the unit is linked? I can't suggest a detailed change to the code at this point due to unfamiliarity with Lua. —Quondum 22:12, 6 December 2024 (UTC)

Template-protected edit request on 18 December 2024

Line 84: change link from Year#Symbols y and yr to Year#Symbols and abbreviations Reason: broken section link 94.175.200.195 (talk) 19:18, 18 December 2024 (UTC)

Done: {{val|12|ul=yr}} → 12 yr. A more robust system for section would be desirable, such as {{anchor}} in the article. Johnuniq (talk) 02:57, 19 December 2024 (UTC)

Template-protected edit request on 8 February 2025: Bohr magneton

Please add the Bohr magneton μ_B to the units list, in the "Nuclear physics and chemistry" section. I suggest the abbreviation "μB", although that risks ambiguity with a micro- prefix. I came across a need for it in the Invar article and had to use a workaround. I believe the line required is

μB   [[Bohr magneton|''μ''<sub>B</sub>]]

Thank you! 97.102.205.224 (talk) 17:54, 8 February 2025 (UTC)

 Completed. P.I. Ellsworth , ed. ^{put'er there} 18:09, 8 February 2025 (UTC)

I don't think that the concern about ambiguity with the prefix will manifest. The only conflicting cases that I see are microbel, microbuckingham, and microbyte, none of which I would be expected to be used. The requested use seems to be the best use. —Quondum 18:21, 8 February 2025 (UTC)

Edit request 4 May 2025

Description of suggested change:

Diff:

−

+

cd [[Candela]] lm [[Lumen (unit)]]

Carnby (talk) 09:09, 4 May 2025 (UTC)

Are you saying two units should be added, namely cd and lm? That would happen at Module:Val/units. Can you briefly say how these would be useful in an example article? At any rate, leave this open for couple of days to see if anyone has an opinion then set answered=no to reactivate the request. Johnuniq (talk) 09:28, 4 May 2025 (UTC)

Yes, candela would be used in Daytime running lamp.-- Carnby (talk) 09:35, 4 May 2025 (UTC)

I agree that a change is appropriate, since these SI units and their prefixed versions currently link badly, e.g. 5 cd 5 lm, 1 klm, 1 mcd. I'll try to look into an exact change in a few days. —Quondum 14:42, 4 May 2025 (UTC)

You might like to look at the old version of the doc that I wrote at permalink. Since then, I implemented a request to combine the base unit and the link into a single entry in the form of a wikitext link. There has been no change to the SI part of the definition so my original doc is all that is needed to understand what "SI" does. I find the current doc confusing. Johnuniq (talk) 09:36, 5 May 2025 (UTC)

I agree that the documentation has become a challenge to read. But the module has become a monster too, and hence IMO unmaintainable. The simplicity of the version that you linked is needed, but it does not answer my question either. Nevertheless, I have ascertained that the template, for all of the "convenience" that it offers, seems to need a separate definition for each prefix. I'm not sure that adding all these is really warranted. I have not figured out how to test a sandboxed version of the /units page (and the documentation seems to assume that the requesting editor is able to test on the live version).

My guess is that the following change might work for the coherent base units (grouping with lx makes sense, and supporting all the SI multiples seems overkill):

−

lx [[Lux (unit)|lx]]

+

cd cd Candela SI lm lm Lumen (unit) SI lx lx Lux (unit) SI

Note also that this module does not seem to support the four new SI prefixes (r, q, R, Q) yet. —Quondum 17:25, 5 May 2025 (UTC)

Too much space between integer number and ± uncertainty

I feel like this is a new (regression) issue, because I don't recall {{val}} producing this problem before.

As of this comment, {{val}} renders {{val|11|22}} as 11±22 (hard-coded: 11±22 ), with 0.3em left margin and 0.15 right margin around the '±'.

Is this intentional? It looks awkwardly spaced.  — sbb (talk) 17:43, 22 May 2025 (UTC)

I have noticed this too, and wondered whether it is intentional. I have been noticing it for many months, though (but not sure how long). It does seem weird (and a bit annoying). —Quondum 17:53, 22 May 2025 (UTC)

Spacing around ±

Please modify line 631 of Module:Val from

'<span style="margin-left:0.3em;margin-right:0.15em;">±</span>' ..

to

'<span style="margin-left:0.3em;margin-right:0.3em;">±</span>' ..

That is, change the 0.15em to 0.3em. This balances the spacing around the "±" at about the width of a normal space. (This is prompted by the previous section.) —Quondum 00:32, 23 May 2025 (UTC)

I have disabled the edit request for now because val has worked like this since May 2015 and a major discussion should occur before changing ten-year old behavior. See Template talk:Val/Archive 7#Horizontal spacing for a couple of examples where the current spacing works well. I can see both sides of the argument: someone looking for symmetry wants equal spacing (particularly with the simplified example above), but from a semantic point of view, the ± is part of the uncertainty. For example, {{val|5|3}} (5±3) has two components: the value and the uncertainty. At any rate, the question should concern not how these contrived examples look, but how val is used in articles with much more complex values. Johnuniq (talk) 01:19, 23 May 2025 (UTC)

The current format is a sort of visual average between the two semantics: the '±' being a binary operator and it being a unary operator on a second spaced adjacent value. It had no space when Module:Val was created (I have not been able to find what the template did: it seemed to be determined by a now-deleted subpage), and was changed to the present spacing with no edit comment on 2015-01-08. The unary interpretation would mean that "100 2" should be naturally interpreted as 100 with an upper uncertainty limit of 102, which is ridiculous, so I would argue that "the ± is part of the uncertainty" without a binary operator is just nonsense IMO, rather needing to be written as "100 + ±2". In any event, having a visual half-way point between two different semantics is really ugly semantically, not to mention confusing, nonstandard, and not conforming with the examples at MOS:UNCERTAINTY. I agree that a discussion is warranted before a change; the question might be whether there will be anyone interested enough. —Quondum 12:45, 23 May 2025 (UTC)

As the original creator of {{val}}, I'm sad to say I don't know how we got here either. But one thing I do know is that from the start I've tried to follow whatever standards Wikipedia had for formatting numbers, and ask for them to be created if I found none. This discussion should be held at Wikipedia:Manual_of_Style/Dates_and_numbers and consensus should be reached there before any changes are made here.

— SkyLined (talk) 16:52, 23 May 2025 (UTC)

I asked for opinions at WT:Manual of Style/Dates and numbers#Spacing around ±. MOS:UNCERTAINTY says that {{+-}} and {{val}} may be used. Special:ExpandTemplates shows that they produce identical output (except that val has nowrap and a sort key by default). Each of the following generates margin-left/right = 0.3em/0.15em.

• 5±3 ← 5{{±|3}}
• 5±3 ← {{val|5|3}}

{{+-}} originally had no spacing around ±. The template was changed in December 2020 to match what val does.

An example of usage is at Astronomical unit#Development of unit definition:

the best IAU 2009 estimate was A = c₀τ_A = 149597870700±3 m

Johnuniq (talk) 02:57, 24 May 2025 (UTC)

FWIW, here is how Latex does it: $149\ 597\ 870\ 700\pm 3\ {\text{m}}$, which appears to be symmetric. Since a very large percentage of scientific papers are submitted using TeX based systems, as well as many books published with TeX based math, I suggest that this is a "source" for such spacing. Johnjbarton (talk) 03:21, 24 May 2025 (UTC)

I had hoped for more input because I hate changing code that has worked a certain way for many years unless extensively discussed. However, the main point was for people to have an opportunity to give an opinion, and that has happened. Accordingly, assuming no further discussion occurs, I will make the change specified above (0.3em before and after) in around 24 hours. Johnuniq (talk) 03:15, 26 May 2025 (UTC)

If it is any comfort, a short search in retrospect yielded:

• several fully balanced examples (the first few being most authoritative)
  • JCGM 100:2008 (BIPM) (10,11 ± 0,04) mm
  • ISO/IEC Guide 98-3:2008 Part 3: Guide to the expression of uncertainty in measurement [1] – just a copy of JCGM 100:2008
  • NISP SP 260-202 10.011 mg/g ± 0.025 mg/g
  • (100.021 47 ± 0.000 70) g
  • 28.8 ng mL⁻¹ ± 1.1 ng mL⁻¹
  • Consequently, the measurement result is often stated as: y ± U
  • −1.0 ± 0.1 grams
• one fully unbalanced example
  • NRC Canada: The measured result is 10,000.051Ω ±0.028Ω (non-spacing of the unit is sketchy here)
• and no compromise examples matching our long-standing 0.3em & 0.15em spacing

Thanks for the update to the module. —Quondum 12:56, 26 May 2025 (UTC)

Done. Johnuniq (talk) 05:18, 27 May 2025 (UTC)

Is 0.30em on both sides a smidge too much? It seems like a lot of whitespace compared to what I'm used to in other contexts. Or perhaps just too much compared to what it was before in WP? Keeping the total spacing as before might have been a good idea, although perhaps impractical at 0.225em? I suspect there will be some subtle fallout across the thousands of articles that just had table widths or columns get wider. Lithopsian (talk) 15:15, 27 May 2025 (UTC)

At WT:Manual of Style/Dates and numbers § Spacing around ±, a figure of 0.22em was mentioned as what LaTeX does. —Quondum 16:18, 27 May 2025 (UTC)

I appreciate swift action over endless debate but I think waiting a few days, or even a week or two before making changes, would give people a chance to chime in with valuable insights. Not everybody has time to edit Wikipedia daily and even those that do may go on a holiday.

Let's not change it anymore and move the discussion to MoS. Once we have consensus there, we update the MoS as well as this template (unless we agree to keep the current spacing) — SkyLined (talk) 16:50, 27 May 2025 (UTC)

I agree that conservative is good, but if you are arguing we should make the best small change first, then as suggested by Lithopsian, keeping the total space constant is a smaller change. As as you say most cases won't be even looked at in a day, changing now is less disruptive than two changes spaced apart. Johnjbarton (talk) 16:55, 27 May 2025 (UTC)

If anyone wants the spacing changed, a sandbox should be setup with clear examples of the alternatives with real-world examples because there is no point having a discussion with only hazy ideas. Johnuniq (talk) 03:31, 28 May 2025 (UTC)

You mean like the initial change was sandboxed and demonstrated so people could see it in action? So, I've edited Module:Val/sandbox with 0.225em spacing before and after, and I've edited User:Lithopsian/sandbox to contain a copy of HD 133131 which directly invokes the module sandbox for the starbox detail panel on the right. The details for star HD 133131A use the 0.225em spacing, and star HD 133131B uses 0.3em before and after (don't strain your eyes on the astrometry section because it is template-generated and hence all unchanged). I haven't noticed a live instance of real breakage yet, which would make for a better test. I could mock up a table that causes some wrapping or overflow issues, but it would very much depend on the theme and fonts in use so probably not very helpful or reproducible. Lithopsian (talk) 14:36, 28 May 2025 (UTC)

There are two slight technical obstacles, which complicate this discussion. As far as the MoS is concerned, it will not in general exact spacing, and as such it would remain mute on this (a space is a space), even though you could get opinions from the MoS crowd. The first is that we cannot expect people in general editing to try and match the {{val}} template, so a fine-tuned spacing cannot be considered a form of standard. The second is that when text is copied from the page, we actually want a space to be copied from either side of the '±', instead of no space, which is the case with both the previous and current versions of the template. This means that we should also consider simply inserting space characters and removing the margins.

I have no strong preference whether {{val}} tweaks the exact width here. I'm just giving some points that should also be considered. —Quondum 16:48, 28 May 2025 (UTC)

In not sure why you believe "we want a space to be copied". I am quite certain there is no consensus on that, since I disagree. — SkyLined (talk) 00:19, 29 May 2025 (UTC)