Last modified: 2014-09-06 09:22:13 UTC
Some users are complaining that negative values, when formatted, have a "-" prefix, as opposed to the "more correct −".
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.
Er, sounds like bullshit to me?
(In reply to comment #2) > Er, sounds like bullshit to me? Are you kidding?
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.
(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...
Isn't it possible to show a minus but to calculate with the "-" form?
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.
(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.
I favour Leon's method, instead; this should be altered for display only, and the output of Language::formatNum() left alone.
(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".
(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.
The God Emperor of MediaWiki has spoken.
*** Bug 12029 has been marked as a duplicate of this bug. ***
Should be easy to simulate with something like this: {{#ifexpr:{{{1}}}<0|−{{formatnum:{{#expr:-{{{1}}}}}}}|{{formatnum:{{{1}}}}}}}
*** Bug 35146 has been marked as a duplicate of this bug. ***
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 | −{{formatnum: {{#expr: abs number }} }} | {{formatnum: number }} }}. This code will not break if {{formatnum:}} uses the proper minus sign.
(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 | −{{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.
