Template talk:Val

A teragram is not a tonne

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)

Decibel

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)

Pop-up

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)

Feature request: breakable numbers

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

Weird code

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)