Last modified: 2014-09-06 09:22:13 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 8327 - Language::formatNum() should prefix negative values with − (minus sign U+2212)
Language::formatNum() should prefix negative values with − (minus sign U+2212)
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
unspecified
All All
: Lowest normal with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://de.wikipedia.org/wiki/Special:...
:
: 12029 35146 (view as bug list)
Depends on: 13025
Blocks: 38579
  Show dependency treegraph
 
Reported: 2006-12-19 23:27 UTC by Rob Church
Modified: 2014-09-06 09:22 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Proposed patch (426 bytes, patch)
2006-12-19 23:28 UTC, Rob Church
Details

Description Rob Church 2006-12-19 23:27:31 UTC
Some users are complaining that negative values, when formatted, have a "-"
prefix, as opposed to the "more correct −".
Comment 1 Rob Church 2006-12-19 23:28:35 UTC
Created attachment 2907 [details]
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.
Comment 2 Brion Vibber 2006-12-20 00:22:46 UTC
Er, sounds like bullshit to me?
Comment 3 Carbidfischer 2006-12-20 06:17:08 UTC
(In reply to comment #2)
> Er, sounds like bullshit to me?

Are you kidding?
Comment 4 Brion Vibber 2006-12-20 06:42:15 UTC
No?

1) What would be the benefit?

2) With patch as written, negative numbers would be corrupted when output as
plain text, certainly a regression in behavior.
Comment 5 Phil Boswell 2006-12-20 09:16:41 UTC
(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...
Comment 6 Carbidfischer 2006-12-20 14:16:19 UTC
Isn't it possible to show a minus but to calculate with the "-" form?
Comment 7 Leon Weber 2006-12-20 16:39:26 UTC
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.
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-12-20 18:48:18 UTC
(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.)

> 2) 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.
Comment 9 Rob Church 2006-12-20 18:54:09 UTC
I favour Leon's method, instead; this should be altered for display only, and
the output of Language::formatNum() left alone.
Comment 10 Broken Arrow 2006-12-20 21:38:13 UTC
(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".
Comment 11 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-12-20 21:55:08 UTC
(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).
Comment 12 Brion Vibber 2006-12-20 22:09:04 UTC
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.
Comment 13 Carbidfischer 2006-12-22 13:38:31 UTC
The God Emperor of MediaWiki has spoken.
Comment 14 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-11-18 22:29:36 UTC
*** Bug 12029 has been marked as a duplicate of this bug. ***
Comment 15 Tisza Gergő 2007-11-19 10:23:00 UTC
Should be easy to simulate with something like this:

{{#ifexpr:{{{1}}}<0|&minus;{{formatnum:{{#expr:-{{{1}}}}}}}|{{formatnum:{{{1}}}}}}}
Comment 16 Mark A. Hershberger 2012-03-12 16:20:49 UTC
*** Bug 35146 has been marked as a duplicate of this bug. ***
Comment 17 TMg 2012-11-27 12:17:27 UTC
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.
Comment 18 Pavel Selitskas [wizardist] 2012-11-27 12:41:01 UTC
(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.
Comment 19 Nemo 2012-11-27 12:45:08 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links