PHP provides the function number_format to format numbers with decimal points and thousands separator. Actually, if there was a way, in Drupal, to customize this function at site/user levels... :-)

I believe this is not so difficult to implement. All we needs is add a couple of fields to allow admins/users customize these options (decpoint/thsndsep) to admin/settings and user/edit, maybe near the date format?

Does it worth to roll a patch for 4.7?

Comments

LAsan’s picture

LAsan CreditAttribution: LAsan commented
Version: x.y.z » 7.x-dev
Status: Active » Fixed

No feedback.
Version not maintained.

keith.smith’s picture

keith.smith CreditAttribution: keith.smith commented
Component: base system » language system
Status: Fixed » Active

These settings would have to be configurable per-language (though I don't know if there is anything in core that uses them right now). This is probably a language system issue (and may be a won't fix or by design there).

markus_petrux’s picture

markus_petrux CreditAttribution: markus_petrux commented

...I don't know if there is anything in core that uses them right now...

It could be used to format view counters, etc.

If it was in core, then other modules could make use of this.

If it was part of the locale system, then:

1) the {languages} table would have to be extended with 2 fields: dec_point and thousands_sep.

2) I guess .po files for core languajes would have to include values for these new fields.

3) The language settings form would have to be extended to support these new fields as well.

4) Finally, the locale API could implement something like this:

function locale_number_format($number, $decimals = 0) {
  global $language;
  return number_format($number, $decimals, $language->dec_point, $language->thousands_sep);
}
...may be a won't fix or by design there...

Please, don't. If it cannot be done for D7, then let it be for the future.

markus_petrux’s picture

markus_petrux CreditAttribution: markus_petrux commented

Maybe it is not a language dependent issue, since I could prefer reading text in english but read numbers with comma as decimal point, or read text in spanish and set decimal point as dot, etc. Maybe it should even be user selectable, aside from providing a site default, just like date/time formats. This is how desktop systems implement this feature. You can set the language and number format at will.

So maybe this approach could be implemented like this?

1) Change "Administer -> Site configuration -> Date and time" into "Administer -> Site configuration -> Regional settings"

2) In the "Regional settings" form and a new fieldset labeled "Numbers format" that contains fields for "decimal point" and "thousands separator" AND an option to allow users setup different options from their profiles, just like time format.

3) Extend users table with 2 fields: dec_point and thousands_sep.

4) Extend user settings form with those fields, that would show if site had enabled this option in "Regional settings".

5) Finally, common.inc could implement something like this:

function format_number($number, $decimals = 0) {
  static $dec_point, $thousands_sep;
  global $user;
  if (!isset($dec_point)) {
    $dec_point = variable_get('number_default_dec_point', '.');
    $thousands_sep = variable_get('number_default_thousands_sep', ',');
    if (variable_get('configurable_number_formats', 1) && $user->uid) {
      if (strlen($user->dec_point)) {
        $dec_point = $user->dec_point;
      }
      if (strlen($user->thousands_sep)) {
        $thousands_sep = $user->thousands_sep;
      }
    }
  }
  return number_format($number, $decimals, $dec_point, $thousands_sep);
}

I think this is better that the other approach. It gives more freedom to sites and users to set these options, regardless of language settings.

markus_petrux’s picture

markus_petrux CreditAttribution: markus_petrux commented

In the meantime I have implemented #4 as a contrib module:

http://drupal.org/project/format_number

It seems this is more country dependent than language dependent, so I opted for site default / user selected options.

http://en.wikipedia.org/wiki/Decimal_separator

markus_petrux’s picture

markus_petrux CreditAttribution: markus_petrux commented

Sorry for double posting.

I just wanted to mention that I've exported the whole contributions CVS just to check, and there are a lot of modules using PHP function number_format(), from CCK number field, to ecommerce, and a lot more. So maybe it would be nice to have something like this in core.

markus_petrux’s picture

markus_petrux CreditAttribution: markus_petrux commented

Just bumping to add a few references I used to complete the Format Number API module, where I believe it covered all possible combinations used around the globe.

- PHP manual: number_format().
- Unicode Locale Data Markup Language (LDML).
- Unicode CLDR Project: Common Locale Data Repository (CLDR).
- CLDR By-Type Chart: number.symbol.
- Wikipedia: Decimal separator.

If it was to be included in core, one possible way would by renaming Administration / Site configuration / Date and time into "Regional settings" and there include the current settings for "Date and time" and include an additional fieldset for "Number format" settings. The same approach could be applied to the user profile page.

Then everyone would have a centralized method to format numbers, the same way there's one for dates, etc.

Worths writing a patch for this?

Jose Reyero’s picture

Jose Reyero CreditAttribution: Jose Reyero commented
Issue tags: +i18n sprint
markus_petrux’s picture

markus_petrux CreditAttribution: markus_petrux commented

Is it possible to consider this feature for D7?

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
CreditAttribution: plach commented
Version: 7.x-dev » 8.x-dev

I am afraid this will have to wait for D8 :(

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented
Issue tags: +xmlsitemap

Adding 'xmlsitemap' tag since I'd like to see a cleaner way of i18n numbers besides having to manually put t('0.0'), t('0.1), etc. in the module.

grendzy’s picture

grendzy CreditAttribution: grendzy commented
Issue tags: -xmlsitemap

I agree this is too late for 7, but would be nice for core. Check out this excerpt from xmlsitemap.de.po. Eeek!

#: xmlsitemap.module:313
msgid "0.9"
msgstr "0,9"
#: xmlsitemap.module:314
msgid "0.8"
msgstr "0,8"
#: xmlsitemap.module:315
msgid "0.7"
msgstr "0,7"
grendzy’s picture

grendzy CreditAttribution: grendzy commented
Issue tags: +xmlsitemap

sorry, in-flight collision on the tag.

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented

Let's work a great version of that Format Number API module for D7, including an interface to match what the date/time localization does in D7. Plus let's get some tests. :) That should help ease this for D8.

markus_petrux’s picture

markus_petrux CreditAttribution: markus_petrux commented

Possible dup: #471058: Implement format_number() for international number formating

@Dave #14: Sounds a good plan. :)

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented
Title: Add settings to configure decimal point and thousands separators » Add format_number() and settings to configure decimal point and thousands separators

Woo-hoo! :)

markus_petrux’s picture

markus_petrux CreditAttribution: markus_petrux commented

Updating status of the issue...

Sorry it happens quite late, but there's finally a version of Format Number API for Drupal 7. Cheers

Another issue in the Drupal project queue related to this: #1345758: META: Provide locale (regional) formats framework for automated translation of non textual data

wil2091’s picture

wil2091 CreditAttribution: wil2091 commented
Issue summary: View changes

How can I make the numeric digits to be displayed only in english format irrespective of the language selected. My website translates the numbers as well based on the language selected. Any suggestion, what am I doing wrong?

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Anybody’s picture

Anybody
Primary language German
Location Porta Westfalica
CreditAttribution: Anybody commented

This is a very very old issue but still not solved and a big problem for several cases in multilingual websites.

Drupal 8 should clearly provide an abstraction for number_format() like it does for format_date().

It should be used instead of number_format() all modules to make it possible to flexibly override the date formatting. How can we proceed here

markhalliwell’s picture

markhalliwell
Primary language English
CreditAttribution: markhalliwell at Tag1 Consulting commented
Title: Add format_number() and settings to configure decimal point and thousands separators » Add Number::format with settings to configure decimal point and thousands separators
Component: language system » base system

This should be added to \Drupal\Component\Utility\Number instead of creating a new procedural function.

If we're talking about adding settings/config, then maybe it should be converted into a service instead (like date.formatter currently is).

Also, while i18n may need this, it really has nothing to do with the language system.

Anybody’s picture

Anybody
Primary language German
Location Porta Westfalica
CreditAttribution: Anybody commented

I completely agree with @markcarver. How can we proceed here?

Yaazkal’s picture

Yaazkal CreditAttribution: Yaazkal commented

+1

If we're talking about adding settings/config, then maybe it should be converted into a service instead (like date.formatter currently is).

apaderno’s picture

apaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
CreditAttribution: apaderno as a volunteer commented
Version: 8.4.x-dev » 8.5.x-dev

@Anybody If you are able to provide a patch, that would be a start.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Anybody’s picture

Anybody
Primary language German
Location Porta Westfalica
CreditAttribution: Anybody commented

Yes Yaazkal, that's a good point. I think this behaves a lot like date formatting, because both is kind of core "localization" (independent from i18n because the Drupal site always has a language which doesn't have to be english).

I'll have a look at the date.formatter service implementation but could need some help because I didn't write custom services yet.

Furthermore I'm planning to write a custom module for more flexible number formatting. The current decimal formatter only supports fixed amount of decimals, which doesn't fit for many industry cases, where the decimals show the precision and if no decimal is entered then it should not be output as zero. I'll create a separate issue / module project for that, but it could also become part of the core patch later on.

If there is any core maintainer with deeper knowledge and interest to fix this, please don't hesitate to contact me.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Anybody’s picture

Anybody
Primary language German
Location Porta Westfalica
CreditAttribution: Anybody commented

I now started a contrib project for this and would hope to see some of you help coding :)
Let's keep this issue open to integrate the module into core one day, if it succeeds. I still think this should be handled equally to date formats (central configuration + i18n)

henk’s picture

henk CreditAttribution: henk at RatioWeb for Bright Solutions GmbH commented

@Anybody can you share the place where you are working on it? Maybe I can help with something?

Anybody’s picture

Anybody
Primary language German
Location Porta Westfalica
CreditAttribution: Anybody commented

@henk: Thank you! See https://www.drupal.org/project/advanced_number_format - currently it's only plans / discussion / documentation, but we can start coding soon. Feel free to add comments in the issues!

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

mlncn’s picture

mlncn CreditAttribution: mlncn at Agaric for Drutopia, Find It Cambridge, Cambridge, Massachusetts Family Policy Council commented

I just noticed that there doesn't seem to be a way to format the number when using formatPlural(). For example, "Your search has one result" or "Your search has 1234 results"— there's no way to format that large number as as 1,234.

I wonder if this venerable issue could help with that also?

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.