Template talk:Val

para: no line breaks

The table in the doc sets a width on the columns to prevent line breaks in the parameter descriptions. This is a work-around and not a solution. I've asked for this to be fixed in {{para}} by making that template output html/css to prevent line breaks. — SkyLined (talk) 14:15, 3 April 2023 (UTC)

Horizontal spacing

Normally in expressions like 5 ± 3 the space to the left and right of "±" is what is appropriate to binary operation symbols, not, for example, written as 5±3. And when a plus sign or a minus sign is used as a unary operation symbol, there is less space, as in +5 or −5, and so it should be also with "±".

When this template is used it looks to me as if a larger space appears to the left of this symbol than to the right. Can that be fixed? Michael Hardy (talk) 20:17, 9 July 2023 (UTC)

The history is that {{val}} used to be based on template wikitext which was replaced with Module:Val. The old {{Val/±}} (now deleted) was edited on 12 May 2015 to provide left and right margins of 0.3em and 0.15em around ± (before that, there was no margin). The module emulates what the template did. That is, val has worked like this since May 2015. There are two cases where unequal spacing happens:

• {{val|5|3}} → 5±3 (margins [0.3em]±[0.15em])
• {{val|5e3}} → 5×10³ (margins [0.25em]×[0.15em])

I can see that someone used to binary operators would want equal spacing on both sides but I think an argument could be made that the ±3 is a modifier of the 5 so the current spacing is appropriate. Some examples can be seen in the infobox at Gamma Canis Minoris which includes Rotational velocity 5±2 km/s. Astronomical unit has more examples, including exponents and the best IAU 2009 estimate was A = c₀τ_A = 149597870700±3 m. We would need a pretty solid discussion and agreement to change val now. Johnuniq (talk) 04:39, 10 July 2023 (UTC)

Ideally, we should be following a standard set by an authorative body. Failing that, we should reach consensus on what to do based on the most common way it is done outside Wikipedia. I have no data on this either way, so I cannot help. If we cannot find any data on which to base this decision, a vote will have to do.

— SkyLined (talk) 07:25, 10 July 2023 (UTC)

Screen reader problems with digits grouped by spaces in this template

I can't figure out precisely what's causing the problem here, but in my primary browser Chrome (but not in Firefox), 123456.78901 now reads with my screen reader JAWS as "one hundred twenty three four hundred fifty six ..." instead of as "123 thousand four hundred ..." and so on, because it thinks there's a space between the digits. I'm pretty sure this was working fine in 2014 when I last brought this up. {{Gaps}} still works fine and the val template reads out properly with the other Windos screen reader, NVDA. I tried older JAWS versions back to 2020 and they still had this problem (though this isn't 100% reliable as they have shared components). Graham87 (talk) 09:12, 1 October 2023 (UTC)

Huh? It's working fine here but not in the template documentation. This problem's getting weirder and weirder ... Graham87 (talk) 09:14, 1 October 2023 (UTC)

OK it's not a val/gaps problem but an issue with whether an instance of this template is inside an ordered or unordered HTML list, per testing I've done at User:Graham87/sandbox25. Feel free to edit that page to add more test cases for me to respond to. But don't add 100000 of them ... hmmm, the val template reads correctly with my screen reader with definition/description lists! (Also, I didn't start using Chrome until 2020 so I wouldn't have previously noticed this problem). Graham87 (talk) 09:29, 1 October 2023 (UTC)

JAWS does insert random spaces in Chrome in other situations and it's apparently a fairly long-standing problem. This is the first time I've noticed it do so in a situation where people have gone out of their way to get screen readers to not display spaces! Graham87 (talk) 10:01, 1 October 2023 (UTC)

I tried the examples at User:Graham87/sandbox25#Gaps in Special:ExpandTemplates and also looked at the HTML source for sandbox25. In both cases the expected result occurs, namely the wikitext and HTML generated by {{gaps}} is identical in the three places it is used. The only difference being that the gaps HTML is in <ul><li>...</li></ul> or <ol><li>...</li></ol> when in a list. I guess there's nothing we can do about the problem unless some workaround turns up, for example a tag that would cause JAWS in Chrome to know it was a single number. It might be worth asking at WP:VPT. Johnuniq (talk) 01:59, 2 October 2023 (UTC)

I'd be very surprised if there was a tag like that ... and screen readers tend to not be good with such tags anyway. I think it's just a JAWS/Chrome bug. I might report it to Freedom Scientific, the company that makes JAWS, but given how long-standing the problem is I don't expect much traction. Graham87 (talk) 10:19, 2 October 2023 (UTC)

And it also affects bold/italic markup (which I've added to my sandbox ... I'd noticed this sort of thing before but I'd never really isolated the problem properly until now). Graham87 (talk) 11:30, 2 October 2023 (UTC)

I've mentioned this discussion at Wikipedia talk:WikiProject Accessibility#Weird bug with JAWS/Chrome inserting misplaced spaces in output, just as an FYI. Graham87 (talk) 11:42, 2 October 2023 (UTC)

I reported it and ... they fixed it in the very latest version (released last night my time), JAWS 2024.2312.53; all the items in my sandbox read out properly now! Their latest "what's new" page (archived because it's dynamic) has an item that says: "Resolved an issue where JAWS was inserting an extra space in the virtual buffer when encountering the closing tag for certain HTML elements." Graham87 (talk) 03:52, 21 December 2023 (UTC)

Template-protected edit request on 16 December 2023

The unit "dex" links to decimal exponent, which redirects to a page that doesn't use that term, nor "dex". It would be better to link to dex (decimal exponent). That doesn't actually exist, but it gives a message saying that one can look at the entry in Wiktionary, which does define it. Eric Kvaalen (talk) 15:53, 16 December 2023 (UTC)

I'm more inclined to remove the link altogether, but I'm sure that would break something. I'd be on board with linking to a soft redirect if any of the other links are to soft redirects. SWinxy (talk) 19:15, 16 December 2023 (UTC)

The unit dex was added on 14 May 2021 by Lithopsian in diff. It was used at HD 203949 in diff. I have removed dex from Module:Val/units and replaced where it was used with wikitext that links to dex (decimal exponent). I think that is the best that can be done at the moment. In general, a discussion like this should be just a discussion. Use an edit request after there is some agreement about what should happen. Johnuniq (talk) 02:30, 17 December 2023 (UTC)

bnwiki

Hi, on bnwiki, this module does not gives result in Bengali digit, so i did this. It works but not fully, see bn:Module talk:Val#উদাহরণ for examples. And for bnwiki, {{val|1234567.1234567|fmt=commas}} should be 12,34,567.1234567 instead of 1,234,567.1234567. Please help to fix. Thanks. আফতাবুজ্জামান (talk) 21:30, 18 December 2023 (UTC)

@আফতাবুজ্জামান: Module:Val is quite complex and I never got around to providing much localization. As you can see, numdot and numsep were added for the Italian Wikipedia, and likewise mtext allows easy customization of the error messages. However, there is no method to change digit translation or digit grouping. Module:Convert has a lot more and can group digits 2,2,3 but I would be reluctant to copy that tricky code into val and test it. Regarding translating the output, why not use bn:Module:EnDigitConverter that I wrote 8 years ago? I see it's now bn:Module:ConvertDigit. Maybe bn:Template:ConvertDigit which uses the module could be put in whatever template you are using for bn:Template:Val. Johnuniq (talk) 04:16, 19 December 2023 (UTC)

@Johnuniq, If i use bn:Template:ConvertDigit, for example {{val|1234.5678|1.23|4.56|e=3|u=deg}} won't work correctly. I was trying to use Module:Num Converter and was half successful. As you can see examples here, i am getting half Bengali and half English digit (e.g. 1২৩৪.5678°±1.23°). I was wondering if you could tell me which part (line) in the module produce that 1 & 5678 & 1.23 etc, so that i can just add "convert('bn', tostring(...))" to them. If you want, please directly edit the bn:Module:Val, it's not live yet. আফতাবুজ্জামান (talk) 23:34, 19 December 2023 (UTC)

I'll try to look at the issue maybe over the weekend. Feel free to post here and remind me next week if I forget to respond. Johnuniq (talk) 09:05, 20 December 2023 (UTC)

I have started looking and translating the digits won't be a problem. I should be done in a couple of days. Johnuniq (talk) 04:29, 27 December 2023 (UTC)

I put a preliminary version at bn:Module:Val. Johnuniq (talk) 08:30, 27 December 2023 (UTC)

@Johnuniq, Thank you. আফতাবুজ্জামান (talk) 20:06, 27 December 2023 (UTC)

Bug in unit apply to both numerator and denominator for inch/ft/min/sec (single/dbl quote)?

Compare:

• {{val|1|/|2.3|u=m/s}} → 1/2.3 m/s
• {{val|1|/|2.3|u=ft}} → 1/2.3 ft
• {{val|1|/|2.3|u=in}} → 1/2.3 in

vs.:

• {{val|1|/|2.3|u="}} → 1″/2.3″
• {{val|1|/|2.3|u='}} → 1′/2.3′
• {{val|1|/|2.3|u=°}} → 1°/2.3°
• {{val|1|/|2.3|u=deg}} → 1°/2.3°

 — sbb (talk) 01:36, 24 January 2024 (UTC)

Are you referring to how the second group repeats the unit while the first doesn't? That is an intentional feature that applies to ranges. It makes more sense when using a dash or to.

• {{val|1|-|2.3|u=ft}} → 1–2.3 ft
• {{val|1|to|2.3|u=ft}} → 1 to 2.3 ft
• {{val|1|-|2.3|u='}} → 1′–2.3′
• {{val|1|to|2.3|u='}} → 1′ to 2.3′

Johnuniq (talk) 02:09, 24 January 2024 (UTC)

(Sorry for the late reply, I don't think I was notified of your response to me).

I understand that it makes sense for ranges. But I'm not specifying a range, I'm specifying a vulgar fraction, and it seems to be supported (if only notionally) by {{val}}. If I want 1/2.3 in (as in, the sensor size, 1/2.3 in), it works. But other unit codes as noted, repeat. What is the rationale for treating different units differently? Or perhaps better asked, what is the set of units that don't repeat (such as "m/s", "ft", "in", ...) and what is the set of units that do repeat?  — sbb (talk) 03:30, 11 February 2024 (UTC)

@Sbb: In val, a slash is a range, not a fraction. It might end up looking like a fraction but val treats it as a range. That is for usage where the slash sort-of means "or". Units are repeated if the range is x or × (that's a WP:MOS issue) or if the unit is flagged with ANGLE at Module:Val/units. You might not need {{val}}. Just write out what is needed. Val is to replace tricky wikitext. Johnuniq (talk) 05:07, 11 February 2024 (UTC)

Where in WP is a range designated by a slash? I can't think of anywhere. {{val}}'s docs only mention a single example using slash, but does not prescribe slash as a range. It is merely a conjoining (conjunction) format, one of several, including range-types (hyphen, "to", "and") as well as product/area types (×, "by"). I understand that in the Lua code, "/" is treated like a conjunction, but that doesn't mean it's appropriate syntax as a conjunction.

But there's an obvious need for fractional values, and it seems slash should provide that.

And again, what is the MOS range rule that produces only the single unit label of "ft" for {{val|1|/|2.3|u=ft}} (1/2.3 ft) but the repeated unit label of "°" for {{val|1|/|2.3|u=deg}} (1°/2.3°)?

You might not need {{val}}. Just write out what is needed. I need to represent 1/2.3 in, which works with {{val}} just fine.

Val is to replace tricky wikitext. I disagree with that. Templates like {{val}} are especially useful to consistently and cleanly represent a combined value and unit, rather than having a hodge-podge of numbers that were forgotten to be wedded to a unit label with {{nbsp}}.

My point in this comment is that there's no logical reason angle unit labels should be treated any differently than other unit labels with "/". I understand that {{val}} does, but there appears to be no logic for that. And nowhere in MOS does slash indicate a sort-of range like "or".  — sbb (talk) 08:15, 11 February 2024 (UTC)

I'm just reporting how it is which has been unchanged since at least August 2015 when the template was switched to using Module:Val. Slash is handled the same way by {{convert}}. At any rate, I just added unit degree which does not repeat:

• {{val|1|/|2|u=degree}} → 1/2°

That might be adequate for your use case. Johnuniq (talk) 08:54, 11 February 2024 (UTC)

Template-protected edit request on 21 March 2024

Hi, I intended to add the {{val}} template to this article. Therefore I suggest the addition of the CGS-but-commonly-used unit of luminosity in particle colliders, cm^-2·s^-1. Thanks, sware • 🗣 • 🏲 22:03, 21 March 2024 (UTC)