Entity Decimal token formats number into two digits

I also run into this issue.

Apparently, much better would be to introduce 2 additional child-tokens:

• :round which outputs the decimal rounded up to a nearest integer
• :round:x which outputs the decimal rounded up to the x precision
• and then let the default token to output the decimal unformatted, i.e. exactly how it comes

I just ran into the same problem and you are absolutely right! The possible solution in #2 would be great. The default value should use the fields precision setting.

I think besides the additional tokens this is what should be used by default: #52153: Add Number::format with settings to configure decimal point and thousands separators

Here's a patch.

All it does is make Entity tokens round to 8 decimals, sufficient for latitude and longitude. This is not likely to be committed to the module, but rather it is for those who wish to have accurate latitude and longitude in a token and don't mind if other number field tokens are eight instead of two decimal places.

Adding @anybody’s Issue link from #4 to Related Issues to help maintainers correlate these. Will also do that from there to here.

It occurs to me that bucefal91’s suggestion in #2 could conceivably break some existing functionality that depends on the hundreths-digit rounding (I can’t think of an actual case, but just because we can’t think of any doesn’t mean there aren’t any). With that in mind, I propose this modification:

• :unf Outputs decimal value unformatted (other synonyms could include :noround or :full).
• :round and round:# mean as suggested in Comment #2. :integer could be a synonym for :round or :round:0.
• If no formatter is specified, leave rounding at 2 digits for backwards compatibility.
  • Alternatively, there could be an Admin setting to set the preferred default rounding in lieu of specifying it on a per-token-instance basis, and its initial setting would be set at install time in the entity.install script to default to “2” for upgrading of existing installations where the Entity Token submodule is enabled, and to “none” (meaning no rounding, as opposed to “0” for rounding to integers) for new installations or when the Entity Token submodule is disabled or not installed at install time.

FYI: For Drupal 8 I started a project which could be used to add token support for number formatting or alter existing tokens to match global defaults: https://www.drupal.org/project/advanced_number_format

It would be nice to get some help with that.

Until there is a clean solution you can find my patch for one digit decimals in tokens attached. Perhaps anyone might need it.

I've had a shot at putting together a little patch for this. I implemented the following rounding preferences for decimal properties like so:

• [your:decimal:property:raw] exposes the full property value.
• [your:decimal:property:unf] also exposes the full property value.
• [your:decimal:property:integer] provides the property value rounded to the nearest integer.
• [your:decimal:property:round] also provides the property value rounded to the nearest integer.
• [your:decimal:property:round:?] provides the property value rounded to the nearest ? significant figures, where ? may be any integer 0 or greater.
• [your:decimal:property], as previously, provides the property value rounded to the nearest 2 significant figures.

I've only had a chance to test this with the lat/long properties exposed by Geofield module, but I hope this will be of use elsewhere.

Hi @geoffreyr,

this is great!! Thank you very much. Some suggestions for improvements, especially for formatting in different countries (furthermore this should be solved better by default in core)...

• Add parameter to set decimal and thousand separator
• Add functionality for float fields like for decimals
• Add tests for the tokens. I think we should find examples in token module.

Your patch is a great first step! THANK YOU!

@geoffreyr, thanks (though the patch failed testing)!

A change I would recommend based on my #6 from a year ago: instead of the default always being rounding to two digits ([your:decimal:property]=[your:decimal:property:round:2]), it should be configurable via an Admin settings page which would have a checkbox on whether to round at all, and an integer field specifying how many digits to round to (that field would be grayed out / disabled if the checkbox isn’t checked).

The default for that setting would be set at install time by the installer script as follows:

• If an update of an existing installation of the module, and the module was enabled at upgrade time, set the checkbox to checked and set the rounding value to 2, for backwards compatibility..
• If a new installation of the module, or an updatee of an existing installation but the module was disabled / not enabled at the time of the upgrade (i.e. if upgraded through drush pm-upgrade --check-disabled or through the web admin if the option to check for updates of disabled modules and themes is enabled), the checkbox should default to unchecked, which disables the rounding value entirely and causes [your:decimal:property]=[your:decimal:property:raw].

Another suggested change: why should the rounding value be limited to non-negative integers (≥0)? Maybe someone wants to round to the left of the decimal point, to round to the nearest tens or hundreds or thousands or millions instead of to tenths or hundredths or thousandths or millionths.

So, for instance, if the value is 12345.6789, [your:decimal:property:round:3] would return “12345.679” whereas [your:decimal:property:round:–3] would return “12000”. If the value were 98765.4321, those would return “98765.432” and “99000,” respectively. .

Also, maybe add a :groupings suffix to return digit groupings, as commas. So, in the first example above, [your:decimal:property:round:3:groupings] would return “12‚345.679” while [your:decimal:property:round:-3:groupings] would return “12‚000”.

And finally, another suffix of :localize to respect or override user’s locale for the decimal point and grouping separator instead of just assuming period and comma, respectively.. That could be the default, but a locale could be specified to override it if the returned value is needed to be parsed in code or some such. So, for a visitor from the USA, the above would work as usual, while for one from France the values would read “12 345‚679” and “12 000” (with decimal comma instead of regular comma, and non-breaking spaces for grouping, of course), respectively. :localize</cod> could be followed by a locale indicator if you wanted to force a particular cultural standard regardless of the user’s locale: <code>[your:decimal:property:round:3:groupings:localize:en-US] would always return “12‚345.679” in that example.

Hi @Anybody and @Joel MMCC, thanks for your feedback. Your recommendations sound good, especially the ones to do with tests and reasonable defaults, so I'll have another crack at it when I find time. Some of the other requested features (negative rounding, localisation) might take a bit longer, but I'll see how it goes.

Added rounding config, default rounding, and tests.

@geoffreyr should we perhaps move all that i18n / number configuration, not only for tokens, but globally for Drupal, here: https://www.drupal.org/project/advanced_number_format ?

It's a proof-of-concept module to finally solve the whole thing like it's already done for date handling for example...

I guess that would be a better place than entity token module and your code could be a nice starting point. Because I think date handling / formatting in core is the best and similar example, we should have a look how that's done to do it right from the start.

Would you like to help?

@Anybody Yes, I'm interested as long as we can do a version for Drupal 7. Which, of course, should be feasible if we can use XAutoload or Backport or something to reuse D8-friendly code. Just need to work out where to get started!

@geoffreyr, yes of course. This absolutely makes sense also for Drupal 7 so the logic behind should be the same and the forms / integration can be backported.