Template talk:Val/Archive 7

This is an archive of past discussions about Template:Val. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

This edit request to Module:Val/units has been answered. Set the |answered= parameter to no to reactivate your request.

Can we add the Jansky? Abbreviation Jy, probably in the astrophysics section. At the moment using Ju as a unit, for example in the val template, links to the dab page Jy. Lithopsian (talk) 19:25, 9 September 2022 (UTC)

 Edited – "...flux density of 42 Jy". P.I. Ellsworth , ed. ^put'r there 20:34, 9 September 2022 (UTC)

Thanks. Unit Jy is now linking correctly to Jansky. Lithopsian (talk) 20:36, 9 September 2022 (UTC)

my pleasure! Paine  20:39, 9 September 2022 (UTC)

The table in the doc sets a width on the columns to prevent line breaks in the parameter descriptions. This is a work-around and not a solution. I've asked for this to be fixed in {{para}} by making that template output html/css to prevent line breaks. — SkyLined (talk) 14:15, 3 April 2023 (UTC)

Normally in expressions like 5 ± 3 the space to the left and right of "±" is what is appropriate to binary operation symbols, not, for example, written as 5±3. And when a plus sign or a minus sign is used as a unary operation symbol, there is less space, as in +5 or −5, and so it should be also with "±".

When this template is used it looks to me as if a larger space appears to the left of this symbol than to the right. Can that be fixed? Michael Hardy (talk) 20:17, 9 July 2023 (UTC)

The history is that {{val}} used to be based on template wikitext which was replaced with Module:Val. The old {{Val/±}} (now deleted) was edited on 12 May 2015 to provide left and right margins of 0.3em and 0.15em around ± (before that, there was no margin). The module emulates what the template did. That is, val has worked like this since May 2015. There are two cases where unequal spacing happens:

• {{val|5|3}} → 5±3 (margins [0.3em]±[0.15em])
• {{val|5e3}} → 5×10³ (margins [0.25em]×[0.15em])

I can see that someone used to binary operators would want equal spacing on both sides but I think an argument could be made that the ±3 is a modifier of the 5 so the current spacing is appropriate. Some examples can be seen in the infobox at Gamma Canis Minoris which includes Rotational velocity 5±2 km/s. Astronomical unit has more examples, including exponents and the best IAU 2009 estimate was A = c₀τ_A = 149597870700±3 m. We would need a pretty solid discussion and agreement to change val now. Johnuniq (talk) 04:39, 10 July 2023 (UTC)

Ideally, we should be following a standard set by an authorative body. Failing that, we should reach consensus on what to do based on the most common way it is done outside Wikipedia. I have no data on this either way, so I cannot help. If we cannot find any data on which to base this decision, a vote will have to do.

— SkyLined (talk) 07:25, 10 July 2023 (UTC)

This edit request to Module:Val/units has been answered. Set the |answered= parameter to no to reactivate your request.

The unit "dex" links to decimal exponent, which redirects to a page that doesn't use that term, nor "dex". It would be better to link to dex (decimal exponent). That doesn't actually exist, but it gives a message saying that one can look at the entry in Wiktionary, which does define it. Eric Kvaalen (talk) 15:53, 16 December 2023 (UTC)

I'm more inclined to remove the link altogether, but I'm sure that would break something. I'd be on board with linking to a soft redirect if any of the other links are to soft redirects. SWinxy (talk) 19:15, 16 December 2023 (UTC)

The unit dex was added on 14 May 2021 by Lithopsian in diff. It was used at HD 203949 in diff. I have removed dex from Module:Val/units and replaced where it was used with wikitext that links to dex (decimal exponent). I think that is the best that can be done at the moment. In general, a discussion like this should be just a discussion. Use an edit request after there is some agreement about what should happen. Johnuniq (talk) 02:30, 17 December 2023 (UTC)

I can't figure out precisely what's causing the problem here, but in my primary browser Chrome (but not in Firefox), 123456.78901 now reads with my screen reader JAWS as "one hundred twenty three four hundred fifty six ..." instead of as "123 thousand four hundred ..." and so on, because it thinks there's a space between the digits. I'm pretty sure this was working fine in 2014 when I last brought this up. {{Gaps}} still works fine and the val template reads out properly with the other Windos screen reader, NVDA. I tried older JAWS versions back to 2020 and they still had this problem (though this isn't 100% reliable as they have shared components). Graham87 (talk) 09:12, 1 October 2023 (UTC)

Huh? It's working fine here but not in the template documentation. This problem's getting weirder and weirder ... Graham87 (talk) 09:14, 1 October 2023 (UTC)

OK it's not a val/gaps problem but an issue with whether an instance of this template is inside an ordered or unordered HTML list, per testing I've done at User:Graham87/sandbox25. Feel free to edit that page to add more test cases for me to respond to. But don't add 100000 of them ... hmmm, the val template reads correctly with my screen reader with definition/description lists! (Also, I didn't start using Chrome until 2020 so I wouldn't have previously noticed this problem). Graham87 (talk) 09:29, 1 October 2023 (UTC)

JAWS does insert random spaces in Chrome in other situations and it's apparently a fairly long-standing problem. This is the first time I've noticed it do so in a situation where people have gone out of their way to get screen readers to not display spaces! Graham87 (talk) 10:01, 1 October 2023 (UTC)

I tried the examples at User:Graham87/sandbox25#Gaps in Special:ExpandTemplates and also looked at the HTML source for sandbox25. In both cases the expected result occurs, namely the wikitext and HTML generated by {{gaps}} is identical in the three places it is used. The only difference being that the gaps HTML is in <ul><li>...</li></ul> or <ol><li>...</li></ol> when in a list. I guess there's nothing we can do about the problem unless some workaround turns up, for example a tag that would cause JAWS in Chrome to know it was a single number. It might be worth asking at WP:VPT. Johnuniq (talk) 01:59, 2 October 2023 (UTC)

I'd be very surprised if there was a tag like that ... and screen readers tend to not be good with such tags anyway. I think it's just a JAWS/Chrome bug. I might report it to Freedom Scientific, the company that makes JAWS, but given how long-standing the problem is I don't expect much traction. Graham87 (talk) 10:19, 2 October 2023 (UTC)

And it also affects bold/italic markup (which I've added to my sandbox ... I'd noticed this sort of thing before but I'd never really isolated the problem properly until now). Graham87 (talk) 11:30, 2 October 2023 (UTC)

I've mentioned this discussion at Wikipedia talk:WikiProject Accessibility#Weird bug with JAWS/Chrome inserting misplaced spaces in output, just as an FYI. Graham87 (talk) 11:42, 2 October 2023 (UTC)

I reported it and ... they fixed it in the very latest version (released last night my time), JAWS 2024.2312.53; all the items in my sandbox read out properly now! Their latest "what's new" page (archived because it's dynamic) has an item that says: "Resolved an issue where JAWS was inserting an extra space in the virtual buffer when encountering the closing tag for certain HTML elements." Graham87 (talk) 03:52, 21 December 2023 (UTC)

Hi, on bnwiki, this module does not gives result in Bengali digit, so i did this. It works but not fully, see bn:Module talk:Val#উদাহরণ for examples. And for bnwiki, {{val|1234567.1234567|fmt=commas}} should be 12,34,567.1234567 instead of 1,234,567.1234567. Please help to fix. Thanks. আফতাবুজ্জামান (talk) 21:30, 18 December 2023 (UTC)

@আফতাবুজ্জামান: Module:Val is quite complex and I never got around to providing much localization. As you can see, numdot and numsep were added for the Italian Wikipedia, and likewise mtext allows easy customization of the error messages. However, there is no method to change digit translation or digit grouping. Module:Convert has a lot more and can group digits 2,2,3 but I would be reluctant to copy that tricky code into val and test it. Regarding translating the output, why not use bn:Module:EnDigitConverter that I wrote 8 years ago? I see it's now bn:Module:ConvertDigit. Maybe bn:Template:ConvertDigit which uses the module could be put in whatever template you are using for bn:Template:Val. Johnuniq (talk) 04:16, 19 December 2023 (UTC)

@Johnuniq, If i use bn:Template:ConvertDigit, for example {{val|1234.5678|1.23|4.56|e=3|u=deg}} won't work correctly. I was trying to use Module:Num Converter and was half successful. As you can see examples here, i am getting half Bengali and half English digit (e.g. 1২৩৪.5678°±1.23°). I was wondering if you could tell me which part (line) in the module produce that 1 & 5678 & 1.23 etc, so that i can just add "convert('bn', tostring(...))" to them. If you want, please directly edit the bn:Module:Val, it's not live yet. আফতাবুজ্জামান (talk) 23:34, 19 December 2023 (UTC)

I'll try to look at the issue maybe over the weekend. Feel free to post here and remind me next week if I forget to respond. Johnuniq (talk) 09:05, 20 December 2023 (UTC)

I have started looking and translating the digits won't be a problem. I should be done in a couple of days. Johnuniq (talk) 04:29, 27 December 2023 (UTC)

I put a preliminary version at bn:Module:Val. Johnuniq (talk) 08:30, 27 December 2023 (UTC)

@Johnuniq, Thank you. আফতাবুজ্জামান (talk) 20:06, 27 December 2023 (UTC)

Compare:

• {{val|1|/|2.3|u=m/s}} → 1/2.3 m/s
• {{val|1|/|2.3|u=ft}} → 1/2.3 ft
• {{val|1|/|2.3|u=in}} → 1/2.3 in

vs.:

• {{val|1|/|2.3|u="}} → 1″/2.3″
• {{val|1|/|2.3|u='}} → 1′/2.3′
• {{val|1|/|2.3|u=°}} → 1°/2.3°
• {{val|1|/|2.3|u=deg}} → 1°/2.3°

 — sbb (talk) 01:36, 24 January 2024 (UTC)

Are you referring to how the second group repeats the unit while the first doesn't? That is an intentional feature that applies to ranges. It makes more sense when using a dash or to.

• {{val|1|-|2.3|u=ft}} → 1–2.3 ft
• {{val|1|to|2.3|u=ft}} → 1 to 2.3 ft
• {{val|1|-|2.3|u='}} → 1′–2.3′
• {{val|1|to|2.3|u='}} → 1′ to 2.3′

Johnuniq (talk) 02:09, 24 January 2024 (UTC)

(Sorry for the late reply, I don't think I was notified of your response to me).

I understand that it makes sense for ranges. But I'm not specifying a range, I'm specifying a vulgar fraction, and it seems to be supported (if only notionally) by {{val}}. If I want 1/2.3 in (as in, the sensor size, 1/2.3 in), it works. But other unit codes as noted, repeat. What is the rationale for treating different units differently? Or perhaps better asked, what is the set of units that don't repeat (such as "m/s", "ft", "in", ...) and what is the set of units that do repeat?  — sbb (talk) 03:30, 11 February 2024 (UTC)

@Sbb: In val, a slash is a range, not a fraction. It might end up looking like a fraction but val treats it as a range. That is for usage where the slash sort-of means "or". Units are repeated if the range is x or × (that's a WP:MOS issue) or if the unit is flagged with ANGLE at Module:Val/units. You might not need {{val}}. Just write out what is needed. Val is to replace tricky wikitext. Johnuniq (talk) 05:07, 11 February 2024 (UTC)

Where in WP is a range designated by a slash? I can't think of anywhere. {{val}}'s docs only mention a single example using slash, but does not prescribe slash as a range. It is merely a conjoining (conjunction) format, one of several, including range-types (hyphen, "to", "and") as well as product/area types (×, "by"). I understand that in the Lua code, "/" is treated like a conjunction, but that doesn't mean it's appropriate syntax as a conjunction.

But there's an obvious need for fractional values, and it seems slash should provide that.

And again, what is the MOS range rule that produces only the single unit label of "ft" for {{val|1|/|2.3|u=ft}} (1/2.3 ft) but the repeated unit label of "°" for {{val|1|/|2.3|u=deg}} (1°/2.3°)?

You might not need {{val}}. Just write out what is needed. I need to represent 1/2.3 in, which works with {{val}} just fine.

Val is to replace tricky wikitext. I disagree with that. Templates like {{val}} are especially useful to consistently and cleanly represent a combined value and unit, rather than having a hodge-podge of numbers that were forgotten to be wedded to a unit label with {{nbsp}}.

My point in this comment is that there's no logical reason angle unit labels should be treated any differently than other unit labels with "/". I understand that {{val}} does, but there appears to be no logic for that. And nowhere in MOS does slash indicate a sort-of range like "or".  — sbb (talk) 08:15, 11 February 2024 (UTC)

I'm just reporting how it is which has been unchanged since at least August 2015 when the template was switched to using Module:Val. Slash is handled the same way by {{convert}}. At any rate, I just added unit degree which does not repeat:

• {{val|1|/|2|u=degree}} → 1/2°

That might be adequate for your use case. Johnuniq (talk) 08:54, 11 February 2024 (UTC)

This edit request to Module:Val/units has been answered. Set the |answered= parameter to no to reactivate your request.

Hi, I intended to add the {{val}} template to this article. Therefore I suggest the addition of the CGS-but-commonly-used unit of luminosity in particle colliders, cm^-2·s^-1. Thanks, sware • 🗣 • 🏲 22:03, 21 March 2024 (UTC)

@Swaare: No edit request is needed—a unit can be added at Module:Val/units. That's a bit daunting and I'm happy to do it but some details are needed. The units are sort-of grouped logically. Do you see a place where the wanted unit would go? Each unit has an easy-to-type code to identify the unit. Any suggestion? If the unit is linked, what article should it link to? Bear in mind that there is not much point adding a unit to val if the unit will only be used in one or two places. Johnuniq (talk) 04:36, 22 March 2024 (UTC)

This edit request to Module:Val/units has been answered. Set the |answered= parameter to no to reactivate your request.

The unit "fb-1" currently links to Barn (unit). I propose that it would be better to have it link to the section Barn (unit)#Inverse femtobarn. It provides specific information on that unit and would be more helpful to readers. Also, many other units link to specific sections within an article for the same reason, so this would be justified. Purplemountainman^talk contribs 21:21, 27 March 2024 (UTC)

Done. Johnuniq (talk) 03:19, 28 March 2024 (UTC)

This is causing spacing issues on articles. See for example the usage on K2-18b in the "Evolution" section. Is there any way to shrink the numbers so that it fits within the line without enlarging the surrounding space? Viriditas (talk) 20:55, 3 April 2024 (UTC)

Not really. There is an accessibility guideline somewhere saying that text should not be too small. If that format is considered undesirable, perhaps some manual wikitext could be used to say +this -that? Johnuniq (talk) 05:34, 4 April 2024 (UTC)

Is it possible to add a parameter yielding a pop-up of the unit name without the link?-- Carnby (talk) 08:41, 15 September 2024 (UTC)

Not a parameter, but it can be defined in the unit. Search for "abbr" at Module:Val/units. Example:

• {{val|12|u=mg/L}} → 12 mg/L

Johnuniq (talk) 08:55, 15 September 2024 (UTC)

@Johnuniq I see. I was asking just because amperes (A) was written "amps" in FASTON terminal.-- Carnby (talk) 12:17, 15 September 2024 (UTC)

Are Decibel units intentionally omitted from this template? Adding |ul=dB linking to Decibel would be a good start. If someone wants to go to town on it, see Decibel § List of suffixes for a bunch of derived units. ~Kvng (talk) 19:38, 14 September 2024 (UTC)

Although I would not be averse to adding specifically only |ul=dB as a widely known unit, I would oppose any of its suffixes (e.g. dBm) or other metric prefixes (e.g. B = 10 dB, cB = 0.1 dB). The use of units of logarithmic strength of field and power quantities (bell, decibel, neper, etc.) is without the level of systematization that the SI has (including a heavily entrenched historical choice), and we cannot cater to the myriad inconsistent variations in a general template, nor should we be favouring any variant over another. —Quondum 13:43, 4 October 2024 (UTC)

Thanks. Like I said, adding |ul=dB linking to Decibel would be a good start. Is there someone who could do this? The template is protected. ~Kvng (talk) 16:33, 4 October 2024 (UTC)

Kvng, if you want to request this change, see the process outlined at Wikipedia:Edit requests. —Quondum 13:03, 10 October 2024 (UTC)

The current list of units contains:

Tg [[Tonne|g]] SI

which is not correct: a Tg is a teragram, i.e. 10¹² g, which is a million tonnes, not just one. Can we please fix this?

Spidermario (talk) 16:50, 10 July 2024 (UTC)

It has been like that for a long time. Perhaps whoever added those units thought Teragram was not a suitable link target? Anyway, the fix is simple. It would be nice if someone examined Module:Val/units and commented here if there were any other problems that should be fixed at the same time. I'll have a look in a couple of days if no one beats me to it. Johnuniq (talk) 01:29, 11 July 2024 (UTC)

I have made a brief scan through it. This is not comprehensive (the syntax is not that familiar to me) but this is what I notice (in addition to Tg, which could be linked to Teragram (unit)).

Ω [[Ohm|Ω]] SI → should be extended with support of the SI prefixes.

uM [[Molarity|M]] 1e-6 →
uM [[Molarity|M]] SI
μM [[Molarity|M]] SI

There may be some esoteric cases (e.g. pp [[Page (paper)|pp]] and possibly R [[Rayleigh (unit)|R]] SI) that do not belong in a general template such as this.

—Quondum 13:27, 4 October 2024 (UTC)

Further observations:

Remove the nonstandard mcg [[Microgram|g]] SI.

The barn (all cases that link to Barn (unit)) is nonstandard (and esoteric, even though quite well-known in a specialized area of particle physics). It also potentially conflicting with other uses of 'b' (such as for 'bit'). We should not be linking these in a general template such as this: these should be linked explicitly from the article.

There are problems with lack of support for some SI units (e.g. siemens: {{val|ul=S}} → S, ohm: {{val|ul=uΩ}} → uΩ, and possibly more.

Johnuniq, this is the kind of thing that I tended to contribute to and maintain, but this has become a protected template, and working through a "please implement this change" request process is just too cumbersome for me to do it this way. If we can find an alternative where I can work on changes with less friction (but preferably without full template editor capabilities), I could be more actively involved with Module:Val/Units. —Quondum 12:57, 10 October 2024 (UTC)

I will put a message at your talk about the template editor right. Some enthusiastic editors have added a bunch of units to val but that rather misses the point of the template. It is not possible to cover every conceivable unit that someone might want to use and the idea was that units would be added when needed, not because they might be nice. A big problem is that it is hard to find out if a unit is currently used. Therefore, removing a unit from the module might break an article. To my mind, that suggests units should not be added until they are needed. However, hundreds have been so cleaning up what is there would be good. Years ago, when I was working on Module:Val, I downloaded a database dump of all articles and extracted a list of all {{val}} usages. There is a tool for examining template usage now although I have forgotten how to find it at the moment (template tiger?). I thought it was in a link on one of the standard pages (Template:Val or history?). Someone will know. Johnuniq (talk) 01:08, 11 October 2024 (UTC)

This template was edited to include an unmatched closing HTML tag. Surely this is not correct? —Quondum 02:48, 27 November 2024 (UTC)

No, that's a very valid thing to do, and that's not a closing tag (/ comes first in the angle brackets), that's a single tag (/ comes last). More in a few minutes... 97.102.205.224 (talk) 02:56, 27 November 2024 (UTC)

@Quondum: To expand, that's actually the recommended way to use safesubst: in a template. Normally, subst: and safesubst: are expanded when the page is saved, which is unwanted in this case. By including <noinclude /> after safesubst:, that expansion is suppressed, but if Template:val is itself subst:ed, the <noinclude /> tag is stripped out resulting in a nested substitution safesubst:#invoke:val which is expanded when the subst:ing page is saved.

Does that make sense? Basically, you can transclude {{val}} normally, in which case the <noinclude /> disappears and {{safesubst:#invoke:val}} expands as if safesubst: weren't there. Or you can use {{subst:val}}, in which case the template and the nested substitution are both expanded at page-save time. You can see the same thing in the source for Template:Shy. 97.102.205.224 (talk) 03:11, 27 November 2024 (UTC)

That must be my "dislexia" coming through (I can pretend, can't I?) – so it is something like <nowiki/> being used to insert a parsing break. Anyhow, I've learned something: it is the first time that I've seen this (but I still have not dissected how includeonly/noinclude function). It woulda helped if the recommendation was actually linked in the edit summary where it was inserted. —Quondum 13:37, 27 November 2024 (UTC)

Sometimes Wikipedia formats large numbers like π(20²⁹) = 1,520,698,109,714,272,166,094,258,063 or 2²⁵⁶ = 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936 and the articles currently manually insert zero-width spaces to allow line wrapping, especially if the numbers are in table and need to fit in narrow columns. E.g. Prime number theorem § Table of π(x), x / log x, and li(x).

Would it be practical to extend {{Val}} to do this automatically? It's a niche application, and perhaps the answer is simply "no".

I'd happily swap the commas for thin spaces, and I quite like val's current trick which cuts & pastes the number without the spaces but I don't think the span left-margin hack would disappear at a like break as the inter-digit space is required to do. One option would be to add |fmt=commabreak and |fmt=thinsp options to insert comma+zwsp or (breakable) thin space and sacrifice the nifty cut&paste property.

The annoying thing about zwsp is that it's invisible, so it's easy to unknowingly cut & paste it into the input of {{Val}}, which produces a very mysterious error: {{val|1​520​698​109​714​272​166​094​258​063}} produces Error in {{val}}: parameter 1 is not a valid number. Perhaps <wbr /> would be better?

Another thing that might be nice for large numbers is different groupings. It's common to display really long strings of decimal digits, such as the digits of pi in groups of five rather than three. A |group=5 parameter might be nice. (Handling the Indian numbering system § Use of separators is left as an exercise for the truly masochistic.)

Anyway, thank you for considering this! 97.102.205.224 (talk) 16:43, 26 November 2024 (UTC)

It might make sense to provide a separate template aimed at formatting large numbers with breaking such as you suggest. IMO, it should not be {{val}}. The copy & paste issue with {{zwsp}} in your example is IMO the result of inappropriately using that template. —Quondum 18:28, 26 November 2024 (UTC)

@Quondum: I'm not sure quite what you mean by "inappropriate"; could you clarify? Just to un-simplify the example, the cut & paste issue came when I cut & pasted 1,​520,​698,​109,​714,​272,​166,​094,​258,​063 from Prime number theorem § Table of π(x), x / log x, and li(x) and manually deleted the commas. (Guess what I didn't delete?)

The wikisource on that page is {{zwsp|1,|520,|698,|109,|714,|272,|166,|094,|258,|063}}. Is that "inappropriately using that template"? I was considering switching to <wbr />, but discovered that {{wbr}} includes a zero-width space in its expansion.

I've run into a very similar problem with the output of the Windows Calculator. If you use it to compute a number, then cut & paste the result into Wikipedia, you'll get invisible text direction characters. If you feed that number to {{Val}}, you'll get the error mentioned above. I documented this to help future editors.

I'm thinking any use of {{zwsp}} with numbers is "inapproprate", but I'm not sure what to use instead. 97.102.205.224 (talk) 22:38, 26 November 2024 (UTC)

I understood your example, and am basically fully in agreement with you. When we copy & paste, we want no surprises. I am also saying that modifying {{val}} is, IMO, not the place to implement it. {{wbr}} may be ossified, though my impulse would have been to remove the zwsp from it. Perhaps a new template {{breaks|123|456|789|123|456|789|123|456|789}} that achieves the desired effect 123456789123456789123456789123456789 is the way to go? This would be very easy to do. —Quondum 23:06, 26 November 2024 (UTC)

@Quondum: The thing is, I do want visible grouping in the formatted wikitext, whether it be commas or gaps. Something like 1,520,698,109,714,272,166,094,258,063 or 1 520 698 109 714 272 166 094 258 063. Can you think of a way to achieve the "no spaces in copied text" effect while also having the space disappear at line breaks? Just using the <span style="margin-left:.25em;">...</span> trick produces 1520698109714272166094258063, which leaves an unwanted indent on the line after a wrap. Can I apply a style to <wbr style="margin-left:.25em;" />? 1520698109714272166094258063 Ooh! That Seems to work! 97.102.205.224 (talk) 00:00, 27 November 2024 (UTC)

{{val}} was created for formatting (scientific) values, as in numbers with units. It's not designed to allow arbitrary formatting of numbers. While I'm sure we could integrate that into the existing features, I think that would overload the template with too many features and add too much complexity. I agree that a different template for formatting numbers in various ways would be a better option. — SkyLined (talk) 22:48, 26 November 2024 (UTC)

Looking at the source for Module:Val, I've discovered Module:Gapnum and Module:Gaps which might be more appropriate for simple integers. The latter has a wrapper Template:Gaps, but I'm trying to figure out the difference between the two modules. and places spaces between its multiple arguments, while the former breaks up its single main argument. 97.102.205.224 (talk) 23:16, 26 November 2024 (UTC)

I'm not convinced that route will give you anything: {{gaps}} does not introduce wrap points. What about a new template? —Quondum 23:34, 26 November 2024 (UTC)

@Quondum: It's a reflex reaction, but I think it's because, as an IP editor my experience has been that edit requests are generally answered in an hour or two, while the new page queue is days, so I've been trained to prefer the former if at all possible. 97.102.205.224 (talk) 00:23, 27 November 2024 (UTC)

A complex change to a highly used module such as Module:Val is unlikely to happen in a few hours if at all, even if you detailed the exact changes (witness the two objections already). OTOH, since I am editing under a login, I should be able to create a fresh template that invokes module Separated entries if we settle on the code and a template name. —Quondum 00:53, 27 November 2024 (UTC)

@Quondum: Well, I was asking if the change was a good idea, and hadn't written code yet, so I expect a different sort of discussion. But note that the discussion started in less than 2 hours and didn't languish in a queue for days! I think that rather makes my point, actually.

I agree with you about eliminating the zwsp from {{wbr}} and I've already started a discussion there. The person who last added the zwsp (in 2015) is still an active editor and I've pinged them. It's easy to have it support both zero-argument and multi-argument forms, just like my recent change to Template:Zwsp. Then all I'd need to do is add a |gap= parameter. The one trick is that I'd like a missing parameter to add no gap, for compatibility, but an empty parameter to insert the default .25em. So something like <wbr {{#switch:{{{gap}}}|{{{gap}}}=|=style="margin-left:.25em"|style{{=}}"margin-left:{{{gap}}}"}}/>

(mw:Help:Extension:ParserFunctions#Use with parameters says that syntax works to detect unset parameters, but I'm not sure. I might use {{#switch:{{{gap|0}}}|0=|... instead.)

If I create a new template, I'd like to think about the name carefully. {{breakable gaps}} with a redirect from {{brgaps}} comes to mind, but it's kind of awkward. I'll ruminate on it a bit.

Thank you for your very helpful feedback! 97.102.205.224 (talk) 02:56, 27 November 2024 (UTC)

That the conversation started so soon is maybe an unusual occurrence. Template editors have enough work just answering fully worked out requests without debates. And this just happens to be one of the extremely short list of pages that are currently on my watchlist. Perhaps we should avoid making this thread here even bigger, and move to my talk page when you're ready. —Quondum 14:04, 27 November 2024 (UTC)

Trial template at User:Quondum/sandbox/brgaps. —Quondum 18:33, 27 November 2024 (UTC)

1. I was editing Mechanical television and I set {{val|5|x|5|ul=pixel}} yielding 5 pixel × 5 pixel. Quite clumsy. I find 5 pixel × 5 pixel or 5 × 5 pixels more aesthetically appealing.
2. Why is fmt set to gaps by default? Aren't commas the standard thousands separator in the English Wikipedia Manual of Style?

-- Carnby (talk) 20:37, 5 December 2024 (UTC)

Matching your numbering:

1. The repetition of the unit in a product of dimensions is required by MOS:UNITSYMBOLS. The idea of linking it only once probably makes sense, though, and it might make sense to update this template to do this with the |ul= parameter.
2. No, WP:DIGITS does not prefer one or the other, though the comma as separator is is contrary to SI requirements ("Neither dots nor commas are inserted in the spaces between groups of three"), which fits with the MOS requirement that SI units are essentially required in all articles aside from those with strong ties to the US, and in some cases in the UK. So in effect, most scientific articles end up using gaps, which is the primary intended use for {{val}}. {{convert}} defaults to the comma as separator. —Quondum 22:38, 5 December 2024 (UTC)

@Quondum Thank you. Could you please remove the second of the two unit links?-- Carnby (talk) 22:54, 5 December 2024 (UTC)

I can't make the change myself. I'm separating this into a separate request in a thread below. —Quondum 22:12, 6 December 2024 (UTC)

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)

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)

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)

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

Description of suggested change:

Diff:

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):

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)

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)

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.

— 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: ${\displaystyle 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 dictate 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)

I mention copying it because I have seen this used as a consideration before in the construction of templates; it is even mentioned a few times in the archives of this template. Are you "quite certain" that people do not copy text from Wikipedia? Perhaps others will comment on this. —Quondum 01:24, 29 May 2025 (UTC)

No, apologies for the confusion: I personally I don't want a space to be copied when I copy a number with uncertainty. To me the spacing is purely cosmetic and not functional and shouldn't be enforced with a space but continue to be implemented with CSS. — SkyLined (talk) 05:09, 29 May 2025 (UTC)

Okay, got it. I'll go along with adjustment of the CSS to balanced spacing anywhere from 0.22em to 0.3em. —Quondum 11:14, 29 May 2025 (UTC)

@Lithopsian: Thanks for User:Lithopsian/sandbox but IMHO something simpler is needed to give people an easy way to compare spacing. Perhaps extract some ± examples with text around them so they are not too artificial, say a paragraph of a few lines and a list of a couple of items like in an infobox. Then show two copies in the sandbox, one using val and the other val/sandbox. In principle, this discussion should be blessed at MOS but they did not seem to want to get involved so here will do. Johnuniq (talk) 09:14, 29 May 2025 (UTC)

I've stripped it down to a more minimal example, showing the original, changed, and proposed spacings in a table and in free text. Feel free to edit if you can make it clearer or more complete. Note that I hard-coded the "original spacing" examples rather than mock up a complete new module. Lithopsian (talk) 15:33, 29 May 2025 (UTC)

Please see User:Lithopsian/sandbox (permalink) for examples of how val was before the recent change, is now, and would be with a new proposal. The new proposal is to reduce the current before-and-after spacing from 0.30em to 0.225em. The proposal has some support at MOS (link above) and here so I will implement it in around 48 hours unless people have other suggestions. Johnuniq (talk) 03:25, 30 May 2025 (UTC)

Done. Johnuniq (talk) 05:40, 1 June 2025 (UTC)

Thanks, it looks brilliant! No, seriously, it is hardly noticeable, but I think I've already spotted a couple of tables that are no longer too wide for the space they're originally fit it. {{±}} to follow? And then there is {{ErrorBar2}}, which uses space characters to the left and right of the "±". Should that be a separate TFD? An earlier comment suggests that some people may prefer it this way. Lithopsian (talk) 12:54, 1 June 2025 (UTC)

Good point. I had intended to do ±. I have just changed it to match the new val. I don't know anything about ErrorBar2. Maybe change its sandbox and suggest an edit at talk? Ping me from there if you like. Johnuniq (talk) 04:24, 2 June 2025 (UTC)

I would caution against updating ErrorBar2 to match without good reason. Unlike here, that could be considered to be a substantive change, being a replacement of spaces with CSS spacing. —Quondum 12:19, 2 June 2025 (UTC)

Please add the dioptre to the list, probably in the Length, Area, Volume section.

dpt   [[Dioptre|dpt]]
D   [[Dioptre|D]]

I didn't see any conflict with the 'D' unit with anything else; it's rarely used as a diopter value, mainly only by opticians. If it's not added, that's fine. But 'dpt' would be useful in marking up values in some of the optics pages. Thanks.  — sbb (talk) 07:43, 14 June 2025 (UTC)

'D' conflicts with debye, a unit of electric dipole moment still commonly used in chemistry.

Do either 'D' or 'dpt' have any status in optometry as a symbol, as opposed to being an abbreviation or shorthand? To be a symbol, I would think that it needs to be recognized as such (generally by some authoritative or governing body in the field: compare au, for example), and would be useful in forming compound symbols; otherwise it might best be regarded as as a "typical abbreviation" (various abbreviations, not generally consistent, occur everywhere, and supporting those through this template may be unwise). The utility of including it here is, of course, simply for the convenience of being able to use |ul=dpt rather than |u=[[Dioptre|dpt]]. —Quondum 10:31, 14 June 2025 (UTC)

I have no idea about any governing body in the field of optometry. But regarding what's in texts, or what's being taught in optics, there's several examples that mostly show "D" (Many fewer referred to "dpt").

• "Dioptres (D)" Ray (2002), p. 36.
• "When dealing with powers, the term diopter with symbol “D” is usually used instead of inverse meters," Atchison (2018), p. 44.
• "more commonly referred to as diopters (D). Diopters is the preferred unit in ophthalmic and visual optics because ..." Thibos (2018), p. 109.
• "image quality in the presence of 1.5 diopters (D) of anisometropia ... vary from 1D to 2D. ... the largest interocular difference occurred at distance (0D) and intermediate (1.5D) object distances." Zheleznyak, Sabesan & Geunyoung (2018), p. 125.
• "The mean spherical equivalent was reduced from −6.2 to −3.7 diopters (D) ... and to −2.1 D ... from −4.2 to −3.0 D ...", and "led to an average improvement of 2.3 diopters (D) 1 week postoperative." Mrochen, Lemanski & Pajic (2018), pp. 135–136.
• "The relationship between power (K) and focal length (f) is that a focal length of 1000 mm is a power of one dioptre (1 D)," Jacobson et al. (2000), p. 101.
• "The refractive power V_i is measured in units of diopters (dpt) with 1 dpt = 1/m." Teubner & Brückner (2019), p. 114.
• "When f is in meters, the unit of power is the inverse meter, or diopter, symbolized by D: 1 m⁻¹ = 1 D." Hecht (2017), p. 211.
• "The units of optical power are called “diopters” (D). That is, 1 D = 1/m, or 1 m⁻¹." LibreTexts (2025)
• "The dioptric power is measured in units of m⁻¹, also called diopters (dpt)." Parschotta (n.d.).

 — sbb (talk) 23:34, 14 June 2025 (UTC)

References

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

To remove an extraneous space, on page Module:Val/units please replace

lbf [[Pound (force)|<span title="pound-force">lb<sub>F</sub></span> ]]

with

lbf [[Pound (force)|<span title="pound-force">lb<sub>F</sub></span>]]

The superfluous space is noticeable when, for example, a quantity with this unit is followed immediately by punctuation. —Quondum 21:50, 23 June 2025 (UTC)

 Done — Martin (MSGJ · talk) 22:02, 23 June 2025 (UTC)