Page MenuHomePhabricator

formatnum can deformat numbers only if they're in English format
Closed, InvalidPublic

Description

When using the Romanian locale, inputing an already formatted number converts it to English separators (i.e. replaces dots with commas and commas with dots).

On mediawiki.org it is recommended to use formatnum twice in you don't know the input.

See https://ro.wikipedia.org/wiki/Utilizator:Strainu/formatnum for some examples


Version: unspecified
Severity: enhancement

Details

Reference
bz35922

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:15 AM
bzimport set Reference to bz35922.
bzimport added a subscriber: Unknown Object (MLST).

Garbage in, garbage out. There is no way knowing whether 4,456 is a big or small number.

I would not recommended using formatnum twice.

(In reply to comment #1)

There is no way knowing whether 4,456 is a big or
small number.

I disagree. The locale should prevail. So in Romanian, 4,456 is about 4 and a half and in English it's 4 thousands 4 hundred and fifty six.

(In reply to comment #1)

I would not recommended using formatnum twice.

Then the docs should be updated.

This is particularly useful for formatnum used inside templates - the user writes 4.456 without knowing there is a formatnum somewhere inside and the totally unexpected result is 4,456.

(In reply to comment #2)

(In reply to comment #1)

There is no way knowing whether 4,456 is a big or
small number.

I disagree. The locale should prevail. So in Romanian, 4,456 is about 4 and a
half and in English it's 4 thousands 4 hundred and fifty six.

(In reply to comment #1)

I would not recommended using formatnum twice.

Then the docs should be updated.

That line has been added only recently and is not a "recommendation" but the documentation of a hack, not recommended nor reliable as Niklas says. If this is not clear please change its language.
http://mediawiki.org/wiki/Help:Magic_words

This is still not a reason to close the bug as invalid. There are algorithms (and not that complicated) to determine the value of a number.

I do not know who changed the bug title but it is misleading. Formatnum is always able to reverse the formatting of a properly formatted number, but it only works with one locale at a time.

The only valid input for formatnum is plain whole or decimal number. Output for everything else can be anything as far as I am concerned. Formatnum is and will stay as a simple number formatter, mainly to be used in interface message translations. Anything more complicated should be implemented somewhere else.

Nemo changed it. I've done some more testing at https://ro.wikipedia.org/wiki/Utilizator:Strainu/formatnum and in order to obtain what I want, I have to do {{formatnum:{{formatnum:1,234.56|R}}}}

So, I propose the following:

  1. Name the bug "formatnum should reverse formatting on the input before processing the number"
  2. mark it as an enhancement
  3. update http://mediawiki.org/wiki/Help:Magic_words to mention this instead of the "hack" that I still don't see when it works.

(In reply to comment #6)

I do not know who changed the bug title but it is misleading. Formatnum is
always able to reverse the formatting of a properly formatted number, but it
only works with one locale at a time.

What do you mean? And are we talking of the function or of the magic word?
The new summary may be misleading, what I mean is that currently there's no way to use the magic word to reverse the formatting of a number which is in the format used by formatnum e.g. on fr and it (spaces or points between thousands), it can only deformat from English locale. Is the new summary better?

(In reply to comment #7)

  1. Name the bug "formatnum should reverse formatting on the input before

processing the number"

Doesn't look like a good idea.

(In reply to comment #8)

(In reply to comment #7)

  1. Name the bug "formatnum should reverse formatting on the input before

processing the number"

Doesn't look like a good idea.

Why not? This way, numbers in the current locale will be handled correctly, while numbers in other locale will be GIGO and will stand out when viewing the page, increasing the chances of being fixed.

This is very strange: https://es.wikipedia.org/w/index.php?title=Usuario:Ciencia_Al_Poder/Taller&oldid=83325521

  • {{formatnum:123456.78}} --> Convert from invariant format to current locale
  • {{formatnum:{{formatnum:123456.78}}|R}} --> Convert from invariant format to current locale, and then do the reverse. We get the input of first example (OK)
  • {{formatnum:123 456,78|R}} --> Convert from current locale (taking the output of first example) to invariant. We should get the input of first example but it doesn't change the input!

{{formatnum:123 456,78|R}} --> Convert from current locale (taking the output of first example) to invariant. We should get the input of first example but it doesn't change the input!

Are you sure you used a non-breaking space?

Hello,
using   or   does not solve the problem, as it can be seen in my sandbox (nor &ensp or &emsp):

{{formatnum:987 654,321|R}} outputs 987 654.321
{{formatnum:987 654,321|R}} outputs 987 654.321

Try unicode nbsp. {{formatnum:|R}} is really just thought for stuff output by other parser functions, I'd say.

Ok, it works fine with the Unicode character U+00A0. Thanks