Template talk:Val/Archive 6

Archive 1

←

Archive 4

Archive 5

Archive 6

Archive 7

Link support for B, kB, MB, GB, and TB

Hello. This looks like an anomaly to me. Parameter |ul= with MB/s is supported with a reasonable link, but MB just points to a disambiguation page:

• 25.4 MB/s → {{val|25.4|ul=MB/s}} → Data rate units#Megabyte per second
• 25.4 MB → {{val|25.4|ul=MB}} → MB and not → Megabyte

Could this be easily rectified for B, kB, MB, GB, and TB? Best wishes. RobbieIanMorrison (talk) 19:45, 2 January 2017 (UTC)

@RobbieIanMorrison: I fixed that, thanks for reporting the issue. The problem with MB is that it is not a defined unit so there is no defined link and val just links what it is given to produce [[MB]]. I don't think it is worth adding MB unless several articles really need the features of val—why not use simple wikitext like:

12.3 [[Megabyte|MB]] → 12.3 MB

If val is wanted, it is always possible to define the unit:

• {{val|12.3|u=[[Megabyte|MB]]}} → 12.3 MB

Val might be wanted if there is a need to have sortable tables with a mix of B/MB/GB units. Please link to an example if that is needed.

Examples showing the defined "bytes per second" units:

• {{val|12.3|ul=byte/s}} → 12.3 byte/s
• {{val|12.3|ul=kB/s}} → 12.3 kB/s
• {{val|12.3|ul=MB/s}} → 12.3 MB/s
• {{val|12.3|ul=GB/s}} → 12.3 GB/s
• {{val|12.3|ul=TB/s}} → 12.3 TB/s

Hmm, that first link is not very good. Johnuniq (talk) 23:10, 2 January 2017 (UTC)

Hello Johnuniq. Thanks for the quick answer. I missed the wikilink inside the template trick for parameter |u= when I first read the documentation. But I see it now! I would have thought that it is worth handling MB and friends. I can only point the article I just edited which uses 12.3{{nbsp}}[[Megabyte|MB]] as you suggest. My main motivation was for completeness rather than desperation. Best wishes. RobbieIanMorrison (talk) 23:47, 2 January 2017 (UTC)

Support for explicit number of trailing significant digits

There are times when the number of trailing significant digits cannot readily be given through the input value string to template val. Would it be possible to support a parameter specifying this? I'm thinking of is where the parameter is generated, e.g. via #expr, which deletes trailing zeros. Or better: is there some way to force #expr's output on the round operation to include zeros to the specified rounding precision? —Quondum 18:54, 4 February 2017 (UTC)

Discussion

Any chance of example input and desired output, and the context where this would be useful? If using #expr, there may be a template that can be wrapped around the #expr to produce the desired digits. If not, perhaps there should be—that would be more general than adding something to val. Johnuniq (talk) 00:46, 5 February 2017 (UTC) Example input: |1=1.256e-5|least=-10, output 1.25600×10−5 ('least' refers to the exponent for the least significant digit). The example where this is needed is in trying to code up {{physconst}}, which provides a rounding option for which the output semantics are precision implied by the number of digits. The value produced by #expr may have an 'e' notation exponent, which val conveniently understands. I was wondering whether this kind of mapping might naturally live in val. Rounding being implied (e.g. |1=1.256e-5|least=-6 produces 1.3×10−5) would also be good. Alternative solutions such as your suggested template are also good. —Quondum 01:45, 5 February 2017 (UTC) OK, I'll digest that and should reply here in a day or two. Ping me if I forget. Johnuniq (talk) 03:07, 5 February 2017 (UTC) What should happen if the input precision is too high? Omitting the fancy formatting, would input value 1.23456789e-5 give 1.2345789e-5 or 1.23457e-5 as the result? The first option keeps all the input digits, while the second rounds them. Johnuniq (talk) 03:38, 5 February 2017 (UTC) A general "sensible" option (least confusing it the template user, since the precision is explicitly given with the 'least' value) would round the value (your second case; I did anticipate this in my comment above ). When #expr is used, the input precision could be phony, too. In the particular use envisioned, rounding would be particularly useful, since it would remove the need to round it ahead of time as is now being done. —Quondum 03:52, 5 February 2017 (UTC) On second thought, another sensible (possibly preferable) option is to report an error rather than to stretch the template to rounding (given that this is a display formatting template rather than a calculation template), namely when dropped digits are nonzero. It is easy to perform the rounding operation on the parameter using #expr. Another case to consider is when least > e (e.g. {{val|10.00|least=1}}), which could/should be flagged as an error. —Quondum 16:44, 5 February 2017 (UTC) Error checking is good but I'm reluctant to tell an editor it is an error to enter more sig figs than are displayed. Val supports sortable=on—in fact, that is the default which means a hidden sort key is part of the output. It is rarely used, but {{convert}} allows the input value to be rounded, while the original (unrounded) value is used to generate the sort key. For example, a source might say "1.2345" but only "1.23" is wanted in the text. The general principle is that the template will do what it's told rather than imagine what the editor wanted. I've been wondering about the parameter. The proposal is (for example) to use least=-3 but that interacts with the e exponent so both val and the editor (and people looking at the wikitext) have to ponder what least=-3 actually means. Why not round=3 or decimals=3 to mean that three places after the decimal point will be displayed regardless of whether there is an exponent. {{val|1.23456|round=3}} → 1.235 {{val|1.23456e-5|round=3}} → 1.235×10−5 {{val|1.2|round=3}} → 1.200 {{val|1.2e-5|round=3}} → 1.200×10−5 Perhaps decimals=3 would be clearer than round=3 when zero padding. Is there a reason for wanting least=-3? Johnuniq (talk) 02:50, 6 February 2017 (UTC) As you describe it is fine, with a caveat (first bullet). My choice of name was bad, though the semantics I meant were straightforward, being least significant digit relative to the units position of the expressed value, rather than of the significand, due to an unpredictable and uncontrollable output format from #expr:, e.g. |1={{#expr:1e4}} becoming |1=10000. If you use a round parameter, I feel val must reject an e in the first parameter to avoid uncontrolled ambiguity, while still allowing |e=. Entering more significant digits than are displayed: I have no real preference here. I think this should be dictated by what you consider to be the cleanest semantics for the val template. If rounding is considered to be a natural aspect of this template, then provide that rather than an error message. The sort key approach that you describe is reasonable (the sort order should not be affected by the display choices). the template will do what it's told rather than imagine what the editor wanted: I'm an enthusiastic supporter of this principle, but we need to make sure there is no ambiguity/uncertainty. Hence either my semantics or rejection of e in the first parameter when the new parameter is present. There still seems to be a case that you have not considered. What about {{val|1234.5|round=-2}} → 1200? Should val allow it, with the inherent ambiguity in the meaning of the displayed value (how to tell whether the trailing zeros are significant?), or disallow it? In all, just be aware that the semantics of the first parameter are subtle, but must be unambiguous. In particular, we must be clear on when the semantics of the string include or do not include precision and explicit exponent information. If there are possibly circumstances where an editor has little control of these details (e.g. in #expr: output), they should be ignored. —Quondum 05:04, 6 February 2017 (UTC) If val allows e in the first parameter, here is an example to ponder: should "round" have the same meaning as in #expr:? {{#expr:1.2345e-30 round 32}} → 1.23E-30 Which is to say, should the following produce the same result? {{val|{{#expr:1.2345e-30 round 32}}}} → 1.23×10−30 vs. {{val|{{#expr:1.2345e-30}}|round=32}}{{val|1.2345e-30|round=32}} → 1.23×10−30? I'd say yes. Otherwise it will be confusing. With an explicit |e= parameter present, this is less clearcut. —Quondum 02:45, 7 February 2017 (UTC) I suppose so (I assume your second example was intended to be {{val|1.2345e-30|round=32}}). I was wondering if decimals=2 might be ok like this: {{val|1.2345e-30|decimals=2}} → 1.23×10−30 Unfortunately real life means I will have to delay implementing this. I intend getting on to it as soon as I have some clear thinking time. Johnuniq (talk) 03:00, 7 February 2017 (UTC) Most important: there is no rush; this would be nice, but on an if-and-when basis. Until you are comfortable that the semantics are settled, rather do not implement anything. I'd have preferred to have had additional opinion from others as well. You're right: I've fixed the example. Your decimals suggestion falls apart in certain edge cases where the value is calculated using #expr:, which is the context that motivates rounding in the first place. For example, {{#expr:0.000100}} → 0.0001, but {{#expr:0.000099}} → 9.9E-5, which causes decimals to refer to digits in the result that differ by many places. Your suggestion with |decimals=1 would lead to 0.0 and 9.9×10−5 respectively. Thus, if you want to implement decimal as you suggest, the entire |1= would have to be treated as significand when |decimal= is present; either {{val|2.41235e3|decimal=1}} → error (no e permitted in first parameter) or as {{val|2412.35|decimal=1}} → 2412.3 and allow double-e {{val|2.41235e3|decimal=1|e=-20}}, interpreted as {{val|2412.35|decimal=1|e=-20}} → 2412.3×10−20. I prefer the error option in this instance. —Quondum 05:44, 7 February 2017 (UTC)

Request withdrawn: there is a better way to achieve this in the context where I needed it. For example, replace {{val|{{#expr:1.2985round2}}}} → 1.3 with {{val|{{decimals|1.2985|2}}}} → 1.30. —Quondum 01:00, 10 February 2017 (UTC)

Hmm, I should have looked for {{decimals}}. Useful! Let me know if something is needed with val. Johnuniq (talk) 04:54, 10 February 2017 (UTC)

Excessive disambiguation

In the example {{Val|11|ul=kg.m|upl=s-2}} → 7002107873150000000♠11 (kg·m)/s⁻², where the numerator of the units does not contain a division (only multiplications), parentheses around the numerator are superfluous as there is no ambiguity, but they do produce visual clutter. Shouldn't Val refrain from adding parentheses in this context? —Quondum 21:10, 10 February 2017 (UTC)

The parentheses may be redundant but they seem to clarify the intention. The following shows fixed wikitext with and without the parens for a comparison (this is from one of the test cases).

• {{val|1|u=kW.h|up=s}} → 1 (kW⋅h)/s
• {{val|1|u=kW.h|up=s}} → 1 kW⋅h/s

Units like these may not get much use and I'm not sure what val did before the module was introduced in August 2015, but I think the old template gave the same parens. Any opinions? Johnuniq (talk) 01:44, 11 February 2017 (UTC)

That the editor's intent (when using |upl=) is to highlight the original units in a ratio is a poor assumption; it might simply be hyperlink a portion of a compound unit, for example. For conversions and formatting purposes, I feel that it makes far more sense to consider a future consistent parsing of arbitrary but sensible unit combinations such as {{val|1|u=J.kg-1.K-1}} → 1 J.kg-1.K-1 (Entropy) and {{val|1|u=V.s/(A.m)}} → 1 V.s/(A.m) (Magnetic constant). For linking portions of a compound unit, the |ul=/|upl= distinction is also crude and limiting; a notation such as {{val|1|u=[[Gray (unit)|Gy]].[m]/(A.[s]2)}} is easy to specify and understand, is more versatile and supports the current functionality.

This is not a feature request; I just want to caution against assigning marginal semantics, which your assumption of an "intention" is doing. —Quondum 03:02, 11 February 2017 (UTC)

Support for barn (unit)?

I just realized that

{{val|10|ul=pb}}

Yields 10 pb, rather than 10 pb. These units (and their inverse, like 10 fb⁻¹) are routinely used in nuclear and particle physics. We certainly don't need the whole gamut of SI prefixes, but barns, milli/micro/nano/femto/pico barns and their inverse should all be supported. Headbomb {t · c · p · b} 15:42, 28 June 2017 (UTC)

The unit pb was not defined, so the text as entered was used. That is, ul=pb meant [[pb]] would be used for the link.

I just defined all the Barn (unit) units so the above will work now. That is, it will link to Barn (unit). By the way, there was already a "per barn" unit defined—see the first example following.

• {{val|123|ul=fb-1}} → 123 fb⁻¹
• {{val|123|ul=b}} → 123 b
• {{val|123|ul=Mb}} → 123 Mb
• {{val|123|ul=pb}} → 123 pb

Johnuniq (talk) 02:32, 29 June 2017 (UTC)

How to preview Template:Val/list while editing Module:Val/units ?

Moved from Module talk:Val/units

 – * Pppery * _{it has begun...} 15:49, 11 October 2021 (UTC)

To use template {{val}} within the {{Infobox}} of article Samsung Galaxy S8, I have quickly added many units as bits, bytes, kB, dpi...

But to check my understanding I published my change, and then published many times erroneous content, sorry.

I do not know if my latest version is correct because Template:Val/list does not seem to be updated :-/

Please review my changes and for next time tell me how to preview Template:Val/list while editing Module:Val/units.

I have (at least) three issues in my change:

1. The unit kbit is 1000 times bit and Kibit is 1024 times bit.
   Representing the scaling factor of kbit or Ybit is easy, it is SI.
   But how to represent the exact scaling factor of Yibit?
   How to specify that Yibit is 2⁸⁰ times bit? (or 1024⁸ times bit?)
   I have filled the approximation 1.2e24 times bit but such approximation is not acceptable from my point of view.
2. The unit pixel is often abbreviated px but abbreviation of Megapixel is MP.
   But that later should be Mpx depending on SI.
   As far as I know, pixel is never abbreviated P and Megapixel is never abbreviated Mpx.
   How to handle this usage?
3. The picth is the distance between two pixels (or between two dots).
   There are related units that count the density of pixels (or dots) within one centimetre and also within one inch.
   The relation is the same as for the units Hz and second, one is the inverse of the other.
   How to specify this relation in Module:Val/units?
   (this is to {{convert}} from one unit to the other)

Thanks
--Oliver H (talk) 19:48, 9 July 2017 (UTC)

picth or pitch?

As for your other questions, I wouldn't bother worrying about pixel/megapixel. I'm hard pressed to come up with a context for kilopixel, and we aren't going to see terapixel in our lifetimes. So leave megapixel and (potentially) gigapixel as words by themselves, don't try to make prefixes fit. And frankly, I wouldn't bother with the binary units; they only apply to main memory, and frankly don't need relationships. Tarl N. (discuss) 00:33, 12 July 2017 (UTC)

I don't have the energy to examine all this at the moment. Perhaps later. I suspect that examining the wikitext of Template:Val/list (and WP:PURGE) would throw some light on how it works—I only recall that it uses some feature I added. That list is a bit large and I would be inclined to edit Special:MyPage/sandbox and enter some test wikitext with val templates that I hoped would work. Use {{val/sandbox}} to test Module:Val/units/sandbox. While editing that module, put the sandbox title in the Page title box under "Preview page with this module", then click Show preview. That shows what the sandbox would look like if the changes to the module were saved. For my sandbox, I would enter User:Johnuniq/sandbox as the title.

In convert, a pitch is a micrometre and can be converted to dots per inch, example:

{{convert|1000|pitch}} → 1,000 μm (25 DPI)

Some background can be seen at Dec 2013 and Jan 2014.

I agree with Tarl N. Is there a need to add stuff? I would want to see examples of how new features would be used in articles. Extensive WP:MOS discussions have declared that mebibits and friends are gobbledy gook that should only be used where really needed (and only if backed by common usage in reliable sources). Possibly that old discussion has been updated and I missed seeing seeing it, but I don't think so. Johnuniq (talk) 05:18, 12 July 2017 (UTC)

I notice the comment about the binary units being invalid has been removed from the table. I'm concerned about this because there seems to be some level of consensus that these don't even belong in the table, and the values are simply wrong. At the Ti and above level they are given single-digit precision in base 10, and in the case of YiB, actually incorrect (9.6714E24 is not correctly represented by 9E24). Either way, the whole point of the binary units is to be precise representation of powers of 2, not approximations of powers of 10.

Can we remove those entries from the table? Tarl N. (discuss) 02:47, 14 July 2017 (UTC)

I would be inclined to restore Module:Val/units to how it was on 29 June 2017 (diff of edits since then). For one thing, it is not desirable to expand this module indefinitely with things that might be useful because that would make it unmanageable—it is very hard to work out whether a particular unit is used, so pruning units at some future time would be difficult. There is a discussion here (and at convert) that Oliver H started, but with no response to issues raised. Where would these new units be used? What is an example of how would they be used? I ask that because there is no need to define a unit that is wanted a couple of times. Examples:

• {{val|12|u=widgets}} → 12 widgets
• {{val|12|ul=widgets}} → 12 widgets
• {{val|12|u=[[Example|widgets]]}} → 12 widgets

It would be better to use Module:Val/units/sandbox and use {{val/sandbox}} in an article to illustrate the idea. Then a discussion could decide if the proposed changes were desirable. As I mentioned, there have been MOS arguments about mebibytes and friends, and splashing them in articles would not be desirable if my MOS recollection is correct. Johnuniq (talk) 04:12, 14 July 2017 (UTC)

Thank you for your answers. Yes it is pitch (not picth). Syntax {{val|12|u=[[Example|widgets]]}} was not obvious for me. This is the reason why I have originally added units like bit, byte, Kbit, kB... MP, GP... I think these units shall be supported by {{val}} and {{convert}} but if I am alone, I would not insist. I have just removed mebibits and friends, but I am not motivated to remove all other units I have added. Some units as kbit/s have been added by other people (I have just extended and simplified their representation). The {{convert}} is interesting when displaying values in units as dpi or dpcm. --Oliver H (talk) 06:44, 15 July 2017 (UTC)

I have finally had time to examine the recent edits. Defining units may be a bit more tricky than it appears. Any future work should occur in Module:Val/units/sandbox and should be tested with {{val/sandbox}}. After finding a couple of problems with the recent edits I decided to revert them as requiring more planning. Examples of problems:

• {{val|1|u=byte/s}} → 1 bit/s
• {{val|1|u=kbit/s}} and {{val|1|u=kB/s}} had the same sort key (the latter should be 8 times larger)

Also, please do not add units that might be useful. There probably is no need for the unit, and more of them just makes clutter and overhead. Johnuniq (talk) 04:54, 27 July 2017 (UTC)

Proposed new units

Some additions to the units supported by val have been proposed at the module talk. The discussion started as a question about the modules, but now many new units such as Kibit have been added so anyone interested might like to comment. Johnuniq (talk) 04:09, 14 July 2017 (UTC)

minor unit issues

I notice that the units string H.m-1 yields middot instead sdot, whereas all the other units seem to produce sdot. Could this case please be made uniform with the rest?

Also, supporting the input string "kW·h" (using a middot) is pointless; I suggest just removing this. Anywhere it is used will display an error and quickly get fixed (it only needs replacement by the supported string "kW.h"). Supporting nonstandard input string compositions is a slippery slope towards a maintenance nightmare (think in terms of the number of strings supported being exponential in the input variations supported, so root them out before they get established). —Quondum 03:18, 30 October 2017 (UTC)

Thanks, both of those ideas are good, and I agree that it is much better to have a consistent way to input units. I made the edit.

To remind me what this is all about, from interpunct:

• U+00B7 · middle dot = · = · = interword separation.
• U+22C5 ⋅ dot operator = ⋅ = ⋅ = multiplication dot.

Johnuniq (talk) 07:15, 30 October 2017 (UTC)

Perfect, thanks: it now displays consistently in the article that I was editing. I see a quirk with {{convert}} too, but I'll best comment there. —Quondum

Added TemplateData

I added TemplateData for some parameters. I cannot quite test what I did, as the TemplateData information seems to still not be active. I wonder how long time has to pass before it will be active? I did purge Template:Val and Template:Val/doc, with no effect. --Jhertel (talk) 19:43, 17 November 2017 (UTC)

Warnings

When I created the original {{val}}, I used {{FormattingError}} to report errors, which show a big red warning on the page if you make an error. I believe the port to LUA may have remove that in favor of another smaller, dark blue error message. This new error message is very hard to notice. Subsequently, I've seen a lot of editors introducing errors without noticing, especially when making a large number of changes to a complex page. Can we please start using {{FormattingError}} again so the errors are easier to notice? If not, can we please remove mention of that template from the documentation and delete the template as it would be superfluous? I would do this myself, but I haven't the time nowadays. — SkyLined (talk) 23:36, 30 December 2017 (UTC)

Val can output a warning or an error. If that occurs in an article (or in certain other namespaces such as Template:), the page is added to Category:Pages with incorrect formatting templates use. I look at that category from time to time but have never seen a warning or error in an article. Can you link to an article where there was a problem? Following show a working val, a warning, and an error. Hold the mouse over the warning to see more information ("Val parameter 4 ignored").

• {{val|1|2|3}} → 1+2
  −3
• {{val|1|2|3|4}} → 1+2
  −3
• {{val|1|u=m|ul=m}} →

I could clean the documentation to make that clearer. Johnuniq (talk) 01:15, 31 December 2017 (UTC)

Sorry, I did not know that {{val}} now throws "warnings", but I am referring to them: they are not at all visible enough. The warning I saw was caused by an error on the part of an editor, leading to information missing from the page. The editor forgot to type a |, leading to this:

Correct:

• {{tl|val|4|u=m}} → 4 m

Typo:

• {{tl|val|4u=m}} →

— SkyLined (talk) 08:13, 17 January 2018 (UTC)

Sure, but you used the |nocategory=yes that I had in my example. In an article, that would not be present and I would have seen the error because I monitor the tracking category. As mentioned, I have never seen a problem reported in that category which has surprised me. However, the category works so my conclusion is that errors are rare and are corrected by page watchers before I notice. There does not seem to be a problem. Johnuniq (talk) 08:29, 17 January 2018 (UTC)

I am fully aware of Category:Pages with incorrect formatting templates use because I created it myself :). It was design specifically to be able to detect errors created by sloppy editors. I have been monitoring it from day one and frequently fix any mistakes editors do not appear to notice and/or fix themselves. This is how I found the example above.

I created the big red error messages so editors would notice any mistakes immediately and could correct them themselves. The category was intended as a fail-safe in case editors missed their mistakes - it was not intended as the main way to address such issues. These small blue warnings make it harder for editors to notice their own mistakes, and appear to offer no benefit over the big red errors, so IMHO they should be removed and replaced with big red errors. — SkyLined (talk) 14:25, 17 January 2018 (UTC)

Someone just proved my point with this edit - SkyLined — Preceding unsigned comment added by 62.45.240.92 (talk) 07:35, 20 January 2018 (UTC)

If you are thinking that was a one-off, here's another edit where the editor did not notice the warning. — SkyLined (talk) 08:25, 7 February 2018 (UTC)

As prompted at Module talk:Val#Replace warnings with errors, I updated the module to always show an error rather than a warning. Examples:

• {{val|1|2|3|4}} → 1+2
  −3
• {{val|1.2e6|unit=m}} → 1.2×10⁶

Previously I had not seen any errors in the tracking category and my experience from monitoring {{convert}} is that gnomes often do not notice errors so the strategy of doing as little damage to the article seemed warranted. However, if problems are as rare as I claim, it won't matter if big red messages are used so I'm happy to try the change and see if any other views are expressed. Johnuniq (talk) 00:24, 15 February 2018 (UTC)

I understand your desire not to damage the article aesthetically with a big red warning, but I think risk of having potentially incorrect information on the page without a very obvious warning outweighs this. I haven't monitored {{convert}} myself, I just track when pages are added to the error category: in my experience such errors get fixed by the editor that created them almost immediately 99% of the time. The warnings were the exception to this. Let's see how things go with this change for a bit; let me know if you find that it doesn't work well for you. — SkyLined (talk) 08:10, 15 February 2018 (UTC)

I wasn't aware that you have been monitoring the tracking category and that would explain why it's been empty when I looked. Johnuniq (talk) 08:30, 15 February 2018 (UTC)

Well, I created it specifically so I could monitor if people were making mistakes. You can use the RSS feed to see when stuff gets added/removed in real time :) — SkyLined (talk) 12:57, 15 February 2018 (UTC)

Hearts?

And now a question from someone with inadequate coding skills: What does Template:Hearts have to do with Template:Val documentation, or, that is, why is Template:Hearts being called in the wikitext below (which is what I see when I click "View source")? And why might Template:Val need this but Template:Gaps not need it?

<includeonly>{{{{{♥|safesubst:}}}#invoke:val|main}}</includeonly><noinclude> {{documentation}} </noinclude>

Thanks. Quercus solaris (talk) 20:16, 24 February 2018 (UTC)

It's a parameter, not a template, so Template:Hearts is not involved. See Template talk:Val/Archive 5#Template:♥. The trick is only required if subst: is used when a reasonably complicated template is called, and the ♥ is only required to prevent junk being displayed with a call like {{subst:val|123|2|3|=done}} (the =done is junk which sets a parameter to have the value "done"; the parameter name is an empty string). Johnuniq (talk) 00:05, 25 February 2018 (UTC)

Replace warnings with errors

Moved from Module talk:val

 – * Pppery * _{it has begun...} 15:44, 11 October 2021 (UTC)

I plan to remove all warnings and replace them with errors as discussed here unless someone can provide a good reason not to. In short: these warnings are often overlooked by editors, which cause the pages in which they are introduced to contain incorrect information until somebody notices and fixes it. Over the past few weeks this has happened about once every two weeks and it can take up to a week for somebody (other than me) to notice and fix it. By replacing these hard-to-notice warnings with clearly visible errors, I expect editors to detect and fix their mistakes themselves almost immediately and prevent Wikipedia from having incorrect information up to half the time. Unfortunately, I have little time at the moment and no working knowledge of LUA, so I cannot commit to a date for this change at this point. If you are able to make this change, I would appreciate if you would go ahead and do so at your earliest convenience. — SkyLined (talk) 11:06, 14 February 2018 (UTC)

I made the change to the module so it will now always show errors. See my new comment at Template talk:Val#Warnings. Johnuniq (talk) 00:24, 15 February 2018 (UTC)

Thank you! — SkyLined (talk) 07:58, 15 February 2018 (UTC)

Narrow Non-Breaking Spaces?

Unicode &#8239; for Narrow Non-Breaking Spaces is now well-supported by browsers. This is typographically a better option than &nbsp; (&#160;) whose spaces look too wide for digit grouping and for separating digits from unit abbreviations. https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Dates_and_numbers#Numbers currently says "Digits should be grouped and separated either by commas or by narrow gaps". What do people think about changing the Val template to use &#8239; characters which are narrow gaps? Testing:

8876 generated by 8876

8,876 generated by 8,876

8 876 generated by 8&#160;876

8 876 generated by 8{{nbsp}}876

8 876 generated by 8&#8239;876

8 876 generated by 8{{nnbsp}}876

Jaa101 (talk) 04:37, 15 March 2018 (UTC)

See also: Talk:Convert#Narrow non-breaking spaces?.

Val does something much more clever than using spaces. Try putting the following into Special:ExpandTemplates:

• {{val|12345678.901234}} → 12345678.901234

The benefit is that selecting the output in a browser and copying the text will copy it as a number ("12345678.901234" with no gaps). Try copy/pasting the above examples. Johnuniq (talk) 05:09, 15 March 2018 (UTC)

Lousy typing support

Could this template support this input improvement?

12 x 12 m3 → 12 x 12 m3, making →

12&nbsp;&times;&nbsp;12&nbsp;m<sup>3</sup>

→ 12 × 12 m³

It is about keyboard input into well-formatted MOS output. -DePiep (talk) 01:03, 18 March 2018 (UTC)

Unwanted leading + on exponent

A nice thing about acepting e notation is that the output of {{#expr:}} can be fed straight into {{val}} for pretty-printing. However, there's one little issue:

{{Val|{{#expr:2^64 round -13}}}} → {{Val|1.844674E+19}} → 1.844674×10⁺¹⁹

Is there an easy way to get rid of that ugly + sign in the exponent? Do I have to use {{#invoke:String|replace|{{#expr:...}}|+}}? 23.83.37.241 (talk) 07:06, 3 May 2018 (UTC)

Sorry but val inserts the + if it is present in the input, because that gives the user control.

• {{val|1.23E45}} → 1.23×10⁴⁵
• {{val|1.23E+45}} → 1.23×10⁺⁴⁵

Johnuniq (talk) 07:19, 3 May 2018 (UTC)

@Johnuniq: I'm not objecting to the default, just wondering if there's a non-default mode. As I said, using the output of #expr: seems like a use case worth accomodating. E.g. has anyone already written a {{valexpr}} template under a name I havent guessed? 23.83.37.241 (talk) 07:37, 3 May 2018 (UTC)

I believe not. You might get some ideas at WP:VPT. Johnuniq (talk) 07:47, 3 May 2018 (UTC)

@Johnuniq: Thanks! I was halfway through writing something there when I found {{scinote}}, which does exactly what I want. It doesn't have {{val}}'s nice units and tolerance formatting, but I don't need them for the particular case I ran into. {{scinote|1.23E+45}} → 1.23×10^⁴⁵ 23.83.37.241 (talk) 08:36, 3 May 2018 (UTC)

Amazing. I added it to "See also" on this template page. Johnuniq (talk) 08:48, 3 May 2018 (UTC)

Damn, you won the edit conflict! :-) 23.83.37.241 (talk) 08:50, 3 May 2018 (UTC)

Comma as decimal separator

Hello, I'm from de.wikipedia and have copied the module val. It functions quite well there but in German (and Italian,...) Wikipedia the decimal separator should be a comma. What lines must be changed to adapt only the output, so that {{val|2.44|u=kg}} is displayed as 2,44 kg? --Nov3rd17 --Nov3rd17 (talk) 12:10, 23 June 2018 (UTC)

@Nov3rd17: I can fix that but there is the potential for a lot of confusion. The above says that input 2.44 should be displayed as 2,44 – do you really want that? That suggest all numbers in wikitext use en formatting so 1.234 is a bit more than 1, whereas 1,234 is over a thousand. That is unlikely to be true at dewiki!

What about the group separator? At enwiki, 1,234,567.89 is over a million and the commas are removed by val before trying to interpret the number.

I would have thought dewiki would use 1.234.567,89 for that number in the wikitext and would want it formatted in the same way for output. However, val defaults to use a small space as the group separator (it does that in a clever way using HTML so copying a number like 1234567.89 omits the spaces). Should spacing be used for the group separator at dewiki by default, with an option to show dots instead? Johnuniq (talk) 01:26, 24 June 2018 (UTC)

Is there a way to show values on 2 lines?

Specifically something like:

1,234
±567

Nergaal (talk) 16:27, 20 July 2018 (UTC)

No, I'm afraid not. There's not a great deal of benefit from using val for a smallish number like 1,234 with ± uncertainty. Val can insert gaps in long strings of digits and can show upper/lower uncertainties, but ± is easily handled in simple wikitext such as the 1,234<br>±567 you used above. Johnuniq (talk) 00:08, 21 July 2018 (UTC)

Thin space

Thin spaces for use with SI number formatting are represented via this template as a quarter of an em (incorrect) rather than a fifth of an em (correct). Excelsiorsbanjo (talk) 18:27, 6 September 2018 (UTC)

Do you happen to have a source for this claim? Note that {{val}} currently conforms to the Manual of Style AFAICT. If you believe this is not the case, it should be fixed here. However, if the output adheres to the MoS but you believe the MoS is incorrect, you should take the discussion there. — SkyLined (talk) 20:56, 6 September 2018 (UTC)

This spacing is not directly addressed at MOSNUM, so conformance and nonconformance both are likely technically impossible at present. It does indirectly address it, however, in the WP:MOSNUM#Grouping_of_digits section (under 'Grouping with narrow gaps'), where it correctly refers to utilizing (screen reader issues aside) a thin space, as specified by the SI Brochure. A thin space as defined by our own article, web browsers (which implement the character), and just about any source you will find is a fifth of an em, not a quarter. Excelsiorsbanjo (talk) 01:46, 7 September 2018 (UTC)

Well, technically our own article says *usually* ​1⁄5 or ​1⁄6 of an em in width but there do not appear to be any sources that mention 1/4 so it appears this is a mistake. I agree that it should be changed.

I might be able to make this change myself as I wrote the original template years ago but I've not looked at the new Lua implementation so it would take me a while to figure out where to make this change without breaking things. (From a quick glance it looks like the code is not currently using a Unicode thin-space but adding empty HTML <span> elements with a 0.25em width, which seems overly complex. I don't recall having that in my original code but I'm guessing there is a good reason for this. However, I can't think of any and there's no documentation that explains it. I've asked a question on the Module:Val talk page about this. — SkyLined (talk) 08:16, 7 September 2018 (UTC)

The gaps are the way they are for compatibility with {{gaps}}. There is no   in the output; instead, tricky html is used to provide visual gaps for screen readers and so that copying the text does not include gaps. Following are two examples with the results from Special:ExpandTemplates shown below that.

123456789012 ← {{gaps|123|456|789|012}}

123456789012 ← {{val|123,456,789,012}}

{{gaps|123|456|789|012}}
<span style="white-space:nowrap">123<span style="margin-left:0.25em">456</span><span style="margin-left:0.25em">789</span><span style="margin-left:0.25em">012</span></span>

{{val|123,456,789,012}}
<span class="nowrap"><span style="display:none" class="sortkey">7011123456789012000♠</span>123<span style="margin-left:.25em;">456</span><span style="margin-left:.25em;">789</span><span style="margin-left:.25em;">012</span></span>

The outputs from gaps and val are very similar. See Template talk:Gaps#Width of the spaces for other opinions. If a discussion here decides a change is wanted, consensus from a wider group should be obtained. That should occur at the talk page of MOS:DIGITS which says that gaps should be used, not any kind of space. Any change would be to gaps and val but would be a simple edit in the the two modules (see "function delimit" in Module:Val). {{convert}} would also have to be changed to match. Johnuniq (talk) 09:42, 7 September 2018 (UTC)

Here is the relevant text of the 9th CGPM: https://www.bipm.org/utils/common/pdf/CGPM/CGPM9.pdf#page=70 As far as I can tell it does not mention a "thin space" explicitly as the supposedly translated-from-the-French English text does, which is bafflingly disappointing. You can tell, however, from this reproduction and those of other years that the intended width of the space (at least as implemented by the authors of the time) was incredibly thin indeed (the OCR is not great for these PDFs, but if you search for '000' you will find numerous examples of large numbers with digits grouped in threes), and that the intent was clearly for the spacing to be thinner than as used between regular words. As for a general comparison alone, the numbers as formatted by this template are incredibly hard to read, IMO, because of the quite large spacing, but the numbers as formatted in the CGPM documents from around 1948 (9th CGPM) until fairly recently, with their thinner spacing, are far more readable. Excelsiorsbanjo (talk) 00:22, 10 September 2018 (UTC)

Link from uncertainty part

When I first saw a number with uncertainty on the form 1.357543(20), I did not understand what that "(20)" meant. Even though I studied math in my engineering studies some decades ago, I don't remember seeing that notation. After looking at the citation I found out what it meant, but I wanted to add a link from the "(20)" part (the uncertainty part) to an article about uncertainty so readers can easily click that to learn the notation and read more about uncertainty and different notations for it. But as the number with the uncertainty was created with this template, that was easier said than done. I don't think there is a way to do that with this template, is there? The problem is vaguely similar to linking from units; it shouldn't always link, to prevent overlinking. But I guess it could be solved by adding a parameter that you can give a value for the name of an article that should be linked to from the uncertainty part. Or it could be a boolean parameter whether to link our not to a fixed article about uncertainty. If such a parameter doesn't already exist? --Jhertel (talk) 02:56, 23 November 2018 (UTC)

That is a common way of writing an uncertainty. Not high-school levels of common, so it should usually only be used when the notation is explained elsewhere, or when space if limited. Links like 2.0132(16) or 2.0123(16), would be very confusing. Headbomb {t · c · p · b} 03:34, 23 November 2018 (UTC)

♥

Why does this template use another template ♥? – Sivizius (talk) 01:46, 1 December 2018 (UTC)

Val doesn't use {{♥}}. See Template talk:Val/Archive 6#Hearts? and the longer explanation that points to, namely Template talk:Val/Archive 5#Template:♥. Johnuniq (talk) 02:03, 1 December 2018 (UTC)

Unicode Thin-space

Moved from Module talk:val

 – * Pppery * _{it has begun...} 15:44, 11 October 2021 (UTC)

There is a discussion at the Template:val talk page about the width of the space between digit groups. The module currently uses 1/4em but it seems most external sources suggest using 1/5 or 1/6em. I support this change for that reason. I was looking at how I might implement it when I noticed that the module currently uses an empty <span> element with a 0.25em width to add the spaces. This seems overly complex and the code does not provide a reason for this. If I am correct and there is no good reason, I suggest we replace this <span> element with a Unicode &thisp;. — SkyLined (talk) 08:16, 7 September 2018 (UTC)

I replied at Template talk:Val#Thin space—that's the place to discuss what should happen. Johnuniq (talk) 09:45, 7 September 2018 (UTC)

Contrary to SI-mandated format

The SI guide (NIST Special Publication 811 – 2008 Edition) well-nigh mandates the format for quantities with uncertainties, giving as example

63.2 m ± 0.1 m or (63.2 ± 0.1) m but not: 63.2 ± 0.1 m or 63.2 m ± 0.1

It is essentially impossible to achieve the second recommended example using {{val}} with a unit but without a decimal exponent (with an exponent, parentheses are automatically generated), getting

7001632000000000000♠63.2±0.1 m

7004632000000000000♠(63.2±0.1)×10³ m

I suggest that {{val|63.2|0.1|u=m}} (i.e. whenever parameters 2 and u are both present) should automatically generate (63.2 ± 0.1) m, in line with the SI. I have just added this example to MOS:UNCERTAINTY, so let's see whether it kicks up a firestorm. —Quondum 01:01, 28 February 2019 (UTC)

Thanks for the info but I would hope to see a wider discussion before thinking about changes to the module. If there is no reaction to your MOS edit, perhaps an explicit question could be asked at MOS. Johnuniq (talk) 01:11, 28 February 2019 (UTC)

Yes, that makes sense: any change to the module is a far more serious matter than is a tweak to the MOS, which is easily reversed. I see no rush, but thought it to be worth considering. —Quondum 01:21, 28 February 2019 (UTC)

I feel this template should have "no opinion" and just follow the MoS, so any changes to the output should be based on changes to the MoS. The MoS, like any other Wikipedia page, should follow the outside world and not have an opinion either. In other words, if the SI guide differs from the MoS, please start a discussion there, or make immediate changes there and update {{val}} accordingly. 188.206.73.180 (talk) 08:43, 1 March 2019 (UTC)

Good idea, and that is happening, see WT:Manual of Style/Dates and numbers#Formatting of quantities with uncertainties. Johnuniq (talk) 09:37, 1 March 2019 (UTC)

It seems that there is little appetite at the MoS for my suggestion. Which suggests an alternative. There are contexts in which pedantic SI notation would be appropriate, even in WP (typically technical physics articles), and editors should be free to choose to use the notation that is most appropriate. Well, they are, but as the template functions at the moment, one has to work around it to get there. I think it would make sense to have a parameter that allows selection of pedantic SI notation, but I the effort required might not be justified. I saw an example where spacing was messed up to get the parentheses in, which is what prompted this. —Quondum 18:19, 3 March 2019 (UTC)

Localisation

Moved from Module talk:val

 – * Pppery * _{it has begun...} 15:44, 11 October 2021 (UTC)

Hello, I would like to importo this module to it.wiki, but currently there are not localization options like for Module:Convert. I could try to move error message and some formatting options (like the decimal separator) to an external module (Module:Val/locale). Do you think this could be useful or they are reasons (performance Ithaquabe?) not to do this?Moroboshi (talk) 07:53, 3 June 2019 (UTC)

Hi, we talked two years ago about convert. I never got around to providing l10n for val. I like simple stuff—see what I did to Module:Age on 31 March 2019. That was in response to a request I think at my talk which ended up at bnwiki. The point is that there is very little to localize and I don't really want an extra module to fuss with here. However, give it a go if you like. I'm not sure that "locale" is the right name. I temporarily forget what some modules use here, perhaps l10n? Johnuniq (talk) 09:37, 3 June 2019 (UTC)

I just remembered a related issue for dewiki, see Template talk:Val/Archive 6#Comma as decimal separator. I found a local file on my computer where I apparently started work on localization but probably stopped when there was no feedback. I uploaded the file (patched with some recent changes to the main module) to the sandbox, see permalink at 10:34, 3 June 2019. That is not tested. It was to handle numdot + numsep. Perhaps I abandoned it when I realized what a mess converting the wikitext would be. In the discussion at the archive link I pointed out that the example given used an en number for val's input (2.44) but they wanted a de number for the output (2,44). That would quickly cause immense confusion. Johnuniq (talk) 10:43, 3 June 2019 (UTC)

Hi, thankx. I will look into it. I prefer an external module because is simpler to keep files synced across different wiki, but moving all the messages and localisation options to the top of the file could be a also be a solution.--Moroboshi (talk) 10:54, 3 June 2019 (UTC)

Hi. I read the discussion Template_talk:Val/Archive_6#Comma_as_decimal_separator. Currently on it.wiki numbers are formatted directly or indirectly using the magic word formatnum, so the expected input is a number with dot (".") as decimal separator and no group separator. The outuput is a number with nobreaking space ("&amp;"") as group separator and comma (",") as decimal separator. For consistency with the convert module I would like that comma could also be used in input as decimal separator in alternative to dot.

I have uploaded in the Module:Val/sandbox a test version with all the error messages listed in a table at the top of the file. It pass all test in Template talk:Val/testcases except for 27 cases, but the previous version in sandbox was failing them too. Ithaquabe the expected result should be corrected in the table of test ?

I have also added a test on row 133-135 if numdot ~= '.' then arg = arg:gsub(numdot, '.') end to replace the locale numdot with "." if different from dot. --Moroboshi (talk) 11:40, 6 June 2019 (UTC)

Thanks, that's great work, and you have thoughtfully used the same style that I would. I made a couple of minor changes in Module:Val/sandbox. One strange thing is that something changed "may" to "Ithaqua" in your edits both here and in the module. There is no benefit from using mw.ustring.format rather than plain string.format with %s.
I updated the testcases to show what the current {{val}} does and now Template talk:Val/testcases shows only two differences from the sandbox. They are due to use of &quot; in the sandbox.
I assume the messages used " instead of plain " because valerror replaces all quotes in warnings with ". I think it would be better to use the clear " in the messages and let valerr do what it needs to. There is no problem with overhead because valerror is only called if an error occurs, and that is rare. Further, if an error occurs, additional overhead is immaterial, and would be minuscule.
I wouldn't be surprised if further work is needed somewhere because val can output some strange wikitext. Please let me know how you get on at itwiki. I will update the main module here when you have completed your tests. Johnuniq (talk) 08:15, 7 June 2019 (UTC)

May->Itaqua was caused by a silly addon for Chrome that replace name of politician with old gods from Lovecraft mythos (in this case "(Theresa) May" -> Itaqua). Normally I use Firefox and I have forgot about the addon.--Moroboshi (talk) 11:02, 7 June 2019 (UTC)

I'm happy with the translation table at the top of the module, but we mentioned a possible submodule above. If one were used, the convention appears to be /i18n here. Try editing Angola and look in "Pages transcluded onto the current version of this page" at the bottom for i18n. That shows Module:Side box/i18n (does not exist) and Module:Wikidata/i18n. Johnuniq (talk) 23:55, 7 June 2019 (UTC)

Hello. I'm testing the localization on it.wiki and preparing for the conversions of our old template. Currently I'm translating Template:Val/units and I have a question. Why some units is repeated from Convert, like lbf or year or all the SI table for second or hertz ?Moroboshi (talk) 12:49, 13 June 2019 (UTC)

There are a number of factors. You might like to see how I left Module:Val/units in July 2015 and the documentation in July 2015. Most of my edits to the units and documentation since then have been fixes for problems or for requested additions. Other editors have extensively rearranged the units and added items, and expanded the documentation. Sometimes people have added many units in anticipation of how val might be used—I prefer to keep things reasonably small and add only what is needed but I wasn't going to argue. There is no reason to avoid calling convert, apart from its overhead which should be trivial, so I would favor removing any duplicates. Some of the duplicates might be due to my mechanically converting the units used by the old template (see June 2015) to the module, without noticing that some were not needed. Johnuniq (talk) 07:28, 14 June 2019 (UTC)

Sorting will use data-sort-value

Per a discussion at Template talk:Convert#Switching from hidden sort keys to data-sort-value, {{convert}} is changing the format of sort keys. {{val}} gets its sort keys from convert so val will change as well. The following shows some val templates and the output from Special:ExpandTemplates.

{{val/sandbox|12.34}}
<span class="nowrap"><span data-sort-value="7001123400000000000♠"></span>12.34</span>

{{val/sandbox|12.34|sortable=debug}}
<span class="nowrap"><span data-sort-value="7001123400000000000♠"><span style="border:1px solid">7001123400000000000♠</span></span>12.34</span>

This will be live in {{val}} in due course. Let me know if there is a problem! Johnuniq (talk) 10:41, 21 April 2019 (UTC)

My understanding is that the sort key for ranges is simply the first value of a range. This is not quite correct. The sort key for {{val|400|-|500}} range should be 400 for ascending sort and 500 for descending sort. This is because as the person "scans" across the "line", he/she expects to "intersect" the objects in the proper order, whether these objects are "points" (single number) or "line segments" (ranges of numbers). This will require extension of -data-sort-value to support -data-sort-value-ascending and -data-sort-value-descending, but it will provide truly intuitive sorting in real-world data tables that sometimes only have a range of numbers for certain cells. --46.242.12.2 (talk) 17:41, 3 August 2019 (UTC)

Good point, I've never seen that mentioned anywhere. If there were a significant number of articles where sorting is a problem, there might be reason to look at the issue. I don't know if you are saying ascending/descending are supported by the underlying software, or whether that would also need development. Johnuniq (talk) 23:52, 3 August 2019 (UTC)

return unit name? (not symbol)

Is it possible to have the unit name returned ("second" not "s")? -DePiep (talk) 20:19, 20 September 2020 (UTC)

It's years since I did any substantive work on val so I'm not certain but I'm pretty sure there is no equivalent for {{convert}}'s abbr=off. That is, unit names cannot be displayed. For one thing, the built-in units at Module:Val/units do not define a symbol and name for each unit. It would be possible to define a unit which displayed "seconds" but then there would be no mechanism for that to be singular. Since unknown units are processed by convert, and because "seconds" is understood by convert, {{val|123|u=seconds}} displays "123 s" with a symbol because that is what val normally wants. The principle is that val is intended for scientific work with tricky error bands so the unit symbol is what is appropriate. Also, you can just add the name in wikitext:

• {{val|12345|67|89}} seconds → 12345+67
  −89 seconds

Johnuniq (talk) 03:46, 21 September 2020 (UTC)

Thanks for your patience if this is too "OFF TOPIC" for this section; ... anyone who is familiar with the "{{val}}" template, is welcome to [feel free to] consider this new QUESTION: Module talk:Val/units#Would this (suggested change) be OK?

Thanks! --Mike Schwartz (talk) 18:16, 29 September 2020 (UTC)

I might not get the whole picture, but I'm fine with how this is today. Especially with the Johnuniq reply. -DePiep (talk) 18:58, 29 September 2020 (UTC)

Bits and bytes

I'd like to add bit and byte unit conversions, e.g. between kilobytes and megabytes etc., to Template:Convert. I saw that Template:Val has entries for kB, MB, GB, and TB (but none for or other multiples), as well as a couple of data rates, e.g. Mbit/s. Will we have to move them? I don't quite understand the relation between Val and Convert. Looking forward to your comments at Template talk:Convert#Bits and bytes. Thanks! -- Chrisahn (talk) 11:27, 13 October 2020 (UTC)

uncertainties with triaxial dimensions

How do we format (A×B×C)±y ? I don't see anything in the guideline. I put the uncertainty in the units param, but that's not ideal. — kwami (talk) 00:25, 25 October 2020 (UTC)

An uncertainty parameter only works with a single input. Your solution at 2 Pallas is good. By the way, the unit is repeated when x is used due to WP:UNIT. Examples:

• {{val|568|x|532|x|448|u=±12 km}} → 568 ±12 km × 532 ±12 km × 448 ±12 km
• {{val|568|by|532|by|448|u=±12 km}} → 568 by 532 by 448 ±12 km

Johnuniq (talk) 00:46, 25 October 2020 (UTC)

Thanks. I thought we used to be able to do that directly. Maybe misremembering. — kwami (talk) 00:58, 25 October 2020 (UTC)

Documentation

Is there any reason that the following cases aren't documented by examples?:

• {{val|e=5}} → 10⁵
• {{val|e=5|u=K}} → 10⁵ K

On the other hand, what is the point of:

• .{{val| 1234567.1234567 }}. → .1234567.1234567.

When would that be meaningful and useful? I would be bold and simply change these, but the page is protected. --Macrakis (talk) 21:20, 3 February 2021 (UTC)

I think this feature has been around ever since the first days I worked on this template and I simply forgot to document them and no one noticed. These cases should indeed have been documented already; I support adding documentation for them and appreciate your help in doing so.

{{val}} outputs numbers according to ToS. The spacing in 1234567.1234567 makes it easier to interpret than 1234567.1234567. This is by design and should not be modified. — SkyLined (talk) 22:02, 3 February 2021 (UTC)

At Template:Val, clicking "view" after "Template documentation" goes to Template:Val/doc which is the unprotected documentation. The point of the 1234567.1234567 example is that it documents what val does with numbers. I can't tell if you think the example is unrealistic or whether val should behave differently. If the former, yes, the example is unrealistic, but it briefly shows exactly what val does and should not be changed. Johnuniq (talk) 01:39, 4 February 2021 (UTC)

Thanks, I realized that the doc was unprotected, but somehow my edit saying that got lost....

Re the .{{val| 1234567.1234567 }}. example, what is the point of the surrounding periods? Is it to show where the output of the template begins and ends? If so, perhaps something like ⟨123123⟩ would have been clearer. Also, that example was not marked up the same way as the others, so it appears not to have been added by someone who was familiar with the doc page's conventions. --Macrakis (talk) 16:08, 4 February 2021 (UTC)

The original had spaces before and after the parameter and the periods show that those spaces are trimmed. Johnuniq (talk) 22:27, 4 February 2021 (UTC)

Ah! That wasn't clear to me at all, partly because the surrounding periods are easily confused with decimal points. I've restored the example, using ⟨...⟩ as I suggested above. I'm not sure it's needed, though. It seems like a good test of robustness to user input, but it is a model you're suggesting that users emulate? --Macrakis (talk) 22:47, 4 February 2021 (UTC)

No, excess spaces should not be entered. However if someone were planning, for example, to use val within another template, it would be useful to see documentation showing what happens with strange input. Johnuniq (talk) 22:54, 4 February 2021 (UTC)

unit % (percentage)

It appears that unit "%" is treated differently:

• {val|3.45|(23)|e=2|u=kg} → 3.45(23)×10⁻² kg
• {val|3.45|(23)|e=2|u=%} → 3.45(23)%×10⁻²

A workaround is |s=%

• {val|3.45|(23)|e=2|s=%} → 3.45(23)×10⁻²%

-DePiep (talk) 14:50, 22 April 2021 (UTC)

That's mostly because no one has a need to write (7.54 ± 0.21) × 10⁸%. Headbomb {t · c · p · b} 15:03, 22 April 2021 (UTC)

Could be but why inconsistent? -DePiep (talk) 18:35, 22 April 2021 (UTC)

Because % is defined at Module:Val/units with ANGLE. I forget exactly what that does, but it would be responsible. Johnuniq (talk) 01:10, 23 April 2021 (UTC)

Thoughts on syntax

I've tried applying {{val}} to Solar wind article, and I have the following ideas:

1. Support {{val|e=5|u=K}} or {{val|e5|u=K}} syntax, generating 10⁵ K. This is needed for sentences like "on the order of 10⁵ K". {{val|1e5|u=K}} does not work as it generates 1×10⁵ K.
2. {{val|p=~|300|u=km/s}} (~300 km/s) is too complex for such a simple and frequently used case. Perhaps support {{val|~300|u=km/s}} syntax (as well as ≈ and ±)? The sort key should simply throw away ~/≈.
3. Support {{val|70-85|u=K}} shorthand syntax for {{val|70|-|85|u=K}}. Continue to support verbose syntax for cases like {{val|70|and|85|u=K}}.
4. Support {{val|12-14|e6|u=AU}} shorthand syntax for {{val|12-14|e=6|u=AU}}. This might seem like a minor thing, but taken together with the next point it allows to completely get rid of named parameters in most cases.
5. Support {{val|500|km/s}} shorthand syntax for {{val|500|u=km/s}}.
6. Perhaps add {{v}} alias for {{val}}?

These changes would allow users to write very easy expressions like {{v|500|km}}, {{v|±3|mm}}, {{v|≈30000}}, {{v|20-30|m/s}} when they need non-breaking spaces, proper formatting of big numbers, automatic en dash for ranges, and automatic sort key. Simplicity of use and clarity of syntax will significantly increase the usage of the {{val}} template, which will result in better, more uniform formatting of scientific notation across Wikipedia. --46.242.12.2 (talk) 17:36, 3 August 2019 (UTC)

Thanks but I'm going to be a wet blanket.

1: Use {{10^}}: {{10^|5}} → 10⁵

2: There would need to be hundreds of cases to justify saving the tiny bit of typing involved in using |p=~. The advantage of requiring the prefix p parameter is that it reduces the number of magic ways in which val works. Only a tiny number of editors would ever become sufficiently familiar with val to know that sometimes the prefix could be jammed into the number.

3, 4: The range-handling code is already complex and the proposed wikitext is baffling for most editors. {{convert}} supports that kind of range but I've started removing examples that I find in articles because the tiny saving in typing confuses editors.

5: Val is suprisingly complex and working out that the second unnamed parameter was a unit would need quite of a bit of pointless overhead.

6: {{val}} is somewhat self-explanatory and saving two characters by writing {{v}} is not helpful, particularly for other editors.

Johnuniq (talk) 03:55, 4 August 2019 (UTC)

I also think that the number of situations where this is really helpful is too limited to justify the added complexity. In addition, making it easier to write in this way makes it harder to read because of possible ambiguity. But thanks for the feedback regardless. — SkyLined (talk) 15:52, 6 August 2019 (UTC)

I agree with all of Johnuniq's comments except possibly point 1. There is value in using the template to ensure standard formatting (spacing and nowrap) for 10⁵ K, and I would think that most editors are not familiar with {{10^}} – surprisingly I've only recently learned of it. The only argument that I see working here is the complexity and effort not being justified by the limited number of uses. I would support introducing only one of the two suggested formats: {{val|e=5|u=K}} (e5 is not standard in contexts where 1e5 is). —Quondum 19:02, 7 October 2019 (UTC)

{{val|e=5|u=K}} produces 10⁵ K -- isn't that what you want? --Macrakis (talk) 21:20, 3 February 2021 (UTC)

That was presumably added in the interim. —Quondum 03:21, 4 June 2021 (UTC)

Bug report: Cubic Angstrom not supported

Powers of the angstrom are not supported by default, which is problematic when specifying the unit cell volume in {{Chembox Structure}}.

Wrong: {{val|1215.8|(5)|u=Å3}} → 1215.8(5) Å³

Right: {{val|1215.8|(5)|u=Å<sup>3</sup>}} → 1215.8(5) Å³

Actually, I think that all units should have automatically supported dimensions for such weird things as "m/s³". –LaundryPizza03 (dc̄) 08:47, 14 June 2021 (UTC)

I support this, and it makes sense to try to do this automatically. However, there may issues with linking to Wikipedia articles: there are separate pages for [[Metre per second|m/s], m/s², m/s³ but there is none for ų. Those will still have to be entered manually. Coming up with a reasonable solution may be hard. Suggestions? — SkyLined (talk)

Automatic square/cubic won't be happening, sorry. However, I added Å3 as a unit so the above example now works. Johnuniq (talk) 10:33, 14 June 2021 (UTC)

Won't be happening because it violates some policy, or you know if a reason why it's technically impossible? Or won't be happening if you are the person who has to implement it? I'm not volunteering to do it, just want to know if there's a technical reason or a personal one. — SkyLined (talk)

Tb/s link

{{val|1|ul=Tb/s}} (1 Tb/s) links to Data-rate_units#Gigabit_per_second. Data-rate_units#Terabit_per_second would be more appropriate. ~Kvng (talk) 19:27, 30 September 2021 (UTC)

@Kvng: Clicking your "(1 Tb/s)" link goes to Data-rate units, but at the top of that page it says "(Redirected from Tb/s)". So the fix would be an edit at the redirect Tb/s. Johnuniq (talk) 23:47, 30 September 2021 (UTC)

Resolved

You're right. I fixed it. ~Kvng (talk) 00:54, 1 October 2021 (UTC)

Earth radius

A recent edit by Kwamikagami changed the symbols for Earth mass and radius. Following is an example from Moon#Formation without the refs. Old shows the original symbol, and New shows the correct symbol matching Earth radius, although it is just a smudge on my system.

Old The prevailing theory is that the Earth–Moon system formed after a giant impact of a Mars-sized body (named Theia) with the proto-Earth. The impact blasted material into Earth's orbit and then the material accreted and formed the Moon just beyond the Earth's Roche limit of ~2.56 R_⊕. This theory best explains the evidence.

New The prevailing theory is that the Earth–Moon system formed after a giant impact of a Mars-sized body (named Theia) with the proto-Earth. The impact blasted material into Earth's orbit and then the material accreted and formed the Moon just beyond the Earth's Roche limit of ~2.56 R_🜨. This theory best explains the evidence.

I'm noting this for anyone interested because I think there was discussion about the symbol but I can't find it. Johnuniq (talk) 01:29, 8 October 2021 (UTC)

It might be that we need that substitute symbol ('Old') if the correct character ('New') isn't widely supported. They look somewhat different, and that's not just because they're being displayed with different fonts in my browser. In the Earth symbol, the circle is quartered: the + connects to the circumference. In the mathematical symbol, it doesn't: it's a + enclosed in a circle without contacting it. — kwami (talk) 01:34, 8 October 2021 (UTC)

Old: U+2295 ⊕ CIRCLED PLUS in Mathematical Operators (Unicode block), BMP

New: U+1F728 🜨 ALCHEMICAL SYMBOL FOR VERDIGRIS in Alchemical Symbols (Unicode block), SMP

Looks like the old one has advantages for being more widespread (older U+, lower U+ plane). Being a unitquantity (see below), math form is not unlikely (though it might be taken from alchemy originally).

Also, to me the old one looks larger and so, in sub, more readable. I'd say revert, unless the support-issue Kwamu mentions is truly common. -DePiep (talk) 06:26, 8 October 2021 (UTC)

(post relocated to § Is it a unit at all?) DePiep (talk) 11:19, 8 October 2021 (UTC)

Oops, Kwami has found the old discussion I vaguely recalled and has posted at Module talk:Val/units#Character for the Earth symbol in Earth mass and Earth radius. Johnuniq (talk) 09:02, 8 October 2021 (UTC)

Is it a unit at all?

• Actually, it is not a unit of measurement, but a physical quantity. One writes correctly: "R_🜨 = 6357 km" Y, not "the Earth radius is 6357 R_🜨" N. Remove from unit list altogether? What does {{Convert}} do? -DePiep (talk) 06:32, 8 October 2021 (UTC)

Seems to me you could use it in reporting the mass of other objects as being N times earth's mass, e.g. "Expolanet in the mass range 2-3R_⊕". — SkyLined (talk) 10:21, 8 October 2021 (UTC)

That happens, but not sure if that's part of the definition. International Astronomical Union or IUGG should be able to clarify. Some ~older sources do not use this symbol at all: Geodetic Reference System 1980, 2009. Anyway it is bad habit to define unit symbol and quantity symbol to be the same. -DePiep (talk) 10:59, 8 October 2021 (UTC)

The purpose of {{val}} is to allow people to easily display frequently needed but hard-to-type symbols. It also provides no wrap for a number in front of the symbol, and a sort key. It does not matter if it is a unit or something else. Johnuniq (talk) 23:09, 8 October 2021 (UTC)

Would this (suggested change) be OK?

Moved from Module talk:Val/units

 – * Pppery * _{it has begun...} 15:49, 11 October 2021 (UTC)

What my "idea" is

In some cases

-- (e.g., where Proton–proton_chain_reaction#The_p–p_I_branch invokes "{{val}}"at least twice-- with [e.g.] {{val|14|u=MK}} and {{val|10|u=MK}}) --

The line .. (currently, line number 301, iirc) .. that says

MK [[Megakelvin|K]] SI

results in a hyperlink pointing to "Megakelvin" ... which is a"Redirect page,"pointing to

Orders of magnitude (temperature)

. I havean ideafor changing that line.

I was hoping to be able tobypassthat redirect page, by editing the above mentioned line ... (line number 301, "as of" the last time I checked) ... to change it from

MK [[Megakelvin|K]] SI

to

MK [[Orders of magnitude (temperature)|K]] SI.

The reason why I wanted to do that

My reasoning was ... that even though I could (maybe) havefigured outthat "MK" means Megakelvin [units] ... I did not want to have to click on that hyperlink in order to confirm my suspicions. (Call me lazy, but ... if I am lazy, then ... perhaps that situation was aided and abetted by .. the fact that Wikipedia offers those convenient little "preview" displays, -- ! -- when I "hover" my "mouse" pointer over a certain displayed hyperlink.) Asyou may already know!,-- those cool little "preview" displays work OK when there is NOT a redirect involved, but ... when there*is*a redirect, then ... they do not exactly work. (One would have to actually "click".)

Any comments?

Would that (suggested change) be OK?

* * * Thanks * * * for listening. --Mike Schwartz (talk) 18:06, 29 September 2020 (UTC)

I think the issue is the link in the following:

• {{val|10|ul=MK}} → 10 MK

When I hold the mouse over "MK" I see the pop-up "Megakelvin", and the URL points to Megakelvin. That is standard for {{val}} which is intended for scientific topics where most people would know what megakelvin means (if they don't, they have a lot of reading to do) but might not grasp "MK". Are you saying that holding your mouse over the link does not show "Megakelvin"?

Ahh, I have worked out that you are referring to a feature whereby a preview of the target page is shown when holding the mouse over a link. No, don't change that because a much wider issue is involved. What I said is the standard reply that applied when previews were not available (I don't see them as fluff irritates me). There are thousands of links to redirect pages and people are told to not "fix" them (WP:NOTBROKEN) for the reason I mentioned, and because an article on megakelvins might one day exist. There would need to be a central discussion somewhere (WP:VPR?) with a proposal to change that procedure. Johnuniq (talk) 23:24, 29 September 2020 (UTC)

Character for the Earth symbol in Earth mass and Earth radius

Moved from Module talk:Val/units

 – * Pppery * _{it has begun...} 15:49, 11 October 2021 (UTC)

The current use of the Circled Plus (⊕, U+2295) to represent the Earth symbol for the Earth radius and Earth mass units (R_⊕ and M_⊕) is not the intended use of this character. This character only has the aliases of "direct sum" and "vector pointing into page" with the alias of "early astronomical symbol for earth" instead given to the Alchemical Symbol For Verdigris (🜨, U+1F728). Using this would give R_🜨 and M_🜨. It's true that the proper character has poorer support because it was added to the standard in 2010 while the Circled Plus was added way back in 1993 but the lookalike has its own display issue in that some fonts may display the plus sign as not reaching the edge of the circle and so will end up displaying something that isn't actually visually identical to the Earth symbol. Note that any change should also be applied to Template:Earth mass. NuclearElevator (talk) 05:19, 13 October 2020 (UTC)

References

On some systems (e.g., MacOS 10.15), the character does not render legibly. From the text above, a screen capture: . Looking at it pixel-by-pixel simply shows a smudged circle. In the past, this has been a problem making it indistinguishable from other symbols. Tarl N. (discuss) 16:32, 13 October 2020 (UTC)

While correctness is desirable, a smudge is not helpful and the original symbol (circled plus) should be used. Johnuniq (talk) 22:39, 13 October 2020 (UTC)

I'll note that part of the problem is that the character 🜨 (U+1F728) is already defined in most fonts as a subscript (below the horizontal, and small). Making it even smaller with  seems to be what leaves it illegible. For comparison, R🜨 vs. R_🜨 (the latter using subscript wikitext). I have a preference for the current circled plus (under the theory that it's not broken), but if for some reason we go with the U+1F728 character, we should remove the  around it. Regards, Tarl N. (discuss) 00:25, 14 October 2020 (UTC)

We seem to have the opposite problem. U+1F728 is not defined by Unicode as a subscript, and in my fonts is quite large, so that it's still easily legible as an html subscript. U+2295 on the other hand is rather small, so when made a subscript it's a bit difficult to distinguish from Solar mass/radius.

If you saw a box or question mark, that would be a problem. But if you see the correct character, and it's just too small, that's going to be idiosyncratic to each reader and it's best to use the correct symbol. You can always increase the font size of your browser. Substituting symbols for lack of font support is one thing; substituting to optimize a particular user's fonts is not a good idea. Better to choose default fonts that are compatible with Unicode standards. And if WP is supplying the character to readers who don't have it in their default font, and it doesn't display properly, that should get a more general fix than fudging a template. — kwami (talk) 05:48, 8 October 2021 (UTC)

From my talk page, it would seem this was a hack to compensate for an error in the Mac OS. I ran it by s.o. who's using OS 11.6, and it displays fine. So maybe it's been fixed? — kwami (talk) 21:20, 8 October 2021 (UTC)

@Kwamikagami: Nope. On Safari & Firefox on MacOS 11.6, and Safari on iPad iOS 15.0.1, it renders as a smudged circle. I note that Chrome on iPad (which, because I'm logged out, uses the mobile interface), it is legible. Note that my various OS configurations do not change any fonts or sizings, they use default. My Wikipedia login eliminates the mobile interface, I find it unusable. For the rest, I have Twinkle configured, use the Vector skin (Legacy Vector), and show hidden categories. Pretty much everything else is standard. Tarl N. (discuss) 23:32, 9 October 2021 (UTC)

So for one person using Safari on OS 11.6, it is legible, and for another it is illegible. I wonder what the deciding factor is? — kwami (talk) 23:43, 9 October 2021 (UTC)

Dunno. But it has remained constant across multiple displays on multiple machines and multiple operating systems. A difference may be the skin being used; I'm still using the original legacy vector skin (had to go out of my way to bring it back when they changed the default). Tarl N. (discuss) 23:54, 9 October 2021 (UTC)

Help with updating Val on Wikiversity?

Hi there! I'd like to use the Wikiversity version of Val, but it's outdated. Usage that works on Wikipedia doesn't work on Wikiversity. Would anyone be available to help with an update? Since this template relies on a module, and since I don't want to break existing pages that use the template, I thought someone here who is more familiar with the code might be able to do this more quickly, or provide guidance on how best to proceed. Any assistance would be appreciated! --Greg at Higher Math Help (talk) 08:02, 24 March 2022 (UTC)

I'll have a look in a couple of days. It should be ok to copy the two modules (with edit summary containing a link to the original here), then replace the template with what is here. Remind me if I forget. There is no way to know in advance or after the fact whether the modules would damage anything there. Johnuniq (talk) 09:56, 24 March 2022 (UTC)

Template-protected edit request on 17 May 2022

Can we add an ips unit for Inches per second? ~Kvng (talk) 17:09, 17 May 2022 (UTC)

@Kvng: I added ips at Module:Val/units. Is this what was wanted?

• {{val|1.23|u=ips}} → 1.23 ips
• {{val|1.23|ul=ips}} → 1.23 ips

Johnuniq (talk) 03:12, 18 May 2022 (UTC)

Yes, great, thanks! ~Kvng (talk) 21:40, 18 May 2022 (UTC)

Protected template edit request: formatting of magneton quantities

Can we change the displayed symbols for both |u=μN and |u=μB to italicize the mu (i.e., to display μ_N and μ_B rather than μ_N and μ_B)? The mu in these instances, unlike the mu in the unit μm or in the particle symbol for muon (
μ⁻
and
μ⁺
), is a symbol for a quantity (similar to c, k_B, and countless others), which by WP convention is italicized, even when a fundamental constant. See, for example, the formatting at the associated articles linked by this module, namely Nuclear magneton and Bohr magneton. 172.82.46.195 (talk) 20:04, 27 June 2022 (UTC)

Here μN and μB mean micronewton and microbel, not Nuclear/Bohr magnetons. Headbomb {t · c · p · b} 20:21, 27 June 2022 (UTC)

Revised request: Please delete the two lines with μN and µB (lines 606–607 at Module:Val/units). They conflict with micronewton and microbel, and appear to be unused. 172.82.46.195 (talk) 12:19, 28 June 2022 (UTC)

I'm not sure about this. On the one hand, cleaning out some of the cruft added to the units would be good, but those units have been in the module since it was first created and I found one occurrence in an article ({{val|10.6|ul=µB}} in Holmium). Johnuniq (talk) 10:30, 29 June 2022 (UTC)

This is not my call (obviously), but I'd say this must be one of the weakest "keep cruft because else something may break something" cases that I have ever seen. I missed that one – I must have forgotten to look for |ul=µB, and only looked for |u=µB. I also don't know how to use the WP search properly (insource: seems to follow inscrutable rules when considering punctuation). In any event, consider this:

• I started using it because it was supported, until I found the format generated was incorrect. Hence my original request (now struck).
• The current format generated is inconsistent with WP formatting of the symbols μ_B and μ_N (the magneton quantities).
• The two parameters with visually indistinguishable editor code produce different results (I personally find this unacceptable):

  {{val|ul=μB}} → μB vs.{{val|ul=µB}} → µB

  {{val|ul=μN}} → μN vs.{{val|ul=µN}} → μN

• Note that it is the micro-sign (U+00B5) that produces the symbol defined as mu-sub-B letter (and not micro-), whereas the mu produces microbel and micronewton: this is reversed semantics: guaranteed to confuse. Note also Headbomb's response above.
• If there are any remaining cases (and there should be very few), is it such a problem for them to break (and possible soon to be fixed)?

That said, I will leave that with you. 172.82.46.195 (talk) 18:18, 29 June 2022 (UTC)

I can't find any current instance of the micro-symbol used. So we can safely remove those. I'm not against having shortcuts for the bohr/nuclear magnetons, but probably something like mu-borh and mu-nuclear, or borh-mu, nuclear-mu so they don't get confused with micronewtons/bels. Headbomb {t · c · p · b} 19:07, 29 June 2022 (UTC)

@IP: Thanks for fixing Holmium (diff in case needed elsewhere). Searching articles with hastemplate:val insource:µB and hastemplate:val insource:µN does not find any occurrences so I have removed units µN and µB. Johnuniq (talk) 03:23, 30 June 2022 (UTC)

Thank you for dealing with this. 172.82.46.195 (talk) 11:31, 30 June 2022 (UTC)

Units for temperature-equivalent of eV, i.e., eV/k_B

Could we add units for temperature, in units of eV/k_B (and its common multiples)? I imagine the following would suffice:

eV/c2 [[Electronvolt#Temperature|eV/''k''<sub>B</sub>]]

keV/c2 [[Electronvolt#Temperature|keV/''k''<sub>B</sub>]]

MeV/c2 [[Electronvolt#Temperature|MeV/''k''<sub>B</sub>]]

GeV/c2 [[Electronvolt#Temperature|GeV/''k''<sub>B</sub>]]

TeV/c2 [[Electronvolt#Temperature|TeV/''k''<sub>B</sub>]]

As an example use, in Higgs boson, "when the universe was at a temperature 159.5±1.5 GeV" would more correctly be expressed as "when the universe was at a temperature 159.5±1.5 GeV/k_B" 172.82.46.195 (talk) 22:00, 2 August 2022 (UTC)

On review, I think thus request is overkill, so disregard it. This particular use is uncommon, can easily enough be implemented in the article by manually including the appropriate link, and we should avoid excessive accumulation of data for the module. 172.82.46.195 (talk) 13:25, 4 August 2022 (UTC)