Jump to content

Template talk:Val/Archive 3

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4Archive 5→Archive 7

Edit request

Per the suggestion above, change 

 -->w=f|a=r|<!-- Fixed width, right aligned

to 

 -->w={{{w|}}}|a={{{a|r}}}|<!-- Option fixed width, default right aligned

as currently in the sandbox. This will allow fixed width when needed, but will default to the user's preference. It will also allow different alignments, in case they're ever needed.

For example,

{{val/sandbox|7800|200|-100}} → 7800+200
−100
{{val/sandbox|7800|200|-100|w=f}} → 7800+200
−100Error in {{val}}: Val parameter "w=f" is not supported

— kwami (talk) 07:47, 13 February 2014 (UTC)

Demonstrate consensus for that change in {{val}}'s behaviour first (via an WP:RFC, or similar), and this can be implemented. Not before though. You really are hard of hearing. It's like the 20th time you are told to do this, at a million different pages.Headbomb {talk / contribs / physics / books} 11:28, 13 February 2014 (UTC)
Every single opinion has been supportive but yours. No-one else wants forced formatting, though PC-XT+ wants the option. Let someone else close this. — kwami (talk) 13:03, 13 February 2014 (UTC)
There was you and one guy on the astronomy project. That's hardly what'd I'd call a demonstration that consensus has changed. Headbomb {talk / contribs / physics / books} 13:24, 13 February 2014 (UTC)
  • Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. Regardless of who is supporting or opposing, while there is an RfC running, this request can't be assessed (and most of us expect an RfC to run a 30 day course unless it is withdrawn or WP:SNOW closed (and even then it could be WP:BOBSLEDed). Once your RfC has concluded, please have the closer make this edit or form a clear edit request and someone will carry out the consensus. Thank you and happy editing! — {{U|Technical 13}} (t • e • c) 16:20, 13 February 2014 (UTC)

RfC

See the edit request above: Should uncertainties be forced to be monospace, resulting in mixed fonts within a number for most users, or should they use the ambient formatting (as in the MOS and the template {{±}}), with an option for monospace if the editor chooses?

Compare:

1.012 +0.001
−0.002×10−22   (mixed fonts: ambient/monospace)

with

1.012 +0.001
−0.002×10−22   (single font: ambient).

For real examples (a third of all instances on WP), see the chart below. — kwami (talk) 13:11, 13 February 2014 (UTC)

Notified & invited WP:TYP. [1]. -DePiep (talk) 17:20, 13 February 2014 (UTC)
Again, that's not a clear description of the issue. The issue is should asymmetrical uncertainties (not all uncertainties) be rendered in correctly-aligned mixed fonts (123.00+1.11
−0.99), or badly-aligned uniform font (123.00+1.11
−0.99). This is a problem which very much depends on the browser, browser version, mobile display (i.e. phones), font preferences (e.g. for Candara, 123.00+1.11
−0.99 vs. 123.00+1.11
−0.99), etc. Headbomb {talk / contribs / physics / books} 13:33, 13 February 2014 (UTC)
Comment. "Correctly-aligned" may not be the best description. I think you mean "typographically, vertical aligned" (think monospaced characters) versus "same-font aligned" (losing vertical alignment because of smaller/wider characters). :To complete the description: the issue has two bad sides. Either it changes font in inline text (into monospaced), or it does not align similar numbers vertically (see widths "1" vs "9"). May I suggest to use the more extreme candara font examples? Note: this is not my !vote. -DePiep (talk) 17:01, 13 February 2014 (UTC)
Comment. LOL: so both are "correctly" now. I ask opponents (Headbomb and kwami) to withhold further pinstabs, because it confuses RfC understanding and reasoning. The previous section has more leeway for this. I have now identified the options "mixed fonts" and "single font" respectively for easy & neutral reference. -DePiep (talk) 09:14, 14 February 2014 (UTC)
Yeah, silliness is contagious. Reworded. — kwami (talk) 09:54, 14 February 2014 (UTC)
  • I see three options, none of which are ideal: those two presented above, as well as setting the whole template (except maybe units?) to the same monospaced font. (I believe Kwami mentioned this, above.) There is also the alternative of allowing parameters to choose between these, with the historical version as default. I can't say I really prefer one over all others. The monospaced font displays consistently, at the cost of making part of the result stand out. The second option generally flows better, but doesn't guarantee the same level of consistency. Full monospace would have the same consistency and look a little better, at the cost of setting itself apart from the text. Each would be more appropriate in certain situations, so I would say allow a choice. Also, I understand the fears that edit wars will happen on pages that have the choice. I would suggest that pages with the affected uncertainties remain using the form that they have, unless consensus for a change is reached. (Pages using {{+-}} would use the same-font option, as the template now does, and I suppose that template should be updated to have the same form as whatever this RfC adopts, with its own historic default, unless it is made redundant by this template or something. That may be an issue better discussed on the other talk page?) Is there a reason to not include an extra param for this choice? —PC-XT+ 07:43, 14 February 2014 (UTC)
It was just easier to code this way, since it feeds into the {{su}} template. We'd need to copy the monospace formatting from su to be consistent, but then if anyone modifies su, val would display mixed fonts until it's brought into sync. Also, no-one had requested it, so I only created options for status quo & MOS-compliant. — kwami (talk) 08:53, 14 February 2014 (UTC)
To clarify, the choice I !voted for doesn't need to include the third option, which doesn't really have support, and would require more editing. The two are probably sufficient. I was thinking that if the font was changed to monospace in the template, then su could be called without changing the font, but I may have missed something. —PC-XT+ 08:56, 15 February 2014 (UTC)
Duh! Of course. That would work perfectly. — kwami (talk) 10:16, 15 February 2014 (UTC)
Not currently no, but obviously both templates should have the same behaviour. Headbomb {talk / contribs / physics / books} 15:42, 15 February 2014 (UTC)
  • Use mixed fonts, i.e. monospaced for the two ± values. Not monospaced for all numbers in the template (PC-XT mentions above). Also give the option (parameter) to enforce monospace/vari-space (/all-numbers-monospace/all-monospace?) e.g. for usage out of line like in tables.
Though this outcome is not the "one and only correct" one as Bombhead writes. Maintaining the font in running text weighs enough to declare this a close finish in the trade-off, and to skip a blind MOS-ruling. Now, the technical eye recognises the two tabular numbers astonishingly well, even at a glance for the order of magnitude. The keep-font examples here, of course extremely chosen, are a headache. That says that even a less-extreme font will cause a torsion for the eye. I cannot do that to my fellow-technicians. -DePiep (talk) 13:51, 15 February 2014 (UTC)

Comparison of the two formats for all WP articles

(moved from MOS:NUM talk page)

Headbomb claimed that {{val}} is far more widely used than MOS-compliant {{±}}, and that therefore it is ± which should be changed. That turns out not to be true: 888 articles use ± (some of which I've converted to val2), including all of our star-system nav boxes, while only 33 use the ± option of val (out of 857 total). So, it's 888 articles which conform to the MOS, and which no-one has complained about, vs. 33 that use mixed fonts. Here is a list of a dozen of these articles, illustrating how much "damage" would be done by conforming with the MOS (monowidth mixed fonts top, ambient formatting bottom): 

{{hatnote|1=For each article test (=double table row): top row uses {{tl|val}}, bottom row uses {{tl|val/sandbox2}}}}
{| class=wikitable
| rowspan=2| [[Europium]] & [[Isotopes of europium]]
| colspan=2|{{val|5|+11|-3|e=18|ul=years}}
|-
| colspan=2|{{val/sandbox2|5|+11|-3|e=18|ul=years}}
|-
| rowspan=2| [[Quark]] & [[Quark–lepton complementarity]]
| {{val|9|+1|-2|u=°}}||{{val|1290|+50|-110}} ||{{val|100|+30|-20}} ||{{val/sandbox2|4190|+180|-60}}
|-
| {{val/sandbox2|9|+1|-2|u=°}}|| {{val/sandbox2|1290|+50|-110}}|| {{val/sandbox2|100|+30|-20}} ||{{val/sandbox2|4190|+180|-60}}
|-
| rowspan=2| [[Ring Nebula]]
| {{val|2.3|+1.5|-0.7|u=kly}}||{{val|1.3|+0.8|-0.4|u=ly}}||{{val|700|+450|-200|u=pc}}||{{val|-0.2|+0.7|-1.8}}
|-
| {{val/sandbox2|2.3|+1.5|-0.7|u=kly}}||{{val/sandbox2|1.3|+0.8|-0.4|u=ly}}||{{val/sandbox2|700|+450|-200|u=pc}}||{{val/sandbox2|-0.2|+0.7|-1.8}}
|-
| rowspan=2| [[Strange quark]]
|{{val|95|5|-5|ul=MeV/c2}}
|-
|{{val/sandbox2|95|5|-5|ul=MeV/c2}}
|-
| rowspan=2| [[Quarkonium]]
|{{val|4263|+8|-9}}
|-
|{{val/sandbox2|4263|+8|-9}}
|-
| rowspan=2| [[Gliese 581]]
| {{val|8|+3|-1}} Gyr
|-
| {{val/sandbox2|8|+3|-1}} Gyr
|-
| rowspan=2| [[Kepler-86]]
| {{val|5.01|+0.12|-0.12}}|| {{val|0.79|+0.09|-0.08}}|| {{val|5629|+42|-45}}|| {{val|0.41|+0.08|-0.29}}|| {{val|89.83|+0.03|-0.02}}
|-
| {{val/sandbox2|5.01|+0.12|-0.12}}|| {{val/sandbox2|0.79|+0.09|-0.08}}||{{val/sandbox2|5629|+42|-45}}|| {{val/sandbox2|0.41|+0.08|-0.29}}|| {{val/sandbox2|89.83|+0.03|-0.02}}
|-
| rowspan=2| [[PAL]]
| {{val|1.65|+0.4|-0.1|u=µs}}||{{val|51.95|+0.4|-0.1|u=µs}}
|-
| {{val/sandbox2|1.65|+0.4|-0.1|u=µs}}||{{val/sandbox2|51.95|+0.4|-0.1|u=µs}}
|-
| rowspan=2| [[Hubble's law]]
|{{val|70.4|+1.3|-1.4}}||{{val|71.9|2.6|-2.7}}||{{val|77.6|+14.9|-12.5}}|| {{val|70.4|1.5|-1.6}}
|-
|{{val/sandbox2|70.4|+1.3|-1.4}}||{{val/sandbox2|71.9|2.6|-2.7}}||{{val/sandbox2|77.6|+14.9|-12.5}}|| {{val/sandbox2|70.4|1.5|-1.6}}
|-
| rowspan=2| [[DC connector]]
|{{val|3.500|0.000|-0.075|u=mm}} ||{{val|0.140|0.000|-0.003|u=in}}
|-
|{{val/sandbox2|3.500|0.000|-0.075|u=mm}} ||{{val/sandbox2|0.140|0.000|-0.003|u=in}}
|}

There simply isn't an alignment issue in actual use.

The other articles are Up quark, Down quark, Charm quark, Bottom quark, Cabibbo–Kobayashi–Maskawa matrix, Neutrino oscillation, Planck (spacecraft), Teletext, List of mesons, Kamioka Liquid Scintillator Antineutrino Detector, List of baryons, Cosmic neutrino background, MINOS, Xi baryon, Lambda baryon, Strange B meson, B meson, GSC 03549-02811, NA62 experiment, Kepler-69, Z8 GND 5296.

— kwami (talk) 02:22, 13 February 2014 (UTC)

Ideally, fonts should be the same. However, this is not always practical in HTML. This is more of a technical template issue than a MOS issue, in my opinion, and probably should stay on the template talk page. —PC-XT+ 05:40, 13 February 2014 (UTC)
I tend to say: no monospace when not forced to. From the examples:
Single font when there is just on digit (Gliese 581 example).
Single font when only the last digit differs (example [[Hubble's law]).
Single font when bot numbers are exactly the same (Kepler-86 example). Of course this rarely occurs because one would not use the split, but in the example article a split could be used to have similar wordimage over all instances on the page (=the other exaples given for that page).
These are rare situations, within a rare situation. -DePiep (talk) 12:53, 14 February 2014 (UTC)
Except that kind of logic can't really be implemented, and asking editors to inspect the visual output (on several machines and font settings) is unworkable. Also, you say if there's only one digit, it should be single-font, but such cases can clearly be misaligned (7+8
−1). Likewise for when the last digit differs (1.7+0.8
−0.1) The only time the uncertainties are guaranteed (sort of, this assumes that + and − are of the same width in that font) to be aligned is when all digits match (1.7+0.8
−0.8), in which case you would simply use 1.7±0.8. Headbomb {talk / contribs / physics / books} 13:35, 14 February 2014 (UTC)
Yes, it could be implemented. No, no all-browser check needed or intended. -DePiep (talk) 16:51, 14 February 2014 (UTC)
Why this obsession with perfect alignment? When we align numbers in charts, we just left-align or right-align. We don't insist that every digit line up. In the rare occasions that we do want that, we can make them monospace. Uncertainties are no different: It's rarely important that they line up perfectly, and we can trust editors to know when that's needed, just as we do for all other numbers. — kwami (talk) 07:27, 15 February 2014 (UTC)
Kwami, these numbers are tabular even in this situation (inline usage). The scientific/technically trained eye is astonishingly good in recognising the pattern & the value in aligned digits. (Just think of why a financial clerk will always want the decimal point aligned: for the same reason). Before actually reading the numbers, the order of magnitude difference is visible from the positions. It is for this that I'll !vote for the monospaces. It is a tradeoff, so I disagree with Bombhead's conclusion that there is a simple "correct" outcome: that is not true. Maintaining the font in running text is a close silver medalist. Finally this: the situation is so specific, that enforcing any MOS (I did not look it up) would be too insensitive to the required tradeoff. I am a technician not a typograph, but I am waiting for typographists to argue why keeping the vari-font trumps. -DePiep (talk) 13:35, 15 February 2014 (UTC)
By that argument, all numbers should be monospace. It would be quite rare for this to make any difference in legibility. The spaces between every 3 digits shows you the order of magnitude, and in long numbers are mostly zeroes, which align perfectly regardless of whether the font is monospace. Maybe one case in a hundred would be easier to read, but we can always choose monospace if we need to. I don't see any reason to force that on everything. — kwami (talk) 08:56, 17 February 2014 (UTC)
For clarity: I mean to say that only the two +_ numbers should be monospaced. That is because these two, and only these two, are presented tabular. Other numbers are just single numbers in-line, which do not have a visual reference for widths. (In tables though, writing all numbers and even text in monospace could be welcome; that parameter option welcome). -DePiep (talk) 11:30, 17 February 2014 (UTC)
Yes, and I meant no reason to force it even on the ± numbers except in rare cases. Usually when I've seen numbers that don't align they're s.t. like +110
−80, which can be taken in at a glance, or else s.t. like , which are close enough as to hardly matter. I mean, can you point out a single case in the table above (which illustrates a third of all uses of val± on WP) where monowidth makes any practical difference? — kwami (talk) 21:28, 17 February 2014 (UTC)
See the PAL example in the table, a down-to-earth situation. The plus- and minus signs are affected too. Of course asking for a "practical difference" as a requirement limits me/us too much, because practically the numbers are the same in each font of course -- practically there is no difference, one can argue. BUt an essential example, like the PAL, shows that the numbers do not align vertically and so to the eye and to the mental perception are a burden. However minor and pixelcounting, the (technically trained) eye misses the pattern dearly. Even within a same pixelcount (that is, if the two different numbers have equal pixel width in a vari-spaced font), the font-design itself could disturb the eye this way. However, I say "could" because I have no typographical base for this statement. -DePiep (talk) 10:11, 18 February 2014 (UTC)
I thought you meant a difference where it would be difficult to process the order of the uncertainty without monospacing. To my eye, the drastic change in font makes the uncertainty stand out as if we had bolded it, and that throws me, whereas the difference you point out is what we can expect for all numbers in most fonts. I can certainly see making monospace an option, I just don't see any reason to make it mandatory in all cases across all articles. — kwami (talk) 12:15, 18 February 2014 (UTC)
Fixed width fonts should not be forced, and are rarely needed. All the examples above show skewed because they use a font where numerals happen to have unequalized width (Candara, Georgia etc.). This is usually the case when a font contains lower case numerals. Most default sans-serif fonts like Arial, Helvetica and DejaVu Sans, and even most serif fonts like Times have equal-width numerals.
1234567890
0987654321
1111111111
9999999999
1234567890
0987654321
1111111111
9999999999
No one should see the above with unequal widths unless their default sans-serif and serif font has unequal widths.
Now, the font used in examples by way of {{xt}} is a problem, because it uses Georgia which has unequal-width numerals. Perhaps it is time to switch to Times. In any case, fixed width should not be forced, but optional. — Edokter (talk) — 14:27, 23 February 2014 (UTC)
All of those are of uneven width! Arial, Helvetica and DejaVu Sans, etc... are of unequal width, which is why we need the fixed-width to be default. Headbomb {talk / contribs / physics / books} 23:37, 23 February 2014 (UTC)
Then you are using something else the Arial, Helvetica or DejaVu Sans... Give us a screenshot of what you see. — Edokter (talk) — 00:29, 24 February 2014 (UTC)
Edokter, how is it OK to assume/state that digits are equal width in a font that is not defined to be monospaced? -DePiep (talk) 06:14, 24 February 2014 (UTC)
With me the example numbers do not have equal width. I am not interested in any "you have the wrong font settings" address, as aren't our readers. -DePiep (talk) 06:47, 24 February 2014 (UTC)
Edokter, you conclude Fixed width fonts should not be forced, and are rarely needed. ... In any case, fixed width should not be forced, but optional. That would only displace the discussion from here to multiple individual talkpages, in an endless repetition. The RfC question is: isn't this such a rare situation? And why not define the exception so that it is not left to individual editors/articles/repeated discussions? In other words: would you accept the monospaced numbers in the situations mentioned here, and what would be the guideline from that? -DePiep (talk) 06:47, 24 February 2014 (UTC)
Re the report that "9999999999" is wider than "1111111111", would someone with the necessary skill/patience please investigate https://bugzilla.mozilla.org/show_bug.cgi?id=931029 which may be relevant. I think that page is saying that Firefox, under certain conditions, correctly applies kerning to "11". Johnuniq (talk) 07:04, 24 February 2014 (UTC)
Aha! I never suspected that Firefox would be the only one where this is a problem. Firefox applies the native kerning for consecutive "1" glyphs (all other number glyphs are unaffected). That page also gives a possible solution: (-moz-)font-feature-settings: "kern" 0; W ecould put that in a class .digits, and we would no longer need fixed width fonts.
1234567890
0987654321
1111111111
9999999999
1234567890
0987654321
1111111111
9999999999
How does that look? — Edokter (talk) — 12:47, 24 February 2014 (UTC)
For me, same irregularity as the list above. Ff 27 atop WinXP, no fonts set to my knowledge. My Safari shows them aligned OK, twice. (Are you sure you wrote the style="" OK?). -DePiep (talk) 12:55, 24 February 2014 (UTC)
I mismatched the quotes for a minute but I corrected that right away. Please try again. — Edokter (talk) — 13:11, 24 February 2014 (UTC)
Oooops, so my early response here was not saved. I purged & I see: top four rows equal width, bottom four equal width.. Bottom four rows are about 85% of top four row length. -DePiep (talk) 21:43, 24 February 2014 (UTC)
That "-moz-font-feature-settings: 'kern' 0;" seem to take care of things perfectly [I'm on FF27 / Win 7], but if it's Mozilla-specific, then the problem will still show up on other browsers... But if this works on all browsers, this really is the ideal solution! Does that work on the other ones? Headbomb {talk / contribs / physics / books} 19:50, 24 February 2014 (UTC)
This may be also of relevance [2]. Headbomb {talk / contribs / physics / books} 20:03, 24 February 2014 (UTC)
Other browsers that I can test (IE8, Chrome, Opera 12) do not seem to apply kerning in the first place (but that may be due to running XP), however it wouldn't hurt adding the -webkit- and no-prefix version (for IE10). It still is better the using monospace. I adjusted my lates example. — Edokter (talk) — 20:53, 24 February 2014 (UTC)
They're all equal-width in Opera & IE on Win7. — kwami (talk) 21:37, 24 February 2014 (UTC)

Option needed: monospace all

Consider this situation. The template can be used in a table (wikitable). That is, not in running text. Then there is no objection against using monospaced fonts. In a table, the tabular pattern can prevail (align the digits by equal positional value). This requires monospacing all characters, even the units. To make the template fit for universal usage, this could/should be an option. -DePiep (talk) 06:36, 24 February 2014 (UTC)

It's a bit more complicated that that. It will be extremely hard to align numbers such as 12±34 with 1±2 and (123±45)×1010 in tables. There needs some kind of padding added at various places, and since the spacing between the digit groups is not a full character, it would adds a considerable amount of complexity to the code, if it's even possible (e.g. align 1.23±0.02 with (3.455±0.32)×1023). There are simpler cases however, but even then there would need to be some kind of padding on both sides to align numbers such as 12.3 with numbers like 2.45. Headbomb {talk / contribs / physics / books} 12:32, 24 February 2014 (UTC)
Yes, difficult or impossible. And it is web-illegal to left-fill out with spaces/nbsp's. Still, for the editors judgement, it could be a solution in situations. After all, it's tabular for a reason. -DePiep (talk) 12:49, 24 February 2014 (UTC)

Shall we close this?

I have fixed {{su}}, which was slightly botched, and we now have a solution where we can use the body font without misalignment (as long as no funky fonts like Candara are used) using font-feature-settings. Look at the table above (which is using sandbox2) and see if there are still any 'damaging' anomalies. If not, the forced monospace can be removed and sandbox2 can be integrated. — Edokter (talk) — 13:08, 25 February 2014 (UTC)

That's this table above, I understand. Brilliant! No objections left from me. -DePiep (talk) 13:17, 25 February 2014 (UTC)
I have objections contingent on browser compatibility. Does this work on all browsers? If not, for which browser does it not work? This includes old versions of browsers. Does it work for all fonts? We may have to implement conditional CSS if there's a significant amount of browsers / fonts that do not support this. Headbomb {talk / contribs / physics / books} 17:13, 25 February 2014 (UTC)
Have a look here. Support seems pretty mature. Also keep in mind that older browsers that do not support this feature, generally do not support kerning in the first place, so they should not be affected. As for fonts, unless you have a certain font such as Candara set as your default sans-serif, there should be no problem at all. I do not consider this issue big enough to try and cover every possible scenario using conditional CSS; I believe 99% is served adequately with this solution. — Edokter (talk) — 18:41, 25 February 2014 (UTC)
If we go based on that and the WMF traffic stats [3], on traditional platforms [non-modile], we have IE < 10 = 6.79%, Firefox < 4.0 = 0.31%, Chrome < 16.0 = 0.32%, Opera = 1.51%, Safari = 3.88%. For a sum of 12.81% out of 64% of page requests. This is roughly 1 in 5 people without support for that feature. Someone can do fancier analysis if they want, or use HTML request instead of any request, but it's going to come around that 1 in 5 ratio on non-mobile.
That is a very far cry from your 99% figure. Conditional CSS is needed so older/unsupported browsers can fall back on monospace fonts. Headbomb {talk / contribs / physics / books} 21:05, 25 February 2014 (UTC)
Perhaps read what he wrote? I noted elsewhere that it was fine on Opera. Do you actually know of a case where this solution would be a problematic?
We should check Safari. As for old IE, I doubt that many users would be reading the technical articles that have asymmetrical uncertainties, and if they do, they already know that their browser doesn't support a lot of features. Font alignment is the least of their worries. — kwami (talk) 21:41, 25 February 2014 (UTC)
Let me clarify: Browser that do not support font-featrue-settings, tend not to support kerning at all. Meaning, they will not show number glyphs using unequal widths. I checked Opera (12.16) and it does not apply kerning, so does not need the CSS (later versions of Opera are Webkit). I don't know about IE9, but I suspect it does not use kerning either (someone check please). In short, browsers that do not support it, don't actually need it. — Edokter (talk) — 22:02, 25 February 2014 (UTC)
"Safari = 3.88%" does not support? FWIW, my Safari 5.1.7 atop WinXP shows aligned numbers in the big table OK (also the 2×10 check-rows show aligned within a single font). That would make the number 8.93/64=14% (1 in 7). -DePiep (talk) 14:04, 26 February 2014 (UTC)
This was not the correct implementation. The correct implementation would be to have the |w=f of {{su}} to disable kerning only for the asymmetrical uncertainties, and to also add a new value (|w=m) for monospace. And fixed width should be default in {{val}}, not optional. Headbomb {talk / contribs / physics / books} 12:59, 26 February 2014 (UTC)
|w=f is monospace (fixed) in {{su}}. We can't change su's behaviour solely for the benefit if this template. I though the point of this discussion was to do away with mixed fonts. — Edokter (talk) — 13:24, 26 February 2014 (UTC)
The point was to preserve the alignment of digits in asymmetrical uncertainties. Su's |w=f was introduced solely for this purpose, and we want this behavior to cascade in other templates such as {{+-}}, which should also produced aligned asymmetrical uncertainties. Headbomb {talk / contribs / physics / books} 13:33, 26 February 2014 (UTC)
All numbers are aligned now, while retaining the body font. The monospace (w=f) is still available, even though I can't think of a scenario where this is needed. Go ahead and try to trip it over. — Edokter (talk) — 13:44, 26 February 2014 (UTC)
That looks so much better! Once I see this won't be contested, I'll start using the template again. — kwami (talk) 13:01, 27 February 2014 (UTC)

Extra + bug

Small bug, though: double plus-sign in asymmetrical uncertainties when one is provided by the user. (See top examples in the table, which were copied directly from our articles.) — kwami (talk) 13:01, 27 February 2014 (UTC)

(I split up the comment.) That is a bug indeed. Seems to happen on short number only. I can see one hardcoded +, but I don't know this template well enough to fix it, and the testcases does not expose this bug. I'll let the resident template authors fix this one. — Edokter (talk) — 13:39, 27 February 2014 (UTC)
Fixed. Jimp 07:33, 3 March 2014 (UTC)

Bug? - Data received by e-mail at OTRS 2014030210003505

Example page Astronomical_unit - end of section "Definition" 

{{val|fmt=commas|92.955807}} million [[mile]]s

Resolves to ≈ 92.95580699999999 million miles
Not quite the output expected - and gives a false indication of the suggested accuracy of the conversion.  Ronhjones  (Talk) 19:49, 2 March 2014 (UTC)

Strange. What would |fmt=commas do for this value anyway? The simple solution is to omit it:
  • {{val|fmt=commas|92.955807}} → 92.955807 (currently shows "92.95580699999999")
  • {{val|92.955807}} → 92.955807
However, someone might like to ponder what fmt is doing. Johnuniq (talk) 00:46, 3 March 2014 (UTC)
The problem was {{#expr:92.955807-trunc92.955807}}, which gives "0.95580699999999" (instead of "0.955807"). It's been fixed by using {{rnd}} instead. Jimp 08:42, 3 March 2014 (UTC)

another uncertainty format

At ununoctium, we have:

~0.3–0.6 pb = (3–6)×10−41 m2

Is this something that would be worth supporting? Maybe something like val|3|to=6|e=-41}}?

Also, would it be worth formatting prefix = ~ to the harder-to-type ≈&thinsp; (or maybe a better-supported means of spacing) ?

— kwami (talk) 23:27, 3 March 2014 (UTC)

Also, sometimes we want to specify that a number is positive, as under metallicity at Upsilon Andromedae. Currently, {{val|+0.09|0.06}} displays as just 0.09 ± 0.06. I think this should be changed; if an editor puts in the + sign, they presumably have a reason for wanting it to be there, and people probably won't think of specifying it as a prefix. — kwami (talk) 23:40, 3 March 2014 (UTC)

Either {{val|p=(|3|end=–6)|e=-41|u=m2}} or {{val|p=(3–|6|end=)|e=-41|u=m2}} would do the job. This would be okay if it's a one-off but if it's something we'll be needing often, it's not the best solution since it's not very intuitive.
I'm not quite sure what you're suggesting when you mention formatting prefix = ~ to the harder-to-type ≈&thinsp;.
Not getting rid of added "+" was what caused the extra one to appear as mentioned above. We'd have to take care to only keep the "+" in the first parameter.
Jimp 07:51, 4 March 2014 (UTC)
For the +, we could always use p=+, since it won't come up all that much, but IMO it would be nice to support it directly.
I meant it's easier to type p=~ than p=≈&thinsp; if you want "≈ 3...". — kwami (talk) 08:25, 4 March 2014 (UTC)
We could support it directly. It would mean checking for it, checking that it's the first parameter (not the second) and adding it back. So, it's possible, the question is whether it's worth the extra coding given that we may not expect it to come up that much.
Yes, it would be easier to type "p=~" than "p=≈&thinsp;" if you want "≈ 3..." but what if you want "~3..."? Perhaps {{gaps}} is the answer.
Jimp 08:39, 4 March 2014 (UTC)

font format messed up again

The font's messed up again, evidently in some outsourced template, but I can't find it. {{gaps}} is still good. Any ideas? — kwami (talk) 04:45, 28 March 2014 (UTC)

Example please? It's hard to guess what exact the problem is. — Edokter (talk) — 10:09, 28 March 2014 (UTC)
The template has stopped user browser fonts, and forces one of its own. For me, using the template doubles the size of the digits, so they look out of place in text or a table. Gaps uses the browser default, as do other number templates. — kwami (talk) 10:25, 28 March 2014 (UTC)
I really need a page where this problem is visible, and/or a screenshot I can compare it with. — Edokter (talk) — 10:47, 28 March 2014 (UTC)
I followed up at Wikipedia:Village pump (technical)/Archive 124#Font format messed up in common template. — Edokter (talk) — 11:26, 28 March 2014 (UTC)
Thanks! That looks much better now. — kwami (talk) 06:19, 29 March 2014 (UTC)

It was screwed up again, this time forcing the formatting wherever it was used, perhaps because of changes you made to the WP CSS? I've removed the recommendation of this template from the MOS, noted on its doc page that it's no longer stable, and removed the digits class until we can figure out how to handle the extremely minor issue it's intended to fix without messing it up.

A possibility that's been suggested before: Why not just add an option for lining digits? "Lining=yes" or something. Wouldn't that take care of things? If people do it intentionally, then they'll do it consistently. It's the lack of consistency that's been the problem. We could also note in the doc that class=digits can be added to the tables themselves. — kwami (talk) 20:56, 2 April 2014 (UTC)

You asked me to revert it! You know what? I'm pulling out of here. But not before I tell the rest that whatever Kwami wants is impossible. Kwami is using Candara as default sans-serif font, which uses old-style digits (just like Georgia). This is a highly exceptional situation; normal sans-serif font use lining digits. Now, in order to force digits to line up vertically, I applied the .digits class, which 1) disables kerning 2) forces tabular digits. BUT that did not work on Georgia (used in examples), so I forced lining as well, forcing Georgia into submission.
Now Kwami complaints about inconsistent formatting, which is solely due to his use of Candara (which produces numbers like this: 0123456789, only apparent to Windows users). We had a looong talk on WP:VPT, but all is for not. After months of discussion, we are back to square one. You figure it out. The digits class is at your disposal. I do advise Kwami not to put any advice regading the use of {val} for the reason that what you see on the screen is not representative of what everybody else is seeing. — Edokter (talk) — 22:40, 2 April 2014 (UTC)
so this could be fixed if Kwami updated his/her own personal css for the digits class? Frietjes (talk) 22:50, 2 April 2014 (UTC)
Did that already. — Edokter (talk) — 23:14, 2 April 2014 (UTC)
Oh, I see it is disabled. No wonder he's seeing problems again. — Edokter (talk) — 23:16, 2 April 2014 (UTC)
seems like the solution to the "problem" is there, not here. Frietjes (talk) 00:08, 3 April 2014 (UTC)
Yeah, I don't think very many people use Candara. IPs who do may be annoyed, but users have custom css to fix it. Georgia looks ok. This feature improves the general look for most users. It seems there will always be problems with fonts, unfortunately. —PC-XT+ 04:02, 3 April 2014 (UTC)

Yes, Edokter, I asked you to revert, but meanwhile you'd changed the css, so the reversion made things even worse. (I disabled my css to see if your revert had returned things to the way they were. It had not.) We should not be forcing how people's browsers display unless it's really necessary. As for IPs being annoyed, most of our readers are IPs. We can't dismiss them as unworthy of consideration. And even among registered users, few of them would know to customize their css to solve this. We're making a system-wide problem to solve a non-problem.

This discussion has been split, and I've been mostly commenting in the other thread, where Edokter had directed me earlier. Here's my suggestion from over there: Add a 'lining' parameter so that editors have the option of using lining digits. If they take the time to specify lining digits, they will presumably take the time to make the article or table consistent, which was the main problem with the approach of adding digits to Val by default.

So, what if we change

<span class="nowrap">

to

<span class="{{#ifeq: {{{lining|}}} | yes | digits}} nowrap">

Does that do what we need it to? — kwami (talk) 07:41, 3 April 2014 (UTC)

No, it makes using this template unnecessarily complicated. Numbers should display correctly wherever they are used. And no, I did not change any CSS. The lack of inconsistent display is purely caused by your use of Candara. You have two choices:
  1. Have digits apply to {su} part only; this will show lining digits in uncertainties and normal digits in the main part. Inconsistent? Perhaps, but less distracting and preserving legibility. — Edokter (talk) — 10:02, 3 April 2014 (UTC)
  2. Apply .digits to {val}. This ensures base numbers and uncertainties are all lining and tabular, but may be inconsistent with the rest of the article.
Either way, the uncertainties must be aligned for proper display; that is a given. Your coice. — Edokter (talk) — 10:02, 3 April 2014 (UTC)
Things displayed fine before you started messing with it. All I asked was that you restore things to the consensus we had.
And no, those are not the choices, only your preferences. Neither is acceptable on WP. The first is not acceptable because we should not mix formatting within a number. The second is not acceptable because we should not mix formatting within a table or paragraph.
Alignment of uncertainties is hardly ever a problem in practice, but where it is we can certainly force the formatting. How is that "unnecessarily complicated"? Anyone who's adding asymmetrical uncertainties to our articles can figure out how to use the template. Setting digits to lining is no more complicated than linking units, and you don't have a problem with that. Half of all the asymmetrical uncertainties using this template are from me, and I believe the rest are mostly due to one other editor. Either of us could handle a lining parameter, as could anyone else here.
So here are your two choices: (1) Leave the choice to the reader, as is normal on a web page, or (2) give the editor discretion to override the default when needed. — kwami (talk) 10:59, 3 April 2014 (UTC)
You are kidding me right? This entire discussion is a result of your edit request above where you requested the default monospace be removed. That left us with mis-alignment which was deemed undesirable. I had a solution in place, which combined with your personal CSS, should be a solution to all, but then you decided to disable it again. So you know... whatever. I am done with this. — Edokter (talk) — 12:16, 3 April 2014 (UTC)

How to write "number does not exist" in a table?

I started this talk at MOS: How to write "number does not exist" in a table?. Is it hyphen, en-dash, em-dash, "n/a"? Please take a look (do not discuss here). -DePiep (talk) 08:02, 20 October 2014 (UTC)

Option or wrapper-template for sortable-table keys

This template is great for creating a WP:TABLE with a column of easily readable numbers. But if I want that column to be WP:SORTable and I have a mixture of units, I need to have hidden keys (data-sort-value=)with all the values converted to the same unit; otherwise just the "number" part is used for sorting:

Strict
numerical 		Hidden
key
age
2 d
3 d
1 w
age
2 d
3 d
1 w

Is there a wrapper function or flag for {{Val}} itself that sets the hidden key based on an additional parameter for its unit? For example, {{val|...|sortas=d}} that would convert units (u= and friends) to units of "d". DMacks (talk) 04:39, 31 March 2015 (UTC)

There currently is no such thing. I understand that having the conversion done automatically saves time and reduces the risk of typos, but I'm not sure if it's technically possible to add an argument to a table row using a template that is placed inside a table cell in that row. — SkyLined (talk) 09:05, 31 March 2015 (UTC)
It seems to work technically (if I understand the technical detail you are thinking about):
age
2 d
3 d
1 w
That's using a separate parameter passed to a template that converts it into the separate display and sort-key parts of a table-cell. {{User:DMacks/sandbox/sort-keys|val=val|key=key}} generates:
data-sort-value="key" |val
DMacks (talk) 08:42, 31 March 2015 (UTC)
You are right, that is what I am talking about and it does work :). We'd probably want to use another template in order to convert values so as not to duplicate work (I am thinking of {{convert}}). But might it be a good idea to add this option to {{convert}} and use that instead ? In a broader sense, it might be a good idea to look into merging (parts of) both templates. — SkyLined (talk) 09:04, 31 March 2015 (UTC)
I've added a line to the template which uses {{ntsh}} to produce a hidden sort key based on the SI base unit(s) (if units are specified) (as I had suggested at {{convert}}'s talk page). Currently it's using the subtemplates of the old version of {{convert}} (perhaps someone more cluey with Lua than I could get it working using the module). Units not covered by the old {{convert}} subtemplates can be added to {{val/sortkey/unit}}. Do we want a parameter to turn this feature off (or make |sortable=off the default and have the parameter turn it on)? Jimp 06:04, 3 April 2015‎
I have reverted these changes (see below), since they appeared to be causing errors in the template call {{val|299792458|ul=metres per second}} of the article Speed of light, as well as on the documentation page of the template itself—viz. in some of the template calls under "Units" in the Examples section (I don't remember which ones, but it wasn't all of them). I don't remember the precise error message, but it said something about a left square bracket not being a number. The error messages disappeared after I reverted the changes, which would appear to confirm that those changes were indeed responsible for the error.
David Wilson (talk · cont) 11:01, 3 April 2015 (UTC)
P.S.: I think the errors on the documentation page were in the template calls containing the "ul" parameter, which is the same parameter used in the template call in the Speed of light article.
David Wilson (talk · cont) 11:11, 3 April 2015 (UTC)
Thanks for the notice. I've found the error and corrected it. Jimp 11:52, 3 April 2015 (UTC)

Errors

There appear to be big red error lines? DrKiernan (talk) 10:09, 3 April 2015 (UTC)

Thanks, David. Sorted now. DrKiernan (talk) 10:13, 3 April 2015 (UTC)
The error seems to have been introduced by one of these two edits, which are the ones I reverted.
David Wilson (talk · cont) 10:24, 3 April 2015 (UTC)
Please link to an article that use to show the problem, and preferably copy the wikitext of an affected val to here. Someone will probably want to restore the recent edits and will need a clue as to what went wrong. Johnuniq (talk) 10:28, 3 April 2015 (UTC)

Here's what went wrong. Here's how it was fixed. Jimp 12:12, 3 April 2015 (UTC)

There appears to still be an error: see Talk:Neutrino#Formula_Errors_in_Article, resulting in a workaround there. —Quondum 20:27, 3 April 2015 (UTC)
The problem has been fixed. 02:21, 4 April 2015 (UTC)

sortkey, minor notes

Resolved
  • Q: could the "unit" be singular too?:
decade
century

If so, they could be added to the switch list.

  • Q: could there be a switch-off option for the sortkey (for inline situations).

|sortkey=no

Usually it would be reverse: requires to |sortkey=yes in tables, but that would make usage cumbersome. I'm fine with default=with sortkey. -DePiep (talk) 12:51, 3 April 2015 (UTC)

Yes, decade and century work (they could be added but they don't need to be since {{convert}} subtemplates exist for these). The strange abbreviations can be fixed at {{val/units}} and {{val/unitswithlink}}. There could be a parameter to switch off the sort key, yes. I know the norm is to have the parameter switch it on but since it's invisible anyway why do it that way? Jimp 13:36, 3 April 2015 (UTC)
So, to turn the sort key off use |sortable=off. Jimp 14:16, 3 April 2015 (UTC)

Reference handling

When using |ul= in combination with a reference, the result fails:

  • |ul=y<ref>[www.example.com]</ref>
125.2±3.3 [[y[1]]] Red XN

Special:ExpandTemplates shows that the sortkey is not affected (still OK). See Template:Val/testcases2.

Should we add |ref=? Never harms being able to handle refs separately. -DePiep (talk) 07:43, 4 April 2015 (UTC)

I'm not sure why you'd want to add a ref like that.
{{val|125.2|3.3|ul=y}}<ref>[www.example.com]</ref> → 125.2±3.3 y[2] Green tickY
... or even
{{val|125.2|3.3|ul=y|s=<ref>[www.example.com]</ref>}} → 125.2±3.3 y[3] Green tickY ... Question?
Jimp 08:05, 4 April 2015 (UTC)
Got it. Some templates might need another param then (cannot feed that ref into a dedicated |somequantity_unit=). -DePiep (talk) 08:27, 4 April 2015 (UTC)
... well, it always would if one wants to ul that. Independent of this issue. (I was triggered to look at this by the nice way {{Infobox person}}'s |length= now nicely returns a ref even when in single-param input.) -DePiep (talk) 08:37, 4 April 2015 (UTC)
  1. ^ [www.example.com]
  2. ^ [www.example.com]
  3. ^ [www.example.com]

Precision

The template now uses Module:Gapnum so we're no longer limited by the precision limits of {{#expr:}}. Jimp 16:28, 29 April 2015 (UTC)

Linking

Moved from Template talk:Val/units
 – * Pppery * it has begun... 15:57, 11 October 2021 (UTC)

Maybe {{val/units}} and {{val/unitswithlink}} should be redesigned to be {{val/units/symbol}} and {{val/units/link}}, where the first returns the (HTML) symbol for the unit and the second the page to link to for the unit. -- SkyLined (talk) 19:53, 22 April 2008 (UTC)

Better just author {{val/unit}} and require links in doc. Linking is important to MoS. Links and gloss, the parenthetical phrase behind the unit, spelling it out on it's first occurrence, so the reader gets it. There already are MoS instructions that say when and how to unitize (verses spelling-out), and when to link said unit, without overlinking. The current MoS stance means all units added here will require the unit to render equally with or without links.
No MoS or other will say "Don't add units to val." Article culture is "Any notable unit can be added." Global SI derived units are driven by SI base units, so derive your contribution to WP using val. As it is, yr displays "a" (annum) when not linked, but "yr" when linked. As it is, when following the documentation, it says on the edit page of val/<subpage> "When making changes to this template please be sure to update its documentation", which is yet another mismatch to reality. (Is the /test the /doc? No/Yes/Both/Neither?)
Documenting is important, testing units is not. How about dump the test concept from doc? For now, the two places that the proactive, val-editor should know are "to link" or "not to link". Now I, with no lack of any technical training, conception, or experience of large-systems software administration (done plenty) or of transclusion, I made a unitswithlinks entry, fretting thru test. After that? I don't test. It's not equally necessary. Doc how to add. If we doc a caveat about sandboxing and testing isn't this overkill? Just doc "don't remove any other entries; add your entry to two places". Doc well, or else automate. JavaScript may be required in order to add units to val.
As it is, there is a huge content-discrepancy between units and unitswithlinks. Tell me one thing, please. Can I just (doing my own perfectly accurate computer-textual-processing) make the two be all they can be, and be equal? If I don't hear anything against this, they will soon be, for I am WP:bold. Wikipedia loves rocks, and just rolls. — CpiralCpiral 07:48, 22 September 2012 (UTC)
"Better just author {{val/units}} and require links in doc." — Do you have the template skills to pull this off? I'm not sure this is possible, but that would be better than my suggestion, so I'd love to see it.
Also, might I suggest that you start (a) new topic(s) for your other suggestions, so we do not get discussions mixed up? I disagree with some of the things you say, and I'd like to explain why without making this a confusing conversation about multiple topics. — {{{1}}} (talk) 08:33, 24 September 2012 (UTC)
Because I don't have the knowledge to talk here, I'll take this to your user talk page, thank you. — CpiralCpiral 08:58, 24 September 2012 (UTC)
"I'd love to see it."  Done It's in the sandbox waiting, per discussion at val — CpiralCpiral 06:36, 23 May 2015 (UTC)

Mcg

Moved from Template talk:Val/units
 – * Pppery * it has begun... 15:57, 11 October 2021 (UTC)

mcg for microgram? Is this used? Should it be allowed?Headbomb {ταλκκοντριβς – WP Physics}

No, MCG is for Melbourne Cricket Ground. Interestingly 12 μg correctly gives "12 µg". It's time to fix this page to match. Jimp 10:21, 14 February 2014 (UTC)
Yes, "Users can add their own units" means their own keyboard makeovers. Mcg is OK because "mc" is an easy-to-type makeover for "µ" for non-Greek keyboards. Val/Units then converts makeover to markup, and then MediaWiki converts markup using standards. Val can use "mc", while rfc1345 suggests "My", and HTML and Latex suggest "mu" ("&mu;", and latex is "\mu"). It might be nice to suggest following one of these, but how far would that get us?: there are tens of thousands of them, and out of 440 total Val units only one mcg-like thing.
Val can have many-to-one mappings, such as m2, m**2, m^2 in three different articles, all going to m2, and it shouldn't matter because it won't significantly affect the config file or processor load. If they "mess Val up" with "silly nonstandard" makeover like "mcg", then Val works anyway.
The way these articles are hidden to Val maintainers is also not a big deal: they come to us. We just need good documentation. If a Val configurator 1) removes some school kid's "silly nonstandard" unit makeover, or 2) accidentally makes a one-to-many mapping, the vandalism via Val is rapidly self correcting; the more articles effected the faster it self-corrects. In every instance, wikitext points to Val, and they come here and read our documentation. — CpiralCpiral 20:18, 27 April 2015 (UTC)
If there's to be a shortcut for micro, it ought to be u, not mc. I'll do a database search when I get home and purge any mcg from Wikipedia. Then we can add the uX shorcuts as a systematic alternative to μX.Headbomb {talk / contribs / physics / books} 19:29, 24 June 2015 (UTC)
Agreed not 'mc' (though this is used in medicine, if it is recognized by val, it must never be converted to 'μ' but rather left unchanged; I'm not supporting this though). However, there is already a convention here to use mu, and use of 'u' is going to lead lead to confusion and bad habits. I see people using it as a text substitute in some contexts as though it is a standard prefix, and we should not encourage that (many people blur the distinction between a symbol and what it represents). —Quondum 02:13, 25 June 2015 (UTC)
Touché:
There are zero Val with mcg
There are zero Val with greek letters mu
There are fourteen Val with u=uX
— CpiralCpiral 17:03, 12 August 2015 (UTC)
Moved from Template talk:Val/units
 – * Pppery * it has begun... 15:57, 11 October 2021 (UTC)

I am in favor of creating redirect links for all unit/prefix pairs, as in kG links to kilogauss, which redirects to Gauss (unit). This has two advantages:

  1. searching for kilogauss will take you to the right page,
  2. the text shown when you hover over a link for kG will show kilogauss, rather than "Gauss (unit)", so it is immediately clear what the unit/prefix pair stands for. (See for you self: 0 kG).

I can't think of any objections, but I wanted to give people time to provide any they can think of. If I do not hear back, I will update the template at some point. If you are reading this message a month after I wrote it and there have not been any objections and I have also not updated the template, feel free to do so yourself and save me the trouble.

    — {{{1}}} (talk) 09:52, 7 October 2010 (UTC)
I've read that redirects are no problem. Create all we want.
But since module Val/units now goes with Wikipedia:HTML#Formatting only, I learned that the <abbr> tag creates hover text for abbreviations. So I can now recommend against redirects unless they are needed for individuals who'll be working with them a lot. So I would delete certain redirects for zetas and attos and keep certain kilos and megas and micros etc. on the Val work done so far. — CpiralCpiral 17:21, 12 August 2015 (UTC)

Massive sync to test

Moved from Template talk:Val/units
 – * Pppery * it has begun... 15:57, 11 October 2021 (UTC)

I plan on updating this template with the data at Template:Val/unitswithlink/test.

Test was missing 130 entries found here. After the update Unitswithlink will go from 316 to 434 entries. — CpiralCpiral 00:37, 24 April 2015 (UTC)

It would be nice if we could somehow automate this test update through transclusion of Template:Val/unitswithlink. —Quondum 01:53, 24 April 2015 (UTC)
We could use onlyinclude tags at Test, around the fifteen or so sections whose lines start with the pipe character, and then transclude Test into Unitswithlink.— CpiralCpiral 23:30, 25 April 2015 (UTC)

Wikify a Val configuration file

We should like to complete the wikification of Val. Unitswithlink and Units are Val configuration files, but you can't preview them. Hence their respective test pages. The MoS requires we combine them. Wikification (edit, preview, save, talk) requires we automate the integration of them into Val processes. — CpiralCpiral 23:30, 25 April 2015 (UTC)

Automate Units

Moved from Template talk:Val/units
 – * Pppery * it has begun... 15:57, 11 October 2021 (UTC)

Val/units configuration data, the other data, is only 105 units, and these suffice to render all 434 units flawlessly. But Units/test cannot be automatically integrated into Units unless we have all 434 units, because a number of the 105 units, like "years=years", are ad hoc patches that're visual-rendering corrections. These patches to visual renderings are not kept visible ("saved") at all times as they should be.

  • Units/Test reports use the talk page. The other test talk page is sort of restored. The Tests are just not wikified. Why are the report of Units/Test (on the talk page) all "Fail"?
  • I recently removed "year=year" from Units. WP:Test showed "a" (annum) when I used {val||u=year}. It should say "year", hence the configuration line in Units. (How does "a" get there?) Important question: why doesn't Units/Sandbox show this same "a" error in Units/Testcases?
  • Is there a difference between {Val||u=year} and Val/units|year? The side-by-side report I ran at Template:Val/units/test seem suspect, and unlike WP:TEST.

My response to this situation is that it is no wonder Val users are not doing all the work they are asked to do to add units. Documentation and procedure conflict with the simplicity users demand. So Val can't parse Unitswithlink to get the markup information for units-without-link, eh? Why should the markup information in each wikilink at Unitswithlink be out of reach to Units-without-link? It's there in every case.

— CpiralCpiral 23:30, 25 April 2015 (UTC)

Automation evolution and devolution

Moved from Template talk:Val/units
 – * Pppery * it has begun... 15:57, 11 October 2021 (UTC)
  • Can Val/unitswithlink create its own configuration file by using a simple transclusion of Unitswithlink/Test? Yes, by adding some new noinclude tags.
  • Can we make two config files plus two test-display pages into one config-display page that does all four? Would the aformentioned transclusion still work?
  • Val has evolved new features recently that manifested much better in-code commentary. Two user-visible changes have not been documented and are non standard:
    • Of the 130 new entries, 71 have template {{{variables}}} labeled "3", "4", "5", "6", and "ls". Those are new and undocumented.
    • Several of the new entries, namely around "arcsecond" and "solar radius", have pipe characters not uniquely associated to a line and an "=" char, like all the other units. And that arcsecond line is "out of touch" because it is not placed with the other units, but instead is above the "|#default" line.

— CpiralCpiral 23:30, 25 April 2015 (UTC)

Change of data source

Moved from Template talk:Val/units
 – * Pppery * it has begun... 15:57, 11 October 2021 (UTC)

I'd remove the data from Unitswithlink, and replace it with a transclusion of {{Val/unitswithlink/test}} to repopulate and maintain that data portion. This will keep the two files in sync.(See previous discussion.) — CpiralCpiral 03:44, 28 April 2015 (UTC)

If only the sandbox responded as expected. — CpiralCpiral 16:22, 28 April 2015 (UTC)

ε0 is a unit?

Moved from Template talk:Val/units
 – * Pppery * it has begun... 15:57, 11 October 2021 (UTC)

[4].

Where are the all the commas?

Perhaps this has been discussed before, but I can't find any reference to it. The template, by default, groups digits into triples separating by spaces. Why? The Manual of Style says commas should be used to separate triples to the left of the decimal point (never a dot). It does say to use spaces to separate triples to the right of the decimal point. It also throws out this bullet point, the meaning of which is unclear to me: "In scientific/engineering articles, long strings left of the point may be grouped into triples: 8274527" (fomatting using xt and gaps copied exactly from MOS) Lithopsian (talk) 12:49, 25 January 2015 (UTC).

I don't recall anybody ever bringing this up as a problem, so I doubt there ever was such a discussion. The Mos is indeed rather vague but from what I understand the MoS intends to explain spaces are used instead of commas, so I've updated the wording there to clarify that. If that is not the case, I expect the MoS will be updated by others soon to clarify what it really should be. In the later case, this template may need updating, as it is intended to produce numbers exactly according to the MoS. — SkyLined (talk) 16:19, 25 January 2015 (UTC)
This has been discussed, though I forget where. Spacing is a technical standard, and this template is used almost exclusively for technical data. — kwami (talk) 16:18, 18 February 2015 (UTC)
Basically there are five number formats accepted by consensus at MOSNUM.
  • grouping by threes using commas to the left and nothing to the right.
  • grouping by threes using commas but only for numbers with more than four digits to the left and nothing to the right.
  • grouping by threes using thin spaces on both sides.
  • grouping by threes using thin spaces on both sides but on the left only for numbers with more than four digits to the left.
  • grouping by fives using thin spaces on both sides.
The guideline has been reworded and reworded in an attempt to make it simpler; however, in doing so (it seems to me) it has become confusing and, taken literally, has come to say things that make no sense for which there never was any consensus. It really needs a proper rewrite. Anyhow, if you want commas, use |fmt=commas. Jimp 15:24, 3 April 2015 (UTC)

The MOS issue has been cleared up. Jimp 16:31, 29 April 2015 (UTC)

Bug: val can't do zero negative uncertainties

If I ask for {{val|5|+1|-0}}, I get 5+1
−0. A zero negative limit is commonly used in dimensioning drawings to indicate that a value close to the lower limit is preferred to produce a tight fit, but the dimension (commonly an opening) must not be smaller than specified. I haven't dived into the guts of the template to find the value, but I expect it'll require something like &minus;{{#expr|-({{{x}}})}} to ensure the minus sign doesn't disappear.

I added a note to the doc page in the meantime; if someone fixes this, remove it. 71.41.210.146 (talk) 10:24, 23 August 2014 (UTC)

So I tried to fix it but failed. It should be pretty straight forward: change the check to allow 0 as third argument and special-case it to output "&minus;0" rather than 0. However, my attempts to do this failed and I'm not sure why. I have not edited templates since before I had kids, so I'm a bit rusty. Somebody who's more up-to-date on things should be able to fix it in 5 minutes. — SkyLined (talk) 18:31, 24 August 2014 (UTC)
 Done— SkyLined (talk) 08:07, 25 August 2014 (UTC)
Ooh, thank you! About to start using it! 71.41.210.146 (talk) 22:47, 25 August 2014 (UTC)

The below was moved from SkyLined's personal talk page:

{{val|10|+0.5|-0.0|u=mm}} produces 10+0.5
−0.0 mm. Leaving off the decimal point works, but is ugly: 10+0.5
−0 mm The goal is something that preserves trailing zeros like 10+0.50
−0.25 mm Sorry to complain. 71.41.210.146 (talk) 23:06, 25 August 2014 (UTC)
Ah! It doesn't like the leading minus sign. {{val|10|+0.5|0.0|u=mm}} works, and produces 10+0.5
−0.0 mm. Is that okay? 71.41.210.146 (talk) 23:10, 25 August 2014 (UTC)
There may be something we can do about that. I don't have time to investigate right now. If nobody fixes this soon, feel free to update the docs to explain this until it gets fixed. — SkyLined (talk) 08:12, 26 August 2014 (UTC)
partial fix in the sandbox, 10+0.0
−0.0 mm, but it seems more complicated than necessary. Frietjes (talk) 15:01, 26 August 2014 (UTC)
Guys, really, use the sandbox, and test things first before rolling out stuff in the actual template. Headbomb {talk / contribs / physics / books} 17:08, 26 August 2014 (UTC)


Why doesn't val read something like {{val|500|10|−15}} as the third argument being negative (i.e. identical to {{val|500|10|-15}}, 500+10
−15)? For that matter, why can't it automatically read the third argument as being the negative uncertainty, even if not explicitly stated by the user? --JorisvS (talk) 23:04, 28 November 2014 (UTC)

@SkyLined:? Anyone else? --JorisvS (talk) 18:21, 10 March 2015 (UTC)
Sorry, I don't understand what you're asking, could you elaborate? — SkyLined (talk) 21:11, 10 March 2015 (UTC)
@JorisvS:, you mean why do we need "+" and "-", right? Yes, that could be done. Jimp 17:18, 29 April 2015 (UTC)
That's the second part of what I said, yes. The first part is that it doesn't understand the actual minus sign (−) as indicating the negative number, but only a hyphen (-). --JorisvS (talk) 17:23, 29 April 2015 (UTC)
The second part then would be easy enough to implement. The first part, though, whilst not impossible, would require a significant amount of extra code and I'm not sure that it would be worth the effort considering that this is pretty much the standard behaviour of templates on WP. Jimp 02:31, 30 April 2015 (UTC)
Quietly though, it turned out that it didn't take a huge amount of extra code (well, it did take a bit but most of that was dealing with something else); so, go ahead; both suggestions are working now. Jimp 11:09, 1 May 2015 (UTC)

decimal formatting no longer international

Entering e.g. {{val|.999|+.333|-.222}} no longer produces zeroes before the decimal points: 0.999+0.333
−0.222. Lots of abbreviated figures have been entered without international formatting, with the knowledge that the template will fix it, just as it groups digits into threes. All of that data is now poorly formatted. — kwami (talk) 17:18, 30 April 2015 (UTC)

Thanks for that. I'll own up. It's due to the switch to Module:Gapnum. Sorry about that. It hadn't occurred to me that people would input numbers that way. It'll be fixed shortly. Jimp 07:34, 1 May 2015 (UTC)
fixed Jimp 10:51, 1 May 2015 (UTC)
Thanks! — kwami (talk) 16:50, 1 May 2015 (UTC)

Display of recurring decimals

It seems appropriate to have a means of formatting recurring decimals using Template:Val. Such formatting can be done rather crudely as in, for example, Conversion of units. It would make more sense to add a means to the template to do this, e.g. via a "recur=" parameter, which would clearly not be appropriate with uncertainties. So, {{val|2.79|recur=346}} should display something like 2.97346. —Quondum 16:53, 10 May 2015 (UTC)

That would be good. We'd probably not want the line broken as with 2.97{{overline|{{gaps|3|46}}}}. I don't know how tricky it might prove to be. {{Val}} uses Module:Gapnum and this module doesn't seem to like being fed 2.97{{overline|346}}}} but perhaps someone handy with Lua could figure something out. Jimp 17:29, 10 May 2015 (UTC)

Re-purpose merge with test

Moved from Template talk:Val/units
 – * Pppery * it has begun... 15:57, 11 October 2021 (UTC)

Unitswithlink is doing its old job, plus I used partial transclusion tags to display the case/result settings so it could act like /test. And it looks like /test used to look, with the units organized by subject, in the hopes we can better see what we have and what we're missing.

Test is now doing a new job: side-by-side displays of Val/Units and Val/Unitswithlink. The units are in alphabetical order at /test.

All I have to do now is update the Val documentation, but Unitswithlink/doc and Test are already done.

Two years ago I synced the files up and wrote documentation on how to sync them, but they got way off. Now they are one file, and cannot get out of sync. The only thing that needs to be done occasionally is regenerate Test. — CpiralCpiral 00:36, 15 May 2015 (UTC)

Merge {{±}} into val

There is a template {{±}} that does parts of what val does, but doesn't provide the same spacing. I've suggested that it be merged with val a few years ago and nobody has objected since. I think this should be done to get a consistent look and feel for all cases where a ± sign is used. To implement this, I believe it would be best to copy the formatting code in val to ±, so the later looks like the former. Then we should replace the formatting code in val with {{±}}, so the formatting code exists only in one location. This would simplify the code of {{val}}, making maintenance easier and removing the risk of one template getting updated while the other is not, which would re-introduce discrepancies in their look and feel. This may be a rather large overhaul of the code and would need proper sandbox testing before going live. I may not have time to do this myself anytime soon, so feel free to start working on this if you do. — SkyLined (talk) 14:20, 18 February 2015 (UTC)

I'm with you on the question of merging. I'm not so sure about your suggestion as to how. I don't see any reason for {{±}} to exist at all. It's inferior and redundant to {{val}}, so why not just use {{val}}? Having a plethora of templates all doing similar things is generally unhelpful. What you suggest would improve consistency but cannot, I'm afraid, guarantee it, e.g. one person might use 12&nbsp;{{±|3|4}} and another might use 12{{±|3|4}}. In terms of consistency we'd be far better off getting rid of {{±}} and just using {{val}}. It's not as if it's a highly popular template that is going to be missed. Yes, there are a few hundred pages using {{±}} but, by the looks of it, the vast majority of these call the template indirectly through {{πs}}. I'd be surprised if there were more than half a dozen direct transclusions from articles. So, what we have here is a virtually unused redundant inferior template, which is a thing worthy of deletion. Of course, {{val}} could swallow it up as a subtemplate if this would simplify the code here. Jimp 09:01, 30 April 2015 (UTC)
I"m beginning to think that getting rid of {{±}} entirely might not be the best option after all. But, perhaps, instead of {{val}}'s transcluding {{±}} a couple of subtemplates could be created for them both to transclude. Jimp 17:34, 10 May 2015 (UTC)

Documentation on size limit

The documentation says:

"This causes an error for large numbers, numbers that require high precision."

and

"Because numbers can only be stored with a limited precision by Wikipedia servers, val cannot handle very large numbers, such as 123456789123456789."

The template appears to have been changed so that it can handle arbitrary size/precision. Presumably these comments can now be removed from the documentation? Test cases should also include a few ultralong cases, and drop the |nocategory= for the test cases that are now expected to pass. —Quondum 12:57, 23 May 2015 (UTC)

Done. Jimp 12:26, 24 May 2015 (UTC)

Formatting of precision value

I minor formatting point: I notice that the precision in the format with parentheses is not spaced. While

{{val|123456.123456|123456.123456}} produces 123 456.123 456 ± 123 456.123 456,

with parentheses the template produces

{{val|123456.123456|(123456.123456)}} produces 123 456.123 456(123456.123456),

which I would expect to produce the same spacing. —Quondum 12:49, 24 May 2015 (UTC)

The thing is that the digits in brackets aren't a number. 9.123(2) isn't the same as 9.123±2. The "(2)" indicates the error in the last digit so 9.123(2) is equivalent to 9.123±0.002. Likewise, 9.123(12) is equivalent to 9.123±0.012. So, if these digits are to be formatted, they'd have to be formatted according to the final digits, e.g. {{val|9.12345|(1234)}} would be "9.12345(1234)" not "9.12345(1234)" i.e. matching the spacing of the last four digits. I'm not sure, though, whether it's the done thing to space these errors anyway. I wouldn't even be surprised if there were no "done thing": it's not going to come up unless you have more than two digits in the error and I can't recall ever seeing that. So, I sort of doubt whether it'd be worth the extra code to handle a special case that may never even come up (especially when we might not be doing it right anyway). Jimp 14:45, 24 May 2015 (UTC)
You're right. Sorry, that was a really silly brain glitch on my part. —Quondum

ul borked

  • {{val|547.862|0.018|ul=MeV/c2}} gives 547.862±0.018 MeV/c2
  • {{val|547.862|0.018|u=MeV/c2}} gives 547.862±0.018 MeV/c2

The two should match, except for the links. Note the extra }} at the end of the first one. Headbomb {talk / contribs / physics / books} 01:49, 26 May 2015 (UTC)

I saw it but it's gone now. Perhaps it was this. Jimp 04:43, 26 May 2015 (UTC)

13 May 2015 restructure

A number of changes have been made.

adding exponents for errors
Three new parameters have been added.
  • |erre= allows a separate exponent for the error.
{{val|1.2|3|erre=-6}} → 1.2±3×10−6
{{val|1.2|3|erre=-6|e=-5}}  → 1.2×10−5±3×10−6
  • |+erre= and |-erre= does the same for + and − errors.
{{val|1.2|3|4|+erre=-6|-erre=-7}} → 1.2+3×10−6
−4×10−7
{{val|1.2|3|4|e=-5|+erre=-6|-erre=-7}}  → 1.2+3×10−6
−4×10−7×10−5

Jimp 10:22, 13 May 2015 (UTC)

I think that's a really, really bad idea to support this sort of stuff per overengineering. For your first example, someone sane would write 1.200000±0.000003 or 1.200000(3). In your second example, someone sane would write 1.2000000+0.0000030
−0.0000004. In your third example, someone sane would write 1.20+0.30
−0.04×10−5. Headbomb {talk / contribs / physics / books} 15:43, 29 May 2015 (UTC)
The second example is a bit of an overkill; however, the reason I added the this was that I came across the likes of the first example out there in the wild (on Conversion of units). I'd be happy enough to see it gone if we bring the article in line. Jimp 16:15, 29 May 2015 (UTC)
The more I think about it, the more I agree with you. It was the article which needed fixing not the template. Time to revert. Jimp 16:34, 29 May 2015 (UTC)
It's gone. Jimp 17:07, 29 May 2015 (UTC)
move prefix outside brackets
  • {{val|p=$|1.2|3|e=5}} → $(1.2±3)×105
Instead of
  • {{val|p=$|1.2|3|e=5}} → ($1.2±3)×105

Jimp 10:22, 13 May 2015 (UTC)

merge exponent part with main part to a numerical part

This simplifies the code by avoiding the double and triple use of the same #if:s. Jimp 10:22, 13 May 2015 (UTC)

moving errors off to subtemplates.

This is a step towards merging {{±}} as discussed above. Jimp 10:22, 13 May 2015 (UTC)

I'm trying to edit the links for 123 US gal and 123 mpg‑imp (amongst others) and I can't find where they are being produced. Those don't appear in {{val/unitswithlink}}. What gives? Headbomb {talk / contribs / physics / books} 12:52, 26 May 2015 (UTC)

They are linked via {{convert}} so if {{convert}}'s got it wrong, bring it up there, but if you want them to link to something different to what {{convert}} links to (for some reason), then add them to {{val/unitswithlink}}. Jimp 18:16, 26 May 2015 (UTC)
Brought it over there. Headbomb {talk / contribs / physics / books} 02:25, 27 May 2015 (UTC)
I can see where you might get tired of this role, Jimp. I've now documented this at {{val/unitswithlink}} — CpiralCpiral 23:32, 30 May 2015 (UTC)

Behaviour on substitution

When using {{subst:val|...}}, this template inserts a lot of comments in the page that are intended for the template programmer, and not for being inserted into the page being processed. It also is inefficient inasmuch as the comments remain on all iterations of template expansion. The use of {{{{{|safesubst:}}}void|...comments...}} <noinclude> tags inside the template causes the comments to be removed on the first iteration of expansion (both for substitution and transclusion). I'll implement this and see what the effect is.

Even with this, there is a lot of clutter from #if etc. that would be nice if resolved at time of expansion rather than after expansion, assuming all the parameters to {{val}} are literals. There is a subtlety, though: the early evaluation of the #if on substitution probably cannot deal with parameters to {{val}} that are themselves template calls, since these will not have been expanded at the time of the #if evaluation. What a mess the template processing is. I'll leave this issue for now; I'm just mentioning it in case of thoughts... —Quondum 19:24, 31 May 2015 (UTC)

{{val}} isn't meant to be substituted. Headbomb {talk / contribs / physics / books} 00:59, 1 June 2015 (UTC)
Sure. But it can be substituted as it stands. Doing so gives a good sense of what's happening under the hood. The HTML comments presumably add significantly to the server processing load while rendering the page. Any template that might be expanded thousands to millions of times a day could use a little trimming of processing if this does not impact the function of the template. Every time this template is transcluded, tens of thousands of characters are unnecessarily processed by a Wikimedia server, probably many times over due to the interative template expansion process. —Quondum 01:29, 1 June 2015 (UTC)
And every time we update val, we'll need to clean up to several thousands of articles? That's the whole point of templates. If we update the template, everything gets updated. As for performance, see WP:PERFORMANCE. Headbomb {talk / contribs / physics / books} 02:12, 1 June 2015 (UTC)
What are you talking about? I'm not talking about a change to how the template is called or how it renders with any given parameters. I am not suggesting a change to any articles or how they invoke {{val}}. As to performance, I know there is no need to "worry" about it; this is simply at the level of writing clean templates. Hey, you've almost challenged me to modify a template so that WP becomes sluggish; it shouldn't be difficult, though I still have much to learn about how templates work. —Quondum 02:29, 1 June 2015 (UTC)

Regularization of unit shorthands

This template has two factors that I see an issue with, that may be worth thinking about:

  • Redundant variants are creeping in. Multiplication at times is represented by * and .. These are unnecessary redundancy, and invite all units with multiplication to be included in the template in both forms. I see value in allowing only one "shorthand" (*) and a literal form (including the use of middot ·, where the entire units string is not recognized, and thus treated as a literal, and can thus also not be used with |ul=). We could "specify"/encourage a regular units syntax shorthand. Is it possible to locate all instances in articles where "nonstandard syntax" is used, so that these may be changed and removed from the template? Or could we just change the template to display "please replace bad {{val}} parameter with |u=<correct string>" for existing irregular cases (and then do a search for articles with that message)?
  • There is a combinatorial problem: if all the possible useful variants of products of units is listed, the size of the list of units grows combinatorially in the number of units. The value of a template is somewhat reduced if every new variant someone uses needs an edit to the template. Would it make sense to parse out and reformat a "standard" syntax (which understands SI prefixes, standard unit names, *, /, exponent values)? (This might also have possibilities for {{convert}}.)

Both the above points individually argue for a regular syntax for units. Should we start by documenting such a syntax in the Template:Val/doc#How to add units section? —Quondum 14:07, 30 May 2015 (UTC)

I'm all for standardising syntax. The standardisation, though, should go beyond this one template. Notably, there should be a standard which works for both {{val}} and {{convert}} (with a couple of exceptions, e.g. C for coulombs here whereas at {{convert}} it's Celsius). This point is made even more vital by the fact that {{val}} uses {{convert}}. This point is worth considering when choosing whether to use a "*" or a ".": {{convert}} never uses a "*".
To locate uses of irregular syntax we could use a hidden category.
I like the idea of interpreting a combination of units according to a standard syntax. {{Convert}} has gone somedeal of the way down that path. If it would be useful to go further, it might be best to bring the issue up there (as such things will end up going through {{convert}} anyway). Jimp 14:36, 30 May 2015 (UTC)
Excellent observations. Synergy between templates is important, and I'd suggest starting with a conversion of {{val}} and all uses to match the logical cases in {{convert}} – in particular, replacing * with .. This also leaves open the door for (eventually) allowing a user of the templates to choose between the SI-permitted notation variants of a product of units: either a non-breaking space or a dot. What I'm saying is that {{convert}}'s . makes more sense than * in every way, and you have given a possible path to fixing this. I expect that the hidden category on all uses of * would be small enough to fix manually.
I think that we should remain vigilant on the conflicts on C and F (these not being "logical cases"); I have strong opinions on this, but let's leave that be for now. Are there any implications of this at that template (assuming we go with .)?
While on this topic, should we not output the Unicode DOT OPERATOR &sdot; (⋅) rather than MIDDLE DOT &middot; (·) for multiplication of units (see WP:⋅)? —Quondum 18:55, 30 May 2015 (UTC)
I think the MoS says don't use middot. But on every such issue, the MoS is sometimes held with disdain by would-be editors. There are no rules, because a Wiki is a page anyone would edit. Primarily we must encourage people to use and edit without restrictions and with freedom. Thus Val should have many-to-one mappings, such as m2, m**2, m^2 in three different articles, all going to Meter, and it shouldn't matter because restricting that particular freedom won't significantly affect the config file or processor load. Like the MoS says, consistency is per article, not per styles rulings, of which there are usually several to choose from.
When the school kids "mess Val up" with "silly nonstandard" makeover like "mcg", instead of the rfc1345 standard "mug" for microgram, then Val works anyway. The way such rouge articles are hidden to Val maintainers is also not a big deal: they come to us when we make necessary corrections. We just need good documentation when they come. If a Val configurator 1) removes some school kid's "silly nonstandard" unit makeover, or 2) accidentally makes a one-to-many mapping (breaking the case above it), the "vandalism" is rapidly self correcting; and the more articles effected the faster it self-corrects. In every instance the error points to directly to Val, and they come here and read our documentation. Not we check our hidden categories and maintain an ever swelling list.
But we could reduce the Units switch caseload by 70% if we addressed the SI units challenge. First we identify the cases where the first letter is {da, h, k, M, G, T, P, E, Z, Y, d, c, m, μ, n, p, f, a, z, y} AND not a unit AND the link was the same article, strip it off, look up the rest in the reduced switch, and then added it back. The exceptions would be cases like "m", a unit and an SI prefix, and Meter squared with its own article other than Meter, and a handful of other articles that have the SI unit in there title, or whose links go to subsections instead of title lines. Specifically there are 341 (of 405) lines in our config file that begin with one of those letters. Of those E has three exceptions, G has one exception (but the "a" of "Ga" would go to "Year", not "a" or "A"), M has four exceptions, T has one, "a" has one, c has one, the d's have about three, the m's have about 15 exceptions, n has two, p has three, y has three. So 341 - 35 exceptions - 20 units is 286 lines we could eliminate! We could reduce the #switch post expansion by 286/405 or 70%, just by simply have a list of those letters and a list of those exceptions.
It could remain just as easy to add a unit: every once is a while someone like me or SkyLined would go to a specific "New units" section in Units config file, and inspect those to make sure they did not constitute an exception. These new adds would be displayed as normal and would expand in each call, but the manicured adds, internally they'd be in a different switch statement that was expanded. Then post expansion would be the "New units" list plus current switch would be about 150 lines instead of 400.
Standardization and efficiencies must balance against the principles of a Wiki where the procedural inefficiencies and permissiveness give surprising crowd-sourcing power. It is not intuitive, but it works great miracles. Plus the wiki coding abilities are limited for strings. We'd probably have to write our own Lua module to do even just the SI stuff. Actually there is an effort to create a world standard for mathematical nomenclature, but there is virtually no standard. If Convert has an internal standard, let them choose. But since the Val model uses a Wikified config file, let the world choose. — CpiralCpiral 23:16, 30 May 2015 (UTC)
I am not advocating the removal of the ability to add arbitrary unit combinations (including unit multiplication using *), but it would be good if the primary guide and usage was aligned with that of {{convert}}, in part because it will confuse editors less. This initially means changing the examples in the template documentation. Similarly, I'm not saying that we should place an embargo on the middot, only that we can replace the middot with sdot in what is currently there. Are you against this? I'll give this a bash. —Quondum 00:21, 31 May 2015 (UTC)
Okay, I've done this. I should not have broken anything, but of course I may have. —Quondum 01:40, 31 May 2015 (UTC)
Oops. Use &middot;. It says to not use {{middot}}. Sorry. — CpiralCpiral 02:58, 31 May 2015 (UTC)
We could have a preferred and a suggested. I wouldn't want to say {{convert}} is preferred because their documentation does not apply to our user-invented Val-markup. It says * is deprecated. It says use ×. I don't want to ever refer any user to Convert unless we have to, or in a See also section. "No side by side units (but either kWh or kW·h). Use dot, middot, or *, but * is prefered." Or "Val suggests dot and middot, but * is prefered." Like that. — CpiralCpiral 02:58, 31 May 2015 (UTC)
You seem to be confusing what {{convert/doc}} says about separators, but as you say it is not directly applicable here. Why would you be suggesting * as preferred for easily typed units? I would like to see . as the "preferred" unit-multiplier symbol; it is only programmer types who think of *. I think we're fine as is on this, without an explicit "preferred" symbol yet. I would prefer to learn how to use the hidden category system works first. —Quondum 05:14, 31 May 2015 (UTC)
I don't understand, but Jimp understands the proposal. What are we talking about, please, if its not to much to ask? Do you mean a list to choose from? (I found the list of all of Convert's units.) What is the token of your proposed parser, or what is an example of a combinatorial unit or an atom of it? I am confused concerning the mentions of * in the separator context compared to dot and middot, and concerning the ul= not being necessary at times. I don't know the path of Convert Jimp refers to, or the metaphysics of the synergy or mechanism of the resonance of the two templates. — CpiralCpiral 22:41, 31 May 2015 (UTC)
Template:compare/doc talks about a "range separator", and I assumed that this was what you were referring to; a range separator separates quantities, not units within a compound unit.
I would expect to have an easily typed string represent a compound_unit. This would be a list of simple_units separated by '.' and '/'. A simple_unit would be parenthesized of the form (compound_unit), or a prefix–known_unit–numeric_exponent sequence. The numeric_exponent can be unambiguously parsed (an optionally signed integer for now). The prefix is one of the recognized list (SI decimal variants incl. the likes of mu, μ, mc, and IEC binary prefixes like Mi), probably parsed as the longest match that does not include the last character (known_unit cannot be null). What's left can be matched against a list of known_unit. Translation is .→sdot, prefix from standard list (e.g. mu→μ), and known_uint from list (e.g. degC→°C), failing that from convert, failing that unchanged as a literal unit, with constraint to alphabetic only. This may be somewhat ambitious. —Quondum 00:23, 1 June 2015 (UTC)
Already been done? See the stuff around Module:Convert/documentation/conversion_data/doc#SI_prefixes. They use Lua. We have one link to the basic/simple unit's article, and oftentimes a different link to the compound unit. They have aliases, and they can even go to different articles. Completely configurable. — CpiralCpiral 18:25, 2 June 2015 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Val/Archive_3&oldid=1128781773"