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 −".


Version: unspecified
Severity: normal
URL: http://de.wikipedia.org/wiki/Special:Recentchanges

Details

Reference
bz8327

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 9:29 PM
bzimport added a project: MediaWiki-Interface.
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