Template talk:Val
![]() | Template:Val is permanently protected from editing because it is a heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use {{edit template-protected}} to notify an administrator or template editor to make the requested edit. Usually, any contributor may edit the template's documentation to add usage notes or categories.
Any contributor may edit the template's sandbox. Functionality of the template can be checked using test cases. |
This is the talk page for discussing improvements to the Val template. |
|
Archives: 1, 2, 3, 4, 5, 6, 7Auto-archiving period: 3 months ![]() |
![]() | This template does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||
|
![]() | The template {{Val2}} was considered for deletion on 2014 February 7. The result of the discussion was "move to Template:Val/sandbox2". |
Request: remove duplicate link
[edit]When the linked unit (|ul=
or |upl=
) is duplicated in a product by {{val}}, the link is duplicated unnecessarily, for example:
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
[edit]![]() | This edit request to Module:Val/units has been answered. Set the |answered= parameter to no to reactivate your request. |
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
[edit]![]() | This edit request to Module:Val/units has been answered. Set the |answered= parameter to no to reactivate your request. |
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
[edit]![]() | This edit request has been answered. Set the |answered= parameter to no to reactivate your request. |
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):
- 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 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)
- Yes, candela would be used in Daytime running lamp.-- Carnby (talk) 09:35, 4 May 2025 (UTC)
− | + | 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
[edit]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)
Protected edit request on 23 May 2025
[edit]![]() | This edit request to Module:Val has been answered. Set the |answered= parameter to no to reactivate your request. |
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.
- As the original creator of
- — SkyLined (talk) 16:52, 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)