@hpvd opened this Issue on July 13th 2016

Show always same number of decimal digits (123.X) - even if "0"
otherways having no decimal digits on may think these values are rounded in another way...

hmm thought this was already solved some time ago?

Please see attachements

2016-07-13_10h28_27

2016-07-13_10h31_14

@tsteur commented on July 14th 2016 Owner

👍

@tsteur commented on July 14th 2016 Owner

this visualization may use a custom template so it might not have been solved there, just a guess

@hpvd commented on July 15th 2016

looking again at the screenshots above, just found another tiny issues:
alignment broken in movers and shakers widget #10308

@obax commented on October 4th 2017

I can make this quick fix. Would you assign this to me?

@mattab commented on October 4th 2017 Owner

Hi @obax we don't assign issues, you can just create a Pull Request and reference this one :+1:

@Morerice commented on October 15th 2017 Contributor

In NumberFormatter::formatNumberWithPattern() there is this snippet in the final parts of the function, which ensures that the number does at least have the minimum number of fraction digits:

if ($minimumFractionDigits < $maximumFractionDigits) {
    // Strip any trailing zeroes.
    $minorDigits = rtrim($minorDigits, '0');
    if (strlen($minorDigits) < $minimumFractionDigits) {
        // Now there are too few digits, re-add trailing zeroes
        // until the desired length is reached.
        $neededZeroes = $minimumFractionDigits - strlen($minorDigits);
        $minorDigits .= str_repeat('0', $neededZeroes);
    }
}

Currently, if the minimum and maximum digits are equal, this is not executed and the value is rounded based on the maximum using the round() function.

The special case arises when the round() function has a whole number as its first parameter because this function does not add the decimal points. I'm guessing this was known when the formatter was developed because of this test in NumberFormatterTest: ('en', -50, 3, 3, '-50%').

Imo if the minimum = maximum it implies that the decimal point accuracy should be exactly as the number provided: ('en', -50, 3, 3, '-50.000%'). Would you agree with this?

Powered by GitHub Issue Mirror