We want to eliminate explicit calls to setlocale() because of (1) locale-related php 5.2.x bugs with json_encode/json_decode, and (2) compatibility with multithreaded servers.
The locale information is maintained per process, not per thread. If you are running PHP on a multithreaded server API like IIS or Apache on Windows, you may experience sudden changes in locale settings while a script is running, though the script itself never called setlocale(). This happens due to other scripts running in different threads of the same process at the same time, changing the process-wide locale using setlocale().
The L10N class could potentially handle:
possibly on a per translation / site / user basis.
It would be great indeed to have float format feature, possibly date/time format (but it seems lot more complicated since dates are everywhere).
(1) json_encode locale bug: is it still an issue even after your recent json_encode updates?
(2) compatibility with multithreaded servers
In the case of low traffic website, concurrency locale settings would not matter since there would be few concurrent users.
When piwik runs on high traffic website, it is often the only php app runnin on the box, so this is not a big issue neither.
I wonder about Shared hosting though, if a server runs for example 10 piwik with different locales.. I suppose shared hosts use a technique around this and have already fixed this problem maybe?
(1) will still be an issue; with the implementation of a L10N class, Piwik would no longer call setlocale().
(2) I believe this is mostly an issue with older PHP builds on Windows, since newer versions of PHP (5.3.6 and above) have a compile-time setting for per-thread-locale.