Page MenuHomePhabricator

Language::formatNum() should prefix negative values with − (minus sign U+2212)
Open, LowestPublic

Description

Author: robchur

Description:
Some users are complaining that negative values, when formatted, have a "-" prefix, as opposed to the "more correct −".

Details

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 9:29 PM
bzimport set Reference to bz8327.
bzimport added a subscriber: Unknown Object (MLST).

robchur wrote:

Proposed patch

This patch fixes the issue in a brute-force manner, but I didn't want to commit
it without some review, since I'm sure there's going to be a regression in
behaviour somewhere if I do.

Attached:

Er, sounds like bullshit to me?

christian.kaul wrote:

(In reply to comment #2)

Er, sounds like bullshit to me?

Are you kidding?

brion added a comment.Dec 20 2006, 6:42 AM

No?

  1. What would be the benefit?
  1. With patch as written, negative numbers would be corrupted when output as

plain text, certainly a regression in behavior.

(In reply to comment #0)

Some users are complaining that negative values, when formatted, have a "-"
prefix, as opposed to the "more correct −".

What is being done with these values? One would suspect that if fed to ParserFunctions
like {{#expr}} the latter would choke...

christian.kaul wrote:

Isn't it possible to show a minus but to calculate with the "-" form?

leon wrote:

As this bug has been reported due to complaints about the change size value on
recentchanges, I've commited r18468 as a workaround until this one's fixed.

ayg wrote:

(In reply to comment #4)

  1. What would be the benefit?

More professional-looking output? (Admittedly, only to the 5–10% of people who
would notice.)

  1. With patch as written, negative numbers would be corrupted when output as

plain text, certainly a regression in behavior.

UTF-8 would be the more reasonable thing to output it as. The function should
certainly have a switch to determine whether it should output hyphens or
minuses, though, not always return minuses.

robchur wrote:

I favour Leon's method, instead; this should be altered for display only, and
the output of Language::formatNum() left alone.

broken.arrow wrote:

(In reply to comment #7)

As this bug has been reported due to complaints about the change size value on
recentchanges, I've commited r18468 as a workaround until this one's fixed.

Assuming it's not intentional, r18468 has introduced a typo in the class name
"mw-pluminus-bold"; "mw-pluminus-neg" had the same typo from earlier on. This is
inconsistent with the names of the two other classes, "mw-plusminus-pos" and
"mw-plusminus-null".

ayg wrote:

(In reply to comment #10)

(In reply to comment #7)

As this bug has been reported due to complaints about the change size value on
recentchanges, I've commited r18468 as a workaround until this one's fixed.

Assuming it's not intentional, r18468 has introduced a typo in the class name
"mw-pluminus-bold"; "mw-pluminus-neg" had the same typo from earlier on. This is
inconsistent with the names of the two other classes, "mw-plusminus-pos" and
"mw-plusminus-null".

Fixed in r18471, thanks for pointing it out (although a new bug report would
have been preferable).

Have reverted r18468, as it doesn't appear to accomplish anything at all and the
whole subject seems rather silly.

Not a single reason for fulfilling this request has been given, which makes me
consider it a huge waste of time.

Resolving WONTFIX.

christian.kaul wrote:

The God Emperor of MediaWiki has spoken.

ayg wrote:

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

Tgr added a comment.Nov 19 2007, 10:23 AM

Should be easy to simulate with something like this:

{{#ifexpr:{{{1}}}<0|&minus;{{formatnum:{{#expr:-{{{1}}}}}}}|{{formatnum:{{{1}}}}}}}

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

mr.heat wrote:

Reopening. Yes, the hyphen-minus (U+002D) is a common replacement for the minus sign (U+2212). But since we are using Unicode everywhere I don't see a reason why the {{formatnum:}} parser function should not do the same. Why does it need to be ASCII compatible? See http://en.wikipedia.org/wiki/Hyphen-minus for more details.

You can not use the output of a {{formatnum:}} call in an {{#expr:}} anyway. Stuff like {{#expr: {{formatnum:12345}} / 1000}} does not work anyway no matter which character is used. Depending on the language it causes an expression error (if your languages uses commas for digit grouping) or prints "0,012345" instead of "12,345" (if your languages uses dots for digit grouping).

That said I don't see a reason why {{formatnum:-12345}} can not use the proper minus sign. It can't break existing code because, as I said, {{formatnum:}} can not be used inside other parser functions.

Currently we are using code like {{#ifexpr: number < 0 | &#x2212;{{formatnum: {{#expr: abs number }} }} | {{formatnum: number }} }}. This code will not break if {{formatnum:}} uses the proper minus sign.

p.selitskas wrote:

(In reply to comment #17)

Reopening. Yes, the hyphen-minus (U+002D) is a common replacement for the minus
sign (U+2212). But since we are using Unicode everywhere I don't see a reason
why the {{formatnum:}} parser function should not do the same. Why does it need
to be ASCII compatible? See http://en.wikipedia.org/wiki/Hyphen-minus for more
details.

You can not use the output of a {{formatnum:}} call in an {{#expr:}} anyway.
Stuff like {{#expr: {{formatnum:12345}} / 1000}} does not work anyway no matter
which character is used. Depending on the language it causes an expression
error (if your languages uses commas for digit grouping) or prints "0,012345"
instead of "12,345" (if your languages uses dots for digit grouping).

That said I don't see a reason why {{formatnum:-12345}} can not use the proper
minus sign. It can't break existing code because, as I said, {{formatnum:}} can
not be used inside other parser functions.

Currently we are using code like {{#ifexpr: number < 0 | &#x2212;{{formatnum:
{{#expr: abs number }} }} | {{formatnum: number }} }}. This code will not break
if {{formatnum:}} uses the proper minus sign.

Totally agree. {{formatnum}} (and a PHP method on its back) is a presentation-level function, and it won't be used in {{#expr}} and other calculations by any means. It is just this function's nature to be used the last, when the resulting value is done.

I also checked against pasting the negative value with the Unicode minus into Windows' Calculator, and it all worked just fine. Perhaps, Gnome/KDE/... calculators do so as well.

(In reply to comment #18)

I also checked against pasting the negative value with the Unicode minus into
Windows' Calculator, and it all worked just fine. Perhaps, Gnome/KDE/...
calculators do so as well.

Gnome's probably does, while KCalc has problems even for handling input with dots as thousands separator; but all this should indeed not affect this feature request.

putnik added a subscriber: putnik.Dec 8 2017, 1:19 AM
putnik awarded a token.Dec 8 2017, 1:22 AM

This is still a problem, at least with the population estimate in the infobox of https://en.wikipedia.org/wiki/Novgorod_Oblast .

Koavf added a comment.Jun 22 2020, 5:58 AM

To be clear, the infobox Doc just mentioned uses < - >, which is the hyphen-minus character: https://en.wikipedia.org/wiki/Hyphen-minus rather than < − >, the minus sign: https://en.wikipedia.org/wiki/Plus_and_minus_signs#Minus_sign

To be clear, the infobox Doc just mentioned uses < - >, which is the hyphen-minus character: https://en.wikipedia.org/wiki/Hyphen-minus rather than < − >, the minus sign: https://en.wikipedia.org/wiki/Plus_and_minus_signs#Minus_sign

Oh, okay. (I'd still like the minus sign to be used.) (I was referred here by https://www.mediawiki.org/wiki/Help_talk:Extension:ParserFunctions/2014-2020#Request:_Implement_minus_sign_for_negative_numbers_(#expr,_etc.) , which popped up in my notices tonight.)

Koavf added a comment.Jun 22 2020, 6:05 AM

Agreed: minus should be used, not hyphen-minus. I was just clarifying for others who can't obviously tell which figure is in the infobox.

Well, I couldn't either. <chuckles>

Bump. I just ran into this again on another Wikipedia article, https://en.wikipedia.org/wiki/Novgorod_Oblast . Or given my editing history, probably the same article.

Tacsipacsi updated the task description. (Show Details)Wed, Oct 21, 11:09 AM
Tacsipacsi added a subscriber: Tacsipacsi.
cscott added a subscriber: cscott.Wed, Oct 21, 1:22 PM

I'd support changing the output of {{formatnum}} to use U+2212 minus. This will probably break a bunch of pages which pass the output of formatnum back to expr but as T10327#126094 says this is broken anyway for (a) fractional values when user preference is for comma as decimal separator, (b) values greater than 100 when locale specifies two-digit grouping, (c) values greater than 1000. Adding "(d) when value is negative" may actually prompt needed cleanup.

Discussion arose in T237467: Invariant failed: Bad UTF-8 (full string verification) which added warnings for various bits of non-numeric input to {{formatnum}} in the process of un-breaking some non-US/non-Euro wikis which were passing garbage to commafy and ending up with bad UTF-8 as a result.

Change 635546 had a related patch set uploaded (by C. Scott Ananian; owner: C. Scott Ananian):
[mediawiki/core@master] Use Unicode minus in output of {{formatnum}}

https://gerrit.wikimedia.org/r/635546

Daimona added a subscriber: Daimona.

I believe this should be mentioned in Tech News once approved.

I believe this should be mentioned in Tech News once approved.

I added a mention to this week's Tech News as a future change. There are other refactorings to {{formatnum}} rolling out on the next train, so I'd prefer not to complicate that deploy by merging this, but I'd consider this for 1.36.0-wmf.18 (Nov 17-19) if no one objects before then.