Localization of numbers should be supported

[huji]

I'm new to WordPress so please bear with me: I believe localization of numbers should be added to WordPress features. This means that, if you install WordPress and use (for example) Arabic language packs, numbers should be shown using Arabic digits, not English digits.

Arabic digits = English digits.

Arabic digits are already internationalized.

However, you are correct that different languages do use also different characters for numbers.

Let me make myself clear: This internationalization should be global. I have installed WordPress and added Persian language pack; digits in the blog posts and post dates are converted correctly, but digits in the administration pages are still Roman.

I think the problem with it is that, it would add additional overhead for each number. There are quite a few times where numbers are passed to localized strings expecting to still be Roman. I'm not sure this is something that could be implemented easily.

What you ask for has repercussions for how WordPress currently handles numbers and how it will handle numbers in the future. The current framework probably would need to be extended or replaced.

It will help if a patch were available. I am most likely wrong, since I don't specialize in i18n, all of my sites are in (American) English.

There is ​number_format_i18n(); however that only handles locale's having different decimal points and thousand seperators

I wasnt aware that front-end numbers are translated.. If they are, then i dont really see any reason why backend numbers couldnt get the same treatment.

DD32,

I think he was talking about the themes and, or the blogger that is supported by the unicode language in MySQL.

I haven't reviewed WordPress code totally, but from what I've seen so far, there is no native way used for conversion of numbers by default. For example, Persian language pack uses its own functions to convert numbers, decimal points, etc. (Find it in wp-jalali plugin files).

I have to disagree with the issue about overhead (or caching even). When correctly programmed, i18n of numbers wouldn't be such a problem. A seriously bigger project, "MediaWiki", is using this feature from long before without any difficulties.

Related: #7753

See in particular: http://core.trac.wordpress.org/ticket/7753#comment:13

Also this patch:

http://core.trac.wordpress.org/attachment/ticket/7753/7753.2.diff

But what's really needed to make it work is an overhaul of the workflow. Imo, both of the tickets should get closed as wontfix.