Page MenuHomePhabricator

Ability to reverse number formatting and detect invalid formats at the same time
Closed, DuplicatePublic

Description

problem:

calling

lang:parseFormattedNumber('1,,,,2,,,,3,,,,4,,,5')

still returns the number 12345, even though it's clearly malformed.
tested with 'en' lang object.

DESIRED RESULT:
using en, both '12345' and '12,345' should be parsed to 12345.
parsing '1,,,,2,,,,3,,,,4,,,5' and '123,45' should return nil, just as parsing '1.2.3' and '123..44' already return nil.

it seems that spaces behave correctly:
' 1' should parse to 1 and does, and '1 1' should and parse to nil and does, so the only issue i found is with commas (in english - maybe similar issue with periods in other languages).

peace.

Event Timeline

Kipod created this task.Mar 31 2016, 6:03 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 31 2016, 6:03 PM
Jackmcbarn added a subscriber: Jackmcbarn.

All parseFormattedNumber does is call Language::parseFormattedNumber in core, so this isn't Scribunto-related at all.

Jackmcbarn renamed this task from scribunto mw.language:parseFormattedNumber() is too lax to Language::parseFormattedNumber is too lax.Mar 31 2016, 7:24 PM
Kipod added a comment.Apr 2 2016, 5:52 PM

are there pieces in the system that use Language::parseFormattedNumber in core other than scribunto? what for? which of them will break if this call will become stricter? (as i believe it should)?

peace.

In core, the formatnum and plural parser functions use it.

Language::formatNum and Language::parseFormattedNumber are solely intended for use for formatting numbers in the user interface (and the reverse is needed for the plural magic word). They are not generic number formatters or parsers – that functionality should be implemented somewhere else.

Kipod added a comment.Apr 7 2016, 10:16 PM

Language::formatNum and Language::parseFormattedNumber are solely intended for use for formatting numbers in the user interface (and the reverse is needed for the plural magic word). They are not generic number formatters or parsers – that functionality should be implemented somewhere else.

not sure what you mean by "solely intended". maybe someone, at some point, intended all kind of stuff.

today this package is used for more things than what you claim to be the "sole intention". either scribunto should avoid using it (which would be silly, IMO), or the package should behave sanely. parsing "1,,,,3,,,,5.7" as 135.7 does not meet this standard.

peace.

Nemo_bis renamed this task from Language::parseFormattedNumber is too lax to Ability to reverse number formatting and detect invalid formats at the same time.Apr 8 2016, 6:34 AM
Nemo_bis added a subscriber: Nemo_bis.

I've changed the summary to reflect what appears to be your goal.

For all practical purposes, this is a duplicate of T37922. See there on why the parser isn't aware of all possible formats in all languages simultaneously.

Kipod added a comment.Apr 11 2016, 7:24 PM

@Nemo_bis : i looked at T37922, and they do not look to be the same. the other ticket is about "formatNum", this one is about "parseFormattedNum().

also, changing "parseFormattedNumber" to "reverse number formatting" does not make it clearer - it makes it murkier.

this report was about scribunto mw.language package. @Nikerabbit claims above that Language::parseFormattedNumber should not even be used by scribunto, which is fine by me. all i need is a parser that accepts 123,456.12 as the number 123456.12, but will reject 12,3,4,5,6.12, or even 1234,56.12.
of course, this should be language dependent vis-a-vis comma/period, and digit characters.

bottom line: i do not think this report is a duplicate of the other, and i don't think your rewording of the title was an improvement.

peace.