Template talk:Val

Ohms and omegas

In the realm of electrical resistance, the Greek letter capital omega (Ω) is used, which is inconvenient to type. Can we get some aliases for the relevant units? "Ohm", "ohm", and "Omega" all seem like good options. — LucasBrown 11:08, 8 June 2026 (UTC)

@LucasBrown: I have looked at doing this but am having trouble because it's a very long time since I worked on val and I'm having trouble understanding why obvious unit definitions don't work with SI prefixes that I assume you would want (I can see what's going on but the why is puzzling and I can't see a workaround at the moment). I'll think about it in a few days. Remind me if I forget. Johnuniq (talk) 05:28, 9 June 2026 (UTC)

Done. I added definitions for ohm and some SI prefixes: ohm Gohm Mohm kohm mohm μohm uohm nohm. Examples:

• {{val|999|u=ohm}} → 999 Ω
• {{val|1|u=kohm}} → 1 kΩ
• {{val|1|ul=uohm}} → 1 μΩ

Johnuniq (talk) 03:28, 13 June 2026 (UTC)

Heat capacity and viscosity

Hello I've been templatizing Chemboxes lately, and Chembox_Thermochemistry could badly use a unit here for Molar heat capacity (the same units are used in a couple of other fields in the chembox).

I propose adding:
J.mol-1.K-1 Molar heat capacity - J⋅mol^-1⋅K^-1
J/mol.K Molar heat capacity - J/(mol⋅K)
I use the existing kJ.mol-1 unit code on every chemical page I edit, then have to manually correct J.mol-1 to add the ⋅K^-1 as a postfix right now, which makes the template much uglier than it could be. This ordering is how the CRC Handbook of Chemistry and Physics and most wikipedia pages already use it, but the SI definition is apparently the equivalent J/(K⋅mol) and that's what the molar heat capacity page lists, so it might be worth adding the additional two that match that (also since J.mol-1 and J.K-1 both exist here already). There are also probably pages on here somewhere that order things like that so it might make converting those to val slightly easier.
J.K-1.mol-1 Molar heat capacity - J⋅K⁻¹⋅mol^-1
J/K.mol Molar heat capacity - J/(K⋅mol)

I don't know if molar heat capacity is the best place to link since it applies to entropy and I think a couple of other less used fields in Chembox_Thermochemistry but it has no specific page for the SI unit like some of the others (and probably won't), and heat capacity defines it more clearly than any other article I could find.

For the division versions, I'm not sure how parens are normally handled in unit codes and I'll end up using the -1 exponent versions pretty much exclusively anyway so do what you will with that info. I'm only requesting them for parity with the multiply-by-inverse versions and the existing similar templates. I don't think kJ variants are needed, the CRC Handbook's table headers don't use anything but the J version.

And also while I'm at it, the SI Dynamic viscosity unit would be useful but is less commonly needed and I don't know how much work this stuff is:
μPa.s Dynamic Viscosity - micropascal-second mPa⋅s
mPa.s Dynamic Viscosity - millipascal-second mPa⋅s
Pa.s Dynamic Viscosity - pascal-second mPa⋅s

The Pascal-second is equivalent to N·s/m² if that info is useful for some reason. It isn't written that way in tables or data sheets. The CGS equivalent is the centiPoise (cP) which is equal to 1 mPa·s and shows up in US safety data sheets sometimes. I don't think it had an entry when I last tried to use it in ul, but it could link to the Poise (unit) page and would probably want normal / milli / micro / and possible kilo versions as well. I'm not requesting this one though, there's nothing complicated involved in typing it.

Thanks A Shortfall Of Gravitas (talk) 18:45, 18 June 2026 (UTC)

I'll do this in a couple of days, remind me if I forget. I removed the edit request as that is not needed here. A couple of points need clarification first. The above definition for J.mol-1.K-1 displays as

Molar heat capacity - J⋅mol^-1⋅K^-1

when linked, or as

Molar heat capacity - J⋅mol^-1⋅K^-1

when not linked. Is that really what is wanted? With the name using uppercase "M", and a hyphen dash, and the symbol? No other units are shown like that in val. Similarly, the three proposed viscosity units display with a doubly uppercase name and mPa⋅s as the symbol for each (I assume that's a copy/paste problem and the m needs to be adjusted). And a reminder to myself: need to investigate why Template:Val/list is showing "invalid definition" for four units. Johnuniq (talk) 06:14, 19 June 2026 (UTC)

Apologies for that... the capitalization isn't needed; I spaced out and forgot to remove the name, I think I was intending to just write the name of the page it should link to (if linking was enabled) with the stuff after the dash being the rendition of the output, then looked at the code and figured out the rendition should be the link text, then got tired and forgot what I was doing. It should just be:

J.mol-1.K-1 J⋅mol^-1⋅K^-1

J/mol.K J/(mol⋅K)

J.K-1.mol-1 J⋅K⁻¹⋅mol^-1

J/K.mol J/(K⋅mol)

Without the target page name / text in the output link or unit, like everything else. Like I said the parenthesized versions aren't really required, I stuck them in as convenience templates. I'm also making the assumption that adding a unit causes little rendering overhead in the module, so if this isn't the case for some reason just the J.mol-1.K-1 and J.K-1.mol-1 versions would be ok.

And you're correct, the mPa⋅s everywhere was a copy-paste error (and the capitalized units should be left out) and those should be:

μPa.s μPa⋅s

mPa.s mPa⋅s

Pa.s Pa⋅s

kPa.s kPa⋅s

Hopefully I got all those right this time.

Lower SI prefixes only apply to gases where viscosity isn't generally given / specified in chembox. I threw kPa⋅s on there in case someone wants to use it for a non-newtonian fluid since those are more common, though I don't know if I'll ever encounter a chembox for one. Everything higher than that applies to things that aren't usually described in terms of viscosity except on that page (like the Earth's mantle).

I'm remembering to watchlist this this time so I don't disappear for as long. Sorry about that confusion. A Shortfall Of Gravitas (talk) 15:20, 15 July 2026 (UTC)

@A Shortfall Of Gravitas: I added the units illustrated below. Please check—is this correct?

• {{val|12|ul=J.mol-1.K-1}} → 12 J⋅mol⁻¹⋅K⁻¹
• {{val|12|ul=J/mol.K}} → 12 J/(mol⋅K)
• {{val|12|ul=J.K-1.mol-1}} → 12 J⋅K⁻¹⋅mol⁻¹
• {{val|12|ul=J/K.mol}} → 12 J/(K⋅mol)
• {{val|12|ul=μPa.s}} → 12 μPa⋅s
• {{val|12|ul=mPa.s}} → 12 mPa⋅s
• {{val|12|ul=Pa.s}} → 12 Pa⋅s
• {{val|12|ul=kPa.s}} → 12 kPa⋅s

Johnuniq (talk) 04:22, 16 July 2026 (UTC)

Speaking of molar heat capacity, could we have the celsius version as well? i.e. J/mol.C or J/mol.degC → J/(mol·°C), whichever is the convention for °C, same for the others one with K→°C. Headbomb {t · c · p · b} 04:43, 16 July 2026 (UTC)

Val uses degC for Celsius (C for coulomb). Is this what is wanted?

J.mol-1.degC-1 → J⋅mol⁻¹⋅°C⁻¹

J/mol.degC → J/(mol⋅°C)

J.degC-1.mol-1 → J⋅°C⁻¹⋅mol⁻¹

J/degC.mol → J/(°C⋅mol)

Johnuniq (talk) 05:06, 16 July 2026 (UTC)

Yip. Headbomb {t · c · p · b} 05:26, 16 July 2026 (UTC)

I added these. Is this correct?

• {{val|12|ul=J.mol-1.degC-1}} → 12 J⋅mol⁻¹⋅°C⁻¹
• {{val|12|ul=J/mol.degC}} → 12 J/(mol⋅°C)
• {{val|12|ul=J.degC-1.mol-1}} → 12 J⋅°C⁻¹⋅mol⁻¹
• {{val|12|ul=J/degC.mol}} → 12 J/(°C⋅mol)

Johnuniq (talk) 05:50, 16 July 2026 (UTC)

Looks exactly like above? Is there a difference? Headbomb {t · c · p · b} 07:52, 16 July 2026 (UTC)

Those look correct to me, TY very much. I just started using the J.mol-1.K-1 in a chembox. It'll save me a lot of ugly manual formatting. Weirdly I've never seen the degC version in reference material but since the values for them should be the same I'm sure someone has used it at some point. I'm in the US so naturally I use fahrenheit for almost everything outside of science (and some things that do involve science like hotplate temps) but I truly hope there's not some abomination of molar entropy using Joules combined with degF floating around.  :-)

Thanks again. A Shortfall Of Gravitas (talk) 22:07, 16 July 2026 (UTC)

Automatic conversion from confidence interval to +/-uncertainty

In medicine and biology a lot of values are given as the 95% confidence interval (or Bayesian HPD interval) instead of the +/-uncertainty. However, the {{val}} notation is often preferable in tight spaces such as the sub-labels of {{clade}}. Currently to format a number such as 42190 (95% HPD: 23554-77587), one would have to subtract both numbers from 42190 to arrive at {{val|35397|17636}}. Using #expr: is possible but still unwieldy to type.

It would be very helpful if Module:Val could accommodate this kind of use case by adding an option that causes it to treat an "asymmetric uncertainty" as an interval to convert into the +/- notation. Or if there is a similarly compact way to notate such an interval with a center value (be it the mean or the peak of the probability density). Artoria2e5 🌉 05:02, 19 June 2026 (UTC)

I'm totally lost. When doing it manually, you have to subtract two numbers from a third number. I can't see what numbers you mean in the above example. Please clarify. I gather you are looking for ideas at the moment but if you have something in mind, it would be helpful if you could list some sample wikitext (hypothetical parameters to val) and what output they would produce. Johnuniq (talk) 06:24, 19 June 2026 (UTC)

I may be wrong, but in your example of "42190 (95% HPD: 23554–77587)", '42190' represents a mean value for a distribution that is not necessarily normal; by re-calculating it to 35397±17636, you're altering the meaning of the data, by stating the mean value is 35,397 with range of +/−17636. The mean and Bayesian range points are the "hard data", and presenting it differently is misrepresenting the data.

Also, I think what you're trying to do is incorrect, according to the confidence interval article (emphasis mine):

Credible intervals are a Bayesian analog to confidence intervals in frequentist statistics. The two concepts arise from different philosophies: Bayesian intervals treat their bounds as fixed and the estimated parameter as a random variable, whereas frequentist confidence intervals treat their bounds as random variables and the parameter as a fixed value. Also, Bayesian credible intervals use (and indeed, require) knowledge of the situation-specific prior distribution, while the frequentist confidence intervals do not.

 — sbb (talk) 15:57, 4 August 2026 (UTC)

Add ppt & ppq (parts per trillion/quadrillion) units?

For completeness' sake, and because four (ppm, ppb, ppt, ppq) are bold-mentioned (defined) in the Parts-per notation article, and their corresponding parts per million, parts per billion, parts per trillion, and parts per quadrillion links are all redirects to the same Parts-per notation article, can we have the following lines added just below ppm (currently line 657):

ppq  [[Parts per quadrillion|ppq]]  1e-15
ppt  [[Parts per trillion|ppt]]  1e-12

re: ppt = thousand/trillion ambiguity: per mil/mill/mille are already well-covered for parts-per-thousand.  — sbb (talk) 17:00, 4 August 2026 (UTC)

Assuming this is going to be used, I made that edit. Johnuniq (talk) 06:15, 5 August 2026 (UTC)

I was mid-edit hoping for the change. Thanks! =)  — sbb (talk) 23:19, 5 August 2026 (UTC)

Screen readers

I've noticed that the numbers formatted with gaps cause problems in Apple's VoiceOver screen reader. For example, {{val|123456.78901}}, which outputs 123456.78901, is read by VoiceOver in four groups: "one hundred twenty three" / "four hundred fifty six" / "seven hundred eighty nine" / "zero one". It should instead be one group, read as "one hundred twenty three thousand four hundred fifty six point seven eight nine zero one". With commas, i.e. using |fmt=commas (output: 123,456.78901), VoiceOver reads it correctly.

I'm testing on Safari with iOS 26.5. I don't know how other screen readers handle it, but it would probably be a good idea to test it in other screen readers too.

Can we adjust the HTML output of {{Val}} to make it work with VoiceOver? If someone finds a good solution, it could be applied to {{Gaps}} and {{Convert}} too.

Lugel (talk) 10:54, 17 August 2026 (UTC)

This sounds like a VoiceOver bug or misfeature. Both the main Windows screen readers, NVDA and JAWS, read the template fine, but the latter had problems with it in Chrome until I reported a bug about it to their manufacturer (see Template talk:Val/Archive 7 § Screen reader problems with digits grouped by spaces in this template). VoiceOver is notoriously not well-maintained so I don't think reporting a bug there would be fruitful in the short/medium term (but then, I said the same about JAWS, and was pleasantly surprised about how quickly they got on top of it. But I think JAWS is more actively worked on than VoiceOver and support people for JAWS are much easier to get a hold of. Graham87 (talk) 14:31, 17 August 2026 (UTC)

Just tested on Firefox on iOS 26.5. Read & Speak (which I believe is mechanically similar to VoiceOver) reads the template correctly. Toast of Fate ♡ talk to me! 22:11, 24 August 2026 (UTC)

ergs and other instances of linking not the exact unit text

I noticed an issue regarding this template in the article Foe (unit). In the first Line the Val Template is used for a Unit called an "erg", but which has to be written "ergs" because of the sentence structure. The Template automatically links to ergs, even though it should redirect to Erg (unit). I have found no way within the Val Template to fix this. I might have just missed something, but as far as i see, there is no way for a unit to link to anything except its exact text, including grammatical particles like the plural -s. I think this is a problem. one might also imagine other circumstances where one may want to make a unit link to something except its exact text, like maybe having m/s link to velocity, not meters per second. I don't know if it is feasible to fix this without breaking the Template since it's so heavily used, but I wanted to let you guys know of this issue. Wikipedian of Gondor (talk) 08:36, 8 September 2026 (UTC)

If val has a definition for a unit, the parameter ul will use whatever link is in that definition. Otherwise, val puts [[ before and ]] after whatever text was specified by ul. If ergs were needed often, it would make sense to define a unit for it. However, it is not reasonable to have enough definitons to cover every possibility. In that case, simply use parameter u and give whatever wikitext you like. Examples:

• {{val|e=51|u=[[Erg (unit)|ergs]]}} → 10⁵¹ ergs
• {{10^|51}} [[Erg (unit)|ergs]] → 10⁵¹ ergs
• {{val|12345.67890|u=[[Velocity|m/s]]}} → 12345.67890 m/s

The second line above (using {{10^}}) works well but a line break may occur between the number and the unit. That is ok according to MOS:UNIT. If wrapping is not wanted, {{nowrap}} could be used although that would make val easier. Johnuniq (talk) 09:28, 8 September 2026 (UTC)

I briefly thought it could be done with {{convert}} but {{convert|1|foe|erg|disp=out|abbr=off|lk=out}} gives 1.0×10⁵¹ ergs. There's no way to suppress that "1.0×", is there? Such a rare want. NebY (talk) 11:04, 8 September 2026 (UTC)

No, the 1.0 can't be removed. And, someone pointed out that erg links to the wrong page at Template talk:Convert#Disambiguate the unit 'erg'. Fixing that is on my to-do list. Johnuniq (talk) 11:56, 8 September 2026 (UTC)

Thanks and thanks! NebY (talk) 12:00, 8 September 2026 (UTC)