Template talk:Val

Unit request: dpt, D (diopter)

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

• Guenther, Bob D.; Steel, Duncan G., eds. (2018). Encyclopedia of Modern Optics. Vol. 5 (2nd ed.).
  • Atchison, David A. "Optics of the Human Eye". In Guenther & Steel (2018), pp. 43–63.
  • Mrochen, Michael; Lemanski, Nicole; Pajic, Bojan. "Laser and Light in Opthamology". In Guenther & Steel (2018), pp. 130–139.
  • Thibos, Larry N. "Refractive Errors in Wavefront Sensing". In Guenther & Steel (2018), pp. 108–115.
  • Zheleznyak, Len; Sabesan, Ramkumar; Geunyoung, Yoon. "Methods of Vision Correction". In Guenther & Steel (2018), pp. 116–129.
• Hecht, Eugene (2017). Optics (5th ed.). Pearson.
• Jacobson, Ralph E.; Ray, Sidney F.; Attridge, Geoffrey G.; Axrod, Norman F. (2000). The Manual of Photography (9th ed.). Focal Press.
• [LibreTexts] "The Eye". LibreTexts Physics. 2025-03-16.
• Parschotta, Rüdiger (n.d.). "Dioptric Power". RP Photonics Encyclopedia.{{cite web}}: CS1 maint: ref duplicates default (link)
• Ray, Sidney F. (2002). Applied Photographic Optics (3rd ed.). p. 36.
• Teubner, Ulrich; Brückner, Hans Josef (2019). Optical Imaging and Photography. de Gruyter.

Indian number system

The commas aren't considered for Indian Number System which uses commas for every two digits as seen in for example 10,12,23,344 reads ten crores twelve lakhs twenty three thousand three hundred and forty four. Footy2000♡; 04:02, 17 June 2025 (UTC)

What is being asked? Use of the Indian numbering system has been discussed at WP:MOS several times. I forget the details but I believe consensus is that the English Wikipedia does not use that system other than when discussing how it works. Johnuniq (talk) 05:11, 17 June 2025 (UTC)

English is an official language of India, and the first language of tens of millions of people. As such it should be accorded the respect we pay other dialects, including its counting method.

So this should, primarily, be an option for readers rather than editors. Martin Kealey (talk) 01:18, 3 August 2025 (UTC)

Request: allow range of different orders of magnitude

Periodically, articles discuss a range of orders of magnitude. I.e., "typical values ranging from 10¹² to 10¹³ m/s²", which would be currently coded as something like "... {{10^|12}} to {{10^|13}} {{val|u=m/s2}}"}}.

I'd like to be able to express the range as something like: {{val|e1=12|to|e2=13|u=m/s2}}. This would have the same non-breaking space semantics that {{val}} currently uses, as well as more clearly grouping/identifying the numerical values and units.  — sbb (talk) 18:40, 23 June 2025 (UTC)

I'm going to argue against this, even though the same thought has occurred to me as well.

• First, the effort needed to implement this and debug it, not counting future increased maintenance effort due to the increased code complexity, might exceed the combined total of writing the equivalent of say {{val|e=12}} to {{val|e=13|u=m/s2}} in not all that many articles.
• Second, let's keep the focus of {{val}} on what should be its primary purpose: ensuring that what it generates is MoS-conformant, not as providing a mildly convenient shorthand for every variant that we consider. IMO, by supporting ranges at all, it introduced excessive complexity and enshrined a controversial format: ranges with elision of units, which I do not support in a template: technically, we should be writing "10¹² m/s² to 10¹³ m/s²". We automatically duplicate the units in 200 mm × 300 mm, for example. We also already have a controversial format in "100±12 m" – note the absence of the SI-mandated parentheses. Let's not add to this.

Sorry to be a wet blanket ... —Quondum 19:42, 23 June 2025 (UTC)

No worries about 'wet blanket', it's not that wet. =) You have some decent reasons for arguing against. However,

• Completely disagreed with "technically, we should be writing '10¹² m/s² to 10¹³ m/s²'". That's much less readable, and not at all how people vocalize the reading (i.e., not how they read it in their heads).
• Duplicating units for 'by' or '×' makes more sense (but also, MOS allows grouping the units to the end).
• re: "100±12 m": I don't see how that's controversial. Just because SI mandates something for scientific writing, doesn't mean we have to mandate that for encyclopedic (i.e., layperson) writing. MOS does not dictate Roman (upright, non-italic) differentiation operators (⁠d/dt⁠ vs. ⁠d/dt⁠) even though ISO dictates it. And I don't think MOS should dictate it.

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

I'm not invested in this, so here I'm being informative rather than arguing anything. My only point of any significance is my "first" one above: complexity in templates is bad news, and you'd have to persuade a template editor that it is justified. Complexity is less with variant templates rather than trying to cram many features into one template. But this isn't my fight to fight: I'm simply hinting that I do not expect anyone to take this one up. Other general comments:

• The balance between a rigorous form (one that maximally eliminates ambiguity) is indeed a MoS choice; being an encyclopaedia whose readers are often not that trained it disambiguating (and editors who are often not that sensitized to it), my preference tends towards minimizing potential interpretive ambiguity. However, I have not failed to notice that my position is not universally shared in the MoS debates, and I fully understand the need to abide by consensus. Articles vary in technicality and I feel that rigour of expression should vary accordingly. For example, in most of our math articles, lack of rigour would have no chance, whatever the MoS might have to say about it.
• The change allowing a single unit on multiple dimensions is recent, and is new to me. Insanity, IMO. But then, I avoid WT:MoS to preserve my sanity. Especially as one of the resident editors there acts as though he owns the MoS, so his opinion bulldozes everything (people tend to be meek in competition as a result, so it normally does not look like there is much objection).
• The MoS tends to defer to the SI brochure to some extent, but not to ISO, so the point about ISO is not strong.

Anyhow, I think we're pretty much on the same page. —Quondum 23:08, 23 June 2025 (UTC)

Counter to my points, and (possibly?) supporting yours (I definitely don't want to put words in your mouth), in the particular example I provided as justification for this change, one could use {{val|1|e=12|-|10|e=12|u=m/s2}} → (1–10)×10¹² m/s². That is at least distributively semantically correct. I don't think I'd suggest that form, simply because it implies a linear range of values between 1 and 10, instead of an exponential (order of magnitude) range. And of course, it's an abuse of scientific notation, and not really engineering notation either.

Hmm... the more I think about it, the more I agree with you that "{{val|e=12}} to {{val|e=13|u=m/s2}} → 10¹² to 10¹³ m/s²" is probably the best compromise between intention and conciseness.  — sbb (talk) 14:27, 24 June 2025 (UTC)

It is probably best to separate the two issues: (a) the MoS issue (i.e. what is a reasonable form to display for a given meaning, which has nothing to do with templates), and (b) what does it make sense for the template to implement. Most of our discussion here has been about (a), but this is the wrong place for that (and consensus might be elusive, so focusing there might not be helpful without taking it to MoS); this leaves (b). Is there something sensible that we can say about what the template should implement, without resolution of (a)? —Quondum 15:10, 24 June 2025 (UTC)

Very salient point. No, I don't think there's any traction to be had on (b) without resolving (a). And to that end, I don't think it's sensible to make modifications to {{val}} without a clear path, specification, and implications of the changes. Thanks for the conversation and your patience. =)  — sbb (talk) 17:19, 24 June 2025 (UTC)

It's a pleasure to chat to someone with whom I can debate without feeling I'm working at cross purposes or getting triggered. —Quondum 17:53, 24 June 2025 (UTC)

Ditto! =) 👍🤝🙏  — sbb (talk) 18:07, 24 June 2025 (UTC)

It's a long time since I've looked at Module:Val but I suspect this would be difficult. The module can handle an unlimited number of values in a range with various symbols between them (there is an artificial limit of, I think, 20 items as a sanity check). Johnuniq (talk) 06:59, 24 June 2025 (UTC)

"The module can handle an unlimited number of values in a range with various symbols between them", as long as those values all have the same exponent parameter |e=. Example:

• {{val|5.0|e=5|-|1.5|e=6|u=m}} produces (5.0–1.5)×10⁶ m because the 2nd |e= setting |e=6 sets the exponent for all values in the 'to'/'-'/'by' list.

Note that I'm not complaining about this behavior. I think a×10^b – c×10^d [u/up] with different exponents b and d is way too confusing.  — sbb (talk) 14:02, 24 June 2025 (UTC)

Extraneous space

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)

Feature request: Adjective mode, and spelling out units in full

Sometimes, one wants to use this template for a value-with-units, and have the units spelled out in full, rather than displayed as an abbreviation; for example, one might want to display "100 meters" rather than "100 m". Also sometimes, one wants to use this template for a value-with-units that serves as an adjective, such as displaying "a 100-meter race". In such cases, MOS:HYPHEN indicates that the number and unit should be separated by a hyphen.

It would be nice to have optional parameters to control this behavior. Both of these functionalities are already present in Template:Convert, so I imagine that porting that behavior here should be fairly easy for someone familiar with templating. — LucasBrown 17:27, 26 June 2025 (UTC)

Exponents for webcrawlers

(This is a follow-up to Talk:Solar_mass.)

I suggest that the results presented to web crawlers be generated using unicode exponent digits rather than <sup> tags, or alternatively with an interposed ^ (caret/circumflex symbol) to indicate exponentiation.

Unicode exponent digits would arguably be beneficial to ordinary readers, as sup tags do not necessarily reduce the font size enough to avoid altering line spacing.

The same issue arises when rendering fractions, but I thought I'd start here. Martin Kealey (talk) 01:08, 3 August 2025 (UTC)

I think you are saying that some of the unit definitions in the Astrophysics section at Module:Val/units should be changed. Any chance of a list here showing the current and proposed symbols? I don't think you'll have much luck changing the way fractions are rendered. Johnuniq (talk) 03:19, 3 August 2025 (UTC)

MOS:SUP#General_guidelines bans unicode exponents, and for good reasons. This template is not exempt from it. Headbomb {t · c · p · b} 10:07, 3 August 2025 (UTC)

No I'm not talking about changing symbols, I'm talking about power-of-ten exponents.

The solar mass should not be rendered to screen readers or web crawlers as “1.988416×10³⁰ kg” because they will strip tags (including <sup>) and render it as “1.988416×1030 kg” -- which is just stupidly wrong.

Exponents should be rendered in a way that does not rely on HTML tags; exactly how I don't really care, though my suggestion is that M_sol could be rendered as either “1.988416×10³⁰ kg” or “1.988416×10^30 kg”.

I don't have the energy to argue a change to MOS:SUP, though I'm dismayed that it effectively requires <sup> tags, directly contradicted a core tenet of web accessibility: that the plain text should read reasonably with all tags stripped away. While the webcrawlers' behaviour is suboptimal, it is not "wrong" to a degree that would justify "fixing" it.

(Separately, the problem with fractions is that they don't include a solidus when the HTML tags are trimmed out, so “three and a half” eventually appears as “312”. Either “3½” or “3¹⁄₂” would ideal, but “3+1/2” or “3.5” would acceptable; “3 1/2” would almost be tolerable.)

Martin Kealey (talk) 07:17, 5 August 2025 (UTC)

You are describing a problem in the guidelines, not the template. As much as you'd like to avoid it, the MoS is the place where this needs to be fixed, so the fix gets implemented everywhere. — SkyLined (talk) 09:08, 5 August 2025 (UTC)

You're describing a problem with webcrawlers, not wikipedia. The solution is to fix the webcrawlers, not gimp Wikipedia. Headbomb {t · c · p · b} 13:14, 5 August 2025 (UTC)

Separator position

In Finnish wikipedia we use thousand separator (space) after three digits (not four as is default), diff: [1]. Are there other wikis that might benefit from having it easily configurable instead of using the default? Space as separator might need to be a non-breakable space instead of plain space, testing it. Ipr1 (talk) 04:09, 13 August 2025 (UTC)

nbsp does not seem to work as separator (not added into result) and there is span for decimal part. Edit: already has "nowrap" span. Forget that comment. Ipr1 (talk) 04:13, 13 August 2025 (UTC)

Separator(s) should not be used in decimal part (fraction) though. Ipr1 (talk) 04:43, 13 August 2025 (UTC)

I'm trying to work out why (ten years ago, at what is now Module:Val#L-544) I used #numstr == 4. Normally I would have <= for a test like that. By default (if parameter fmt is not used), val inserts gaps to make groups of three digits. The code at line 544 is saying (for enwiki) that if neither fmt=commas nor fmt=gaps is specified, a four-digit integer should have no gap. I suppose the extra internationalization would be desirable next time we update the module. There was no planning for i18n originally because getting the module to work at all was sufficient challenge. There would be other grouping requirements at some projects. Johnuniq (talk) 05:05, 13 August 2025 (UTC)

Semantically, it makes sense to treat the specific exceptional case of formatting for a four-digit integer as its own case (as you did) rather than including the shorter ones, since these fit into the standard logic. I barely looked at the code, but that would have been my approach. I do not properly understand the OP's point, though. Should we drop the default no-separator behaviour for a four-digit integer? We should not put gaps into year numbers, but otherwise it would be more consistent to have a separator. It is there as soon as a decimal point is added, not consistent with MOS:DIGITS, which says Numbers with exactly four digits left of the decimal point may optionally be grouped (either 1,250 or 1250), consistently within any given article. I would suggest adding the separator by default now, rather than now remove it in, say, 1234.56. —Quondum 13:30, 13 August 2025 (UTC)

Yes, but re the OP, they are suggesting another variable to make it easier for any other projects which might want to customize Module:Val so four-digit numbers are displayed with a gap by default. Regardless of the merits of that (and val should not be used to display a year), some projects might follow that procedure and it would be easier for them to change the variable at the top of the module than finding what magic number to change in the code. Val would be unchanged at enwiki. Johnuniq (talk) 03:56, 14 August 2025 (UTC)

Ah. This suggests a process that I was unaware of: that other-language wikis duplicate code from here with tweaks. It seems reasonable to code with that in mind. —Quondum 15:25, 14 August 2025 (UTC)