Introduce `number_format_i18n` for @wordpress/i18n

[Clorith]

WordPress translation functions have had number_format_i18n for some time, which is convenient for outputting numbers in a locale-appropriate way.

It would be beneficial to discuss the possibilities of introducing this as part of the @wordpress/i18n package as well.

[swissspidy]

This could be a small wrapper around Intl.NumberFormat that handles the locale part.

[pedro-mendonca]

Hi, any development on this?

[USERSATOSHI]

Hi, From my understanding of this issue, I believe we can use

getSettings() from @wordpress/date which would provide us with the locale.
This locale can be converted into JS Compatible format and can be used internally in numberFormatI18n function

allowing us to have a similar code as PHP.

an example Implementation for this could be:

export function numberFormatI18n(
	number: number,
	decimals: number = 0
): string {
	const locale = getLocale(); // An internal helper function to get locale.

	/**
	 * Node.js supports up to 20 decimal places for Intl.NumberFormat ( Tested manually )
	 * but most browsers support up to 100 decimal places. ( Mdn Docs)
	 * We will use 20 as a safe upper limit for compatibility.
	 */
	const validDecimals = Math.max( 0, Math.min( 20, Math.floor( decimals ) ) );

	const options: Intl.NumberFormatOptions = {
		minimumFractionDigits: validDecimals,
		maximumFractionDigits: validDecimals,
	};

	return new Intl.NumberFormat( locale, options ).format( number );
}

if this implementation is fine, I can go ahead and create a PR for this.

cc: @swissspidy.

[swissspidy]

It's not that trivial.

First, we shouldn't add a dependency on the date package to get locale information. This is the i18n package after all, which itself should have locale information. That's the whole purpose. So we need to figure out how to do that. Maybe we even need a change in core?

Second, the WordPress locale would need to be converted to a BCP 47 language tag or Intl.Locale instance supported by Intl.NumberFormat. That's easy for e.g. de_DE -> de-DE but there are also variants such as de_DE_formal and some other WordPress/GlotPress-specific variants that need to be supported and tested.

[USERSATOSHI]

First, we shouldn't add a dependency on the date package to get locale information. This is the i18n package after all, which itself should have locale information. That's the whole purpose. So we need to figure out how to do that. Maybe we even need a change in core?

Oh , yeah if we are not depending on date then this wouldn't be trivial , I saw locale info in that hence thought it could be a nice way to add it, I will check on this one and see what we can do to get locale without any deps

Second, the WordPress locale would need to be converted to a BCP 47 language tag or Intl.Locale instance supported by Intl.NumberFormat. That's easy for e.g. de_DE -> de-DE but there are also variants such as de_DE_formal and some other WordPress/GlotPress-specific variants that need to be supported and tested.

for this I was able to create a wpLocaleToJS function which doesnt convert it tho I have to check the variants ( thank you for sharing that ) to test on all locale and support anything missing

Right now it supports the lang[_Script][Country] format.

[USERSATOSHI]

One thing we could possible do, is to add numberFormatI18n to createI18n and defaultI18n as these create their own instances and

export const createI18n = < TextDomain extends string >(
	initialData?: LocaleData< TextDomain >,
	initialDomain?: TextDomain,
	hooks?: Hooks
): I18n< TextDomain >

does take LocaleData

which include an optional lang: property in it.

Link to type: https://github.com/aduth/tannin/blob/master/packages/tannin/index.js#L13-L19

[swissspidy]

Right, yeah, in WP we usually provide lang, which is iso_639 + country code. Looks like it doesn't include the variant suffix like _formal, so even better.

[USERSATOSHI]

Right, yeah, in WP we usually provide lang, which is iso_639 + country code. Looks like it doesn't include the variant suffix like _formal, so even better.

Yeah, I just wanted to confirm how locale was being set in WordPress.

Seems like the we can add numberFormatI18n as part of createI18n and defaultI18n.

cc: @swissspidy