Proper number formatting related to i18n

[honza.skypala]

Hi there,

Technical description of the situation: WordPress function number_format_i18n() uses native PHP function number_format() for formatting numbers. Unfortunately this PHP function is not able to handle separators (both decimal and thousands separators) that fall into one of the following categories:

• separator would contain more than one char, e.g. " "; in this case only the first char from the supplied string is used, in the example given above it would be "&".
• separator is ASCII > 128, e.g. ASCII 160;

Impact: Although this is not a native bug to WordPress, the problem source is in PHP, the impact is caused also in WordPress. This situation is problematic for users in Eastern Europe (Czech Republic, Russia, etc.) where the standard thousands separator is " " (space). The users in these countries usually don't want to use real space (ASCII 32) as thousands separator, as it could be word wrapped and the number would be saparated into two lines. Unfortunatelly supplying both variants of non-breakable space (i.e. " " or ASCII 160) fails.

Proposed solution: unforunatelly this bug is reported in PHP for years and nothing happens there. Because of this situation I suggest fixing such problem in the next level, i.e. in WordPress. This means to create a custom function for formatting numbers, with identical input params as number_format(), just that this one would be able to handle separator types mentioned above.

I have such change already deployed on my WordPress blog for several months, so I am going to attach a diff file for the latest SVN state dealing with this issue.

Honza

Diff solving the issue described in the ticket.

Given the very specific nature of the problem it might make more sense to just do:

$number = str_replace(' ', ' ', $number);

where we use it...

Cross reference #10555

I agree with Denis that in this specific case translators should add a number_format_i18n filter in the <locale>.php file and fix the problem there. I vote for wontfix.

One day I will start deleting milestones, too.

Replying to nbachiyski:

I agree with Denis that in this specific case translators should add a number_format_i18n filter in the <locale>.php file and fix the problem there. I vote for wontfix.

What do you mean by <locale>.php file?

If you put a php file named after your locale in wp-content/languages/ it will be loaded automatically if the current locale matches the basename of the php file.

You can use it like a locale-specific plugin.

OK, thank you. So, my file will be cs_CZ.php and it works the same way as usual plugin? Any required header? Is it documented somewhere? And one more question - how can I distribute it with translated Czech version? Can I insert it to dist folder, for example ​http://svn.automattic.com/wordpress-i18n/cs_CZ/trunk/dist/? In dist folder I will create folder structure with this file dist/wp-content/languages/cs_CS.php? Thank you very much for your answers...

Yes, it works like a plugin. You don't need anything special. Putting it in dist/ is perfcetly fine. Here is mine, for example:

​http://svn.automattic.com/wordpress-i18n/bg_BG/trunk/dist/wp-content/languages/bg_BG.php

Great. I was not sure... Thank you for your help!

PHP 5.4.0 allows multiple bytes to be used for decimal points and thousands separators. Of course, we won't have 5.4.0 as a minimum version requirement for probably a decade. I am re-opening this to reflect our decision to begin incorporating locale-specific changes in core. (#19603, others.)

Which locales specifically need multiple characters to properly represent numbers?

For example Czech and probably also other languages with "space" as thousands separator (non-breakable space needed).