Template talk:Val
| Template:Val is indefinitely protected from editing as it is a heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use {{edit template-protected}} to notify an administrator or template editor to make the requested edit. Usually, any contributor may edit the template's documentation to add usage notes or categories.
Any contributor may edit the template's sandbox. Functionality of the template can be checked using test cases. |
| This is the talk page for discussing improvements to the Val template. |
|
| Archives: 1, 2, 3, 4, 5, 6, 7Auto-archiving period: 3 months |
| This template does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||
The template {{Val2}} was considered for deletion on 2014 February 7. The result of the discussion was "move to Template:Val/sandbox2". |
Separator position
[edit]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)
Edit: already has "nowrap" span. Forget that comment. Ipr1 (talk) 04:13, 13 August 2025 (UTC)nbspdoes not seem to work as separator (not added into result) and there is span for decimal part.- 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 parameterfmtis not used), val inserts gaps to make groups of three digits. The code at line 544 is saying (for enwiki) that if neitherfmt=commasnorfmt=gapsis 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)
- As mentioned above, plus I also want to point out that there is no intention of using this for year numbers (those get easily complicated enough with before and after zero markings) so I would rule that outside of possible uses. Rather, year markings should use something like a "date" template (if using anything at all). Ipr1 (talk) 02:05, 13 October 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)
- 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)
- I'm trying to work out why (ten years ago, at what is now Module:Val#L-544) I used
Solid angles
[edit]Could someone with the relevant authority add the following to the list of supported units?
- steradian
- square degree
- square arcminute
- square arcsecond
- square milliarcsecond
- microarcsecond
- square microarcsecond
This can already be done by, for example, writing {{val|1|deg, but it would be nice to be able to write that as <sup>2</sup>}}{{val|1|deg2}} instead. — LucasBrown 15:36, 9 February 2026 (UTC)
- We would need to find standard symbols before doing this. Until then, I suggest using the ad hoc method (full formatting being provided as in your example) should be the way to go. "deg" is not an accepted symbol, for example; it is simply an abbreviation. —Quondum 15:42, 9 February 2026 (UTC)
- The following symbols are standard:
- sr
- deg2
- arcmin2
- arcsec2
- mas2
- μas
- μas2
- As to the abbreviation part, many symbols are supported that are simple, unformatted abbreviations, such as "y", "s", "b", and more. Also, supporting these units would allow the
{{val}}'sulparameter to automatically link to the articles about the units for us, so there is benefit beyond simply removing the need to type<sup>...</sup>. — LucasBrown 15:57, 9 February 2026 (UTC)
- The following symbols are standard:
- Pardon my failure to assume that your understanding of "standard" in not the same as mine, but can you substantiate that these are standardized? Inclusions of "y" and "b" are bad edge-cases, examples of template-rot, unsuitable as a precedent. "s" is the standard symbol for 'second'. I can find mention of 'mas', 'μas' and 'pas' in a footnote of the 9th SI Brochure (but the base symbol 'as' would be excluded!), suggesting that these may be common enough in astronomy as to be a pseudo-standard (and thus allowing the construction of 'mas2', for example). However, 'deg', 'arcmin' and 'arcsec' seem to be too informal to be regarded as symbols rather than simply abbreviations; they are translated by the template to the accepted symbols °, ′ and ″. If you could provide a resolution of a General Assembly of the International Astronomical Union, for example, that might give a sufficiently authoritative "standard" designating the symbols. —Quondum 16:35, 9 February 2026 (UTC)
- The use of "sr" is supported in https://www.bipm.org/documents/20126/41483022/SI-Brochure-9-EN.pdf at the top of page 23 (page 137 going by the page numbers printed on the pages).
- For "mas", see section 5.14 at https://iauarchive.eso.org/publications/proceedings_rules/units. For further support, see this article from The Astrophysical Journal, which is more-or-less the premier journal for astronomy and astrophysics. I could not find explicit support for "mas" in that journal's style guide, but it is all over the place in the article that I linked. — LucasBrown 17:03, 9 February 2026 (UTC)
- Pardon my failure to assume that your understanding of "standard" in not the same as mine, but can you substantiate that these are standardized? Inclusions of "y" and "b" are bad edge-cases, examples of template-rot, unsuitable as a precedent. "s" is the standard symbol for 'second'. I can find mention of 'mas', 'μas' and 'pas' in a footnote of the 9th SI Brochure (but the base symbol 'as' would be excluded!), suggesting that these may be common enough in astronomy as to be a pseudo-standard (and thus allowing the construction of 'mas2', for example). However, 'deg', 'arcmin' and 'arcsec' seem to be too informal to be regarded as symbols rather than simply abbreviations; they are translated by the template to the accepted symbols °, ′ and ″. If you could provide a resolution of a General Assembly of the International Astronomical Union, for example, that might give a sufficiently authoritative "standard" designating the symbols. —Quondum 16:35, 9 February 2026 (UTC)
- Apologies for not being clearer about what I have no objections to; that might have saved you time. Specifically, 'sr' is a standard SI symbol as you have pointed out, and should be supported by this template, along with a correct
|ul=link (I see that it is not yet supported), and 'mas', 'μas' and even 'pas' are sufficiently supported that I have no objection to them (and their squared forms) being added as suggested. Note that 'mas' is already supported. Of your list, it is only the choice of symbols for deg2, arcmin2 and arcsec2 that are contentious. —Quondum 19:16, 9 February 2026 (UTC)- The style guide of the Monthly Notices of the Royal Astronomical Society explicitly endorses deg2: "Use the degree symbol ° except to denote e.g. areas, where deg2 may be more appropriate (e.g. a survey area of 3 deg2)." In the same section where that quote is found, the style guide explicitly endorses "arcmin" and "arcsec" in situations where one is not specifying coordinates. Combined with the explicit endorsement of deg2, this strongly implies approval of arcmin2 and arcsec2. — LucasBrown 21:22, 9 February 2026 (UTC)
- Looking good. Since there are no obvious competing ways of expressing these quantities in symbol form, adopting an approach pioneered by a journal in the field seems sensible. I'll need a bit of time to figure out the needed edits to the template/module data, then I'll ask a template editor to make the change (unless someone objects in the interim). —Quondum 21:49, 9 February 2026 (UTC)
- I have no objections, I just wanted to note how civil and well argumented this thread has worked itself towards the current solution of inclusion. — SkyLined (talk) 04:21, 10 February 2026 (UTC)
- Looking good. Since there are no obvious competing ways of expressing these quantities in symbol form, adopting an approach pioneered by a journal in the field seems sensible. I'll need a bit of time to figure out the needed edits to the template/module data, then I'll ask a template editor to make the change (unless someone objects in the interim). —Quondum 21:49, 9 February 2026 (UTC)
- The style guide of the Monthly Notices of the Royal Astronomical Society explicitly endorses deg2: "Use the degree symbol ° except to denote e.g. areas, where deg2 may be more appropriate (e.g. a survey area of 3 deg2)." In the same section where that quote is found, the style guide explicitly endorses "arcmin" and "arcsec" in situations where one is not specifying coordinates. Combined with the explicit endorsement of deg2, this strongly implies approval of arcmin2 and arcsec2. — LucasBrown 21:22, 9 February 2026 (UTC)
- Apologies for not being clearer about what I have no objections to; that might have saved you time. Specifically, 'sr' is a standard SI symbol as you have pointed out, and should be supported by this template, along with a correct
This edit request to Module:Val/units has been answered. Set the |answered= parameter to no to reactivate your request. |
In accordance with the discussion above, I have produced an updated version of the units at Module:Val/units/sandbox. The intended changes are reflected here, and the whole sandbox could be copied and pasted in place of the existing Module:Val/units. I have tested these changes in my sandbox, but not updated Template:Val/testcases, which seems to need quite a bit of work to bring it up to date. I snuck in hyphenation of the link to kilowatt-hour as per the actual article title. —Quondum 19:51, 10 February 2026 (UTC)
- Done, thanks. Johnuniq (talk) 03:04, 11 February 2026 (UTC)
- The links for arcmin2, arcsec2, mas2, uas2, and μas2 currently point to square angle, which redirects to right angle. They should instead point to square degree. — LucasBrown 04:21, 11 February 2026 (UTC)
- I changed those. Please let me know if any other problems. Johnuniq (talk) 06:43, 11 February 2026 (UTC)
- Argh, my bad. I had intended to link to Solid angle, but somehow managed to use a portmandeau of the two, which did not produce a redlink. I agree with the link to Square degree, as there is a specific section Square degree#Subdivisions that mentions arcmin2 and arcsec2 specifically, and which could be naturally expanded to accommodate the additional smaller units. —Quondum 12:43, 11 February 2026 (UTC)
- I changed those. Please let me know if any other problems. Johnuniq (talk) 06:43, 11 February 2026 (UTC)
- The links for arcmin2, arcsec2, mas2, uas2, and μas2 currently point to square angle, which redirects to right angle. They should instead point to square degree. — LucasBrown 04:21, 11 February 2026 (UTC)
Test cases
[edit]For a while I intend be adding test cases to Template:Val/testcases. There are a lot of instances where the module is in error, and therefore, expect many of these new tests to fail until the module is corrected for these. Feel free to correct the template (or errors in my tests) in the interim, or to leave the corrections for later. An example problem is that the new SI prefixes (Q, R, q, r) are not properly supported by the template. —Quondum 17:16, 12 February 2026 (UTC)
- I just prepared a new section with documentation for how testcases works. I will put it below in a new section to keep it in a convenient place for future reference. Johnuniq (talk) 23:03, 12 February 2026 (UTC)
- Though your description below is convenient, it seems to allow existing errors to go undetected, as was abundantly clear after your recent update of Template:Val/testcases. In particular, if the existing output is bad (invisibly incorrect characters such as the micro sign instead of the Greek mu, and incorrect sorting values), these are simply hidden in this approach. By preparing the tests before updating the module sandbox, correct behaviour can be achieved more directly, even though it is tedious. Sure, it serves as a way to follow changes easily, but that is tracking, not really testing.
- As a related aside, {{val}} has become a maintenance nightmare by the way it is designed, relying on another complex template ({{convert}}), and not parsing the syntax of units, giving rise to exponential complexity (in number of prefixes, units, ways of combining) of implementation and testing. I would think that it is getting to be where this module should be entirely rewritten. —Quondum 23:40, 12 February 2026 (UTC)
Johnuniq, I have made updates to Module:Val/units/sandbox and Template:Val/testcases. These seem good based on the testcases as I expect them to behave. I have not updated any of the codes that use the micro sign, as articles may be using these, pending discussion. If you are comfortable with it, you can copy the sandbox across to the live version, or else we can first discuss any misgivings that you might have and the micro sign. I would even be inclined to eliminate both the micro sign and the mu on input, requiring ASCII 'u' instead (once these have been found and replaced). —Quondum 01:33, 13 February 2026 (UTC)
Testcases
[edit]The system at Template:Val/testcases is obscure. It uses Module:Convert/tester which is intended for hundreds of tests (possibly a couple of thousand before template limits are hit). When I last looked years ago, the other unit test systems would not handle that many.
There is no point making manual changes to the testcases. Instead:
- Edit the samdbox modules for any wanted changes, for example, to alter units.
- Edit Template:Val/testcases to make any wanted alterations/additions to the templates at the left margin.
- For any added template, put nothing after it (no expected output).
- Do not try to edit the expected output which follows on the same line as each template.
- Edit Template talk:Val/testcases and replace its contents with
{{#invoke:convert/tester|make_tests|page=Template:Val/testcases|show=all|template=val/sandbox}} - Preview the edit and copy the displayed output. To do that, select the first couple of words, scroll to the bottom of the page, hold down Shift and select the last couple of words.
- After copying the preview, you can close the edit window to abandon the edit.
- Edit Template:Val/testcases, select all, paste the preview from talk.
- You can view changes if wanted, or just publish the edit.
Later, if ever needed, the history of Template:Val/testcases can be used to track what changes have occurred to the way {{val}} behaves.
- Module:Val • Module:Val/sandbox • same content
- Module:Val/units • Module:Val/units/sandbox • different (diff)
Johnuniq (talk) 23:04, 12 February 2026 (UTC)
Making this available in other languages
[edit]Can this template be added to other languages like dutch? I see it is available in English since ages but the editors in dutch wikipedia are still manually formatting every number with sticks and stones (dashes and dots).
The page source seems not the real code, only a reference #invoke:val|main, and copying this does not work. Does the actual code file need to be placed on a wikipedia server somewhere, or how do we get this essential function into Wikipedia more broadly than just English?
The table alignment template is also missing, it has to be manually done for every cell in a table. This template also is not a normal source page but a reference to a .css file that I assume regular users can not place on the server. Maybe an admin who sees this can copy that one over too (or make it usable on all of wikipedia instead of duplicating code). (Update: this part is resolved with the help of ItsNyoty.)
80dot171dot93dot89 (talk) 10:04, 17 February 2026 (UTC)
Volts per metre?
[edit]Is it possible to add V.m or similar, linking to electric field? I've found it in dust devil.-- Carnby (talk) 13:35, 11 April 2026 (UTC)
- The wikitext in the article is
{{val|10000|ul=volts per metre|fmt=commas}}. All val is doing to putting a comma in10000and adding the text "volts per metre" as a wikilink. Since there is an article with that name, the link is blue. Replace the wikitext with what is wanted, namely:10,000 [[Electric field|volts per metre]]→ 10,000 volts per metre Johnuniq (talk) 04:05, 12 April 2026 (UTC)- I meant to use the SI symbol V‧m in {{val}} linking it to electric field.-- Carnby (talk) 13:11, 13 April 2026 (UTC)
- Why not use the wikitext given in my last comment? Replace "volts per metre" with whatever is wanted. It is linking to electric field. The time to think about adding a unit to val is when a dozen articles need the same thing. Johnuniq (talk) 07:23, 14 April 2026 (UTC)
- I tried this workaround:
10,000{{sp}}[[Electric field|{{Abbr|V‧m|volts per metre}}]]- yielding
- 10,000 V‧m
- Does it look good?-- Carnby (talk) 10:13, 14 April 2026 (UTC)
- Ah, I didn't realize an abbreviation was wanted. It looks good but there are two issues. First, the dot in
V‧mis U+2027 Hyphenation Point. Units looking like that normally use U+00B7 Middle Dot. Second, V·m would be read as "volt metre" where the dot indicates multiplication like N·m (Newton-metre). An electric field is V/m (volts per metre). Johnuniq (talk) 11:12, 14 April 2026 (UTC)
Done-- Carnby (talk) 12:00, 14 April 2026 (UTC)
- Ah, I didn't realize an abbreviation was wanted. It looks good but there are two issues. First, the dot in
- Why not use the wikitext given in my last comment? Replace "volts per metre" with whatever is wanted. It is linking to electric field. The time to think about adding a unit to val is when a dozen articles need the same thing. Johnuniq (talk) 07:23, 14 April 2026 (UTC)
- I meant to use the SI symbol V‧m in {{val}} linking it to electric field.-- Carnby (talk) 13:11, 13 April 2026 (UTC)