Page MenuHomePhabricator

New parser function / magic word, for "pretty-printed" numbers
Open, LowPublic


Author: random832

This is a request for a variant on "formatnum:" called "delimitnum:" which will include in its output span tags that can have a margin set on them to enable spaces to visually appear between digit groups to the right of the decimal point while not causing them to be in the resulting string when the number is selected and copied.

Each group of three digits, and a final group of two, three, or four digits, following the decimal point, should be output in a <span class="digitgroup"> tag, which should have a default style of .digitgroup { margin-left:0.25em }.

Multiple span tags are closed at the end of the number.

By "final group of two, three, or four digits", the following is meant:
1.234 56
1.234 567
1.234 5678
1.234 567 89

The following additional parameters are also requested, in addition to the value to be formatted in the first parameter:
Second parameter - uncertainty (output in parentheses after the number if present)
Third parameter - power of ten (output &nbsp;×&nbsp;10<sup>{{{3}}}</sup> after the number and uncertainty if present)
Fourth parameter - unit (output &nbsp;{{{4}}} if present)

So, the code
would have markup output of
1.356<span class="digitgroup">392</span><span class="digitgroup">733</span>(30)&nbsp;×&nbsp;10<sup>32</sup>&nbsp;Hz
and the visual appearance of
1.356 392 733(30) × 10³² Hz

Discussion towards consensus for the use of this feature on enwiki can be found at:

And an overview of the proposal being discussed can be found at:

The above-linked overview does not go into detail about where the span tags would be closed, and many of the examples provided there are not well-formed markup; I felt that having them surround each individual digit group (rather than all closing at the end of the numeric output, or at the end of the output of the tag) provides the most flexibility for user styles. This choice does not make any difference for the default appearance, as the default style proposed contains only a left margin.

The overview also does not propose the 'class="digitgroup"' convention, instead simply showing examples of tags with inline styles. However, it is better practice to use a class and control the specific styles with stylesheets so that users may override this style in their own user css.

Version: unspecified
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:07 PM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz13025.
bzimport added a subscriber: Unknown Object (MLST).

random832 wrote:

Sorry; the statement "Multiple span tags are closed at the end of the number." above is not consistent with my later statement or example output that the span tag should be closed after each digit group. I'd had trouble deciding which to recommend while writing up this bug report.

random832 wrote:

There needs to be an additional class for digit groups where the digit preceding the group is a "1", so that a different margin width (0.2em by default) can be applied to these.

Greg_L_at_Wikipedia wrote:

The parser function delimits on both sides of the decimal marker. Thus,

::: <code><font color ="maroon"><nowiki>{{delimitnum:1579800.298728}}</nowiki></code></font color> → 1,579,800.298<span style="margin-left:0.25em">728</span>

:::other examples are…

::: <code><font color ="maroon"><nowiki>{{delimitnum:6.02214179|30|23|kg}}</nowiki></code></font color> → 6.022<span style="margin-left:0.25em">141<span style="margin-left:0.2em">79(30)</span>&nbsp;×&nbsp;10<sup>23</sup>&nbsp;kg

::: <code><font color ="maroon"><nowiki>{{delimitnum:1.356392733||50|Hz}}</nowiki></code></font color> → 1.356<span style="margin-left:0.25em">392<span style="margin-left:0.25em">733</span>&nbsp;×&nbsp;10<sup>50</sup></span>&nbsp;Hz

::: <code><font color ="maroon"><nowiki>{{delimitnum:0.45359237|||kg}}</nowiki></code></font color> → 0.453<span style="margin-left:0.25em">592<span style="margin-left:0.25em">37</span>&nbsp;kg

Greg_L_at_Wikipedia wrote:

Well, that didn’t work. That first example would appear as follows.

{{delimitnum:1579800.298728}} → 1,579,800.298 728

random832 wrote:

Right, it delimits to the left of the decimal point with commas. I thought this was implicit in calling it a variant of formatnum.

Sj added a comment.Mar 4 2008, 1:35 AM

This is a great idea. Bravo...

an example function for the problem

Instead of trying to separate the data into different field, I tried to take the approach to parse a given string instead, a test case for this function gave:

input: 12,123,4534524.23456 4335 346346 3335(23)*10^23 km
output: 121,234,534,524.234<span style="margin-left:0.25em">564</span><span style="margin-left:0.25em">335</span><span style="margin-left:0.25em">346</span><span style="margin-left:0.25em">346</span><span style="margin-left:0.25em">3335</span>(23)&nbsp;×&nbsp;10<sup>23</sup>&nbsp;km
input: .1
output: .1
input: .12
output: .12
input: .123
output: .123
input: .1234
output: .1234
input: .12345
output: .123<span style="margin-left:0.25em">45</span>

(span/margins/nbsps converted to spaces for clarity):

input: 12,123,4534524.23456 4335 346346 3335(23)*10^23 km
output: 121,234,534,524.234 564 335 346 346 3335(23) × 1023 km
input: .1
output: .1
input: .12
output: .12
input: .123
output: .123
input: .1234
output: .1234
input: .123 45
output: .123 45


Comment on attachment 4694
an example function for the problem


Greg_L_at_Wikipedia wrote:

I created a little custom sandbox for the developer on my home page. It features a variety of proof-check exercises for this parser function. It can be helpful for evaluating the proper functioning of various features of this parser function. It is here at…

I created this proof-check sandbox for another editor who has created a template, also titled "delimitnum", for doing the very same thing as this parser function. Note that I did not solicit this, he kindly took it upon himself to do this on his own.

Greg_L_at_Wikipedia wrote:

Discussion regarding a formal MOSNUM policy on the use of this parser function and the template by the same name is ongoing at the following section of Talk:MOSNUM:

Greg_L_at_Wikipedia wrote:


I’ve moved the proof-checking sandbox to its own separate user page, at…

Greg_L_at_Wikipedia wrote:

A Wiki editor pointed out that {delimitnum|1.1200|25} should return 1.1200(25), not 1.12(25)

I wanted to make sure that no trailing zeros in the significand are truncated if the uncertainty pipe has a value in it.

Greg_L_at_Wikipedia wrote:

An entirely separate discussion got going on a new venue…

…(not Talk:MOSNUM, but Talk:MOS) where spacing on both sides of the × (times) symbol with other templates was being discussed.

So far, I’ve been careful to insulate you from changes but I hope you will find this one easy to implement as it is a good idea and will make this magic word a more attractive, widely accepted tool.

Could you please put span-based gaps on both sides of the × symbol instead of non-breaking spaces. In order to appear balanced across all platforms, the spans must be asymmetrically specified (0.30 em to the left and 0.15 em to the right), as follows:

<span style="margin-left:0.3em">×<span style="margin-left:0.15em">

Greg_L_at_Wikipedia wrote:


I realized something that you may already have figured out on your own.

{{delimitnum|1.1200|25||kG}} should return 1.1200(25) kg and {{delimitnum|1.1200|||kg}} should return 1.1200 kg.

In other words, regardless of whether the ‘uncertainty’ pipe has a value in it or not, your magic word shouldn't have to ever worry abut truncating trailing zeros under any circumstances. This responsibility must be in the hands of the editors in order that they can control the displayed precision of expressions.

random832 wrote:

If it would hepl get this done, can we get rid of the other stuff and have it _just_ take the first parameter and put in the commas on the left and the margin spans on the right? The other stuff can be dealt with in a template, or several templates.

  • Bug 16273 has been marked as a duplicate of this bug. ***
  • Bug 17659 has been marked as a duplicate of this bug. ***

(In reply to comment #17)

  • Bug 16273 has been marked as a duplicate of this bug. ***

Then I'll write here: I understand that formatnum is not meant to handle
complex situations (see bug 17659#c2) and it is used primarily in user
messages where numbers are integers, but I can't understand why where it's
configured to use the non-breaking space as separator of groups of digit (e.g., which obviously follows what the Bureau international des poids et
mesures states: it has an
inconsistent output (as reported in bug 18957#c15): {{formatnum:1234.5678}}
currently gives 1&nbsp;234,5678 instead of 1&nbsp;234,567&nbsp;8.

(In reply to comment #16)

The other stuff can be dealt with in a template, or
several templates.

Yes. The priority is to resolve the current inconsistencies: bug 17659#c2, bug
8327, bug 10454.

Greg_L_at_Wikipedia wrote:

For use on en.Wikipedia, this bug request (“formatnum”) became template:delimitnum and later to the product currently used on en.Wikipedia, which is template:val. {Val} follows the practice widely recognized in the English-speaking world of delimiting numbers to the left of the decimal point with commas and also follows the practice recommended by the U.S. Government Printing Office Style Manual…


…of using narrow gaps to the right of the decimal point.

If these latest threads pertain to en.Wikipedia, then the straightforward answer is that the English-speaking countries don't follow the BIPM-recommended practice for delimiting numbers; it follows the real-world practices observed by native-English-speaking readers.

If this latest thread is for a tool for fr.Wikipedia, then… “sorry for bothering you.” It wasn’t clear from the above as to where this tool is supposed to be used that you are working on.

(In reply to comment #20)

If this latest thread is for a tool for fr.Wikipedia, then… “sorry for
bothering you.” It wasn’t clear from the above as to where this tool is
supposed to be used that you are working on.

I'm from, and for complex values we use [[w:it:template:M]] which is the counterpart of [[template:Val]]. I don't think that the original request of this bug is desirable, and I don't want to follow international conventions, but I think that we should resolve the inconsistencies of the output of formatnum as it is used currently (i.e. in articles, not only in system messages). Since the requests to correct formatnum itself have been redirected here, I'm requesting that here.

Looks like a crazy template implementation has just been adopted on for some things:

Wikini added a subscriber: Wikini.Jun 25 2015, 9:41 AM