localize paginator counter output and CakeNumber::toPercentage

[dereuromark]

Currently L10n is still an issue throughout the core.
There are also different approachs.
One - using setlocale(LC_NUMERIC) I don't like as it creates even more issues and complicates things. Mainly because all the internal output is wrong then (it should stay in the normal numeric format). It also breaks lots of normal echo/output calls where there is also normal non-localized numbers expected.

As clean approach I recommend using two Configure values, L10n.decimals and L10n.thousands.
Those will mainly be used for any user output regarding localized numberic values then.

Resolves:

• https://cakephp.lighthouseapp.com/projects/42648-cakephp/tickets/2927-number_format-in-paginationhelpercounter
• https://cakephp.lighthouseapp.com/projects/42648/tickets/2763-cakenumbertopercentage-should-allow-separator-localization

Long term I can see those values go into other places where localization should use those config values:

• defaults for format/formatDelta (non currency, though)
• toReadableSize

[markstory]

I wonder if it wouldn't be better to have l10n implement the required code to support LC_NUMERIC catalog files. Then each formatting class could use L10n/i18n as required. This would make numeric formatting similar to string and time formatting which also use LC_* catalog files.

[jippi]

👍 to what mark said :)

[dereuromark]

But doesnt that create more internal magic? Can't this have unforseen sideeffects in the code?
PHP expects numbers to be always "dot separated". Some methods internally might then suddenly return "comma separated" values to be processed/stored..

A Configure value and controlled output via CakeNumber::format() does not seem to be that bad compared to that.

Here is something I just stumbled upon: http://www.code-styling.de/english/php-function-setlocale-and-numbers-can-be-damaged.
Same experiences. You often have to output the numbers as non localized ones (e.g. in JS, RSS, data-x HTML5). So you just echo them. This would all be broken then! They would then also need at least a number_format() call to output them as non-localized numbers. Huge overhead compared to the Configure solution I am proposing that only changes values that need/want to be changed.

Easy to say if one doesn't need it.. Anyone who ever tried to work localized with LC_NUMERIC will discover that this is a nightmare. Especially the magic switching of separator/thousands.
I am all ears on how to get this under control - but I as for now I am highly skeptical.

[ravage84]

I can't say much about the issue at hand but you might be interested how different the various formatting can be.
For example in Switzerland, we use 1'234'567.89 (taken from Windows Regions Control):

[markstory]

I'm suggesting we don't use setlocale(). I agree it has a number of a bad/unexpected side effects. Instead what I'm suggesting is extending the L10n/i18n classes to allow formatting of numbers in a region specific manner . One possible API example might be:

// get a formatter
$formatter = L10n::numberFormatter('ja');
$formatted = $formatter->format($number);

This would provide a similar system to ext/intl and our existing translation functions. It might be better to keep things consistent and do

$formatted = I18n::translate($value, null, null, LC_NUMERIC);

This is a gross call signature, but could be wrapped with functions that provide a nicer API.

[dereuromark]

And then let all other methods - including CakeNumber::format() internally use this formatter?
I like L10n:: more, but either one would probably work.

[markstory]

Yes all the other methods including CakeNumber would delegate to l10n/i18n to do formatting.