Is your feature request related to a problem? Please describe.
By default, no global formats are available via format.* calls. However, for consumption in messages, a few defaults are available through intl-messageformat (source).
Describe the solution you'd like
Ideally, we'd support the same defaults across both options.
The options I can currently think of are:
Importing formats from intl-messageformat for local consumption (big downside: pulls in the whole dependency, so not really an option).
Re-defining the formats for both places (downside: duplication with intl-messageformat)
Using no defaults in either place
After https://github.com/amannn/next-intl/pull/705, we'll get rid of intl-messageformat at runtime and also gain more control over aspects like defaults, so we could consider supporting the same defaults for both APIs without duplication
I'm currently favoring (3), but this would be a breaking change.
Describe alternatives you've considered
User has to define all relevant formats in user space. These apply to either functionality.
Is your feature request related to a problem? Please describe.
By default, no global formats are available via
format.*calls. However, for consumption in messages, a few defaults are available throughintl-messageformat(source).Describe the solution you'd like
Ideally, we'd support the same defaults across both options.
The options I can currently think of are:
formatsfromintl-messageformatfor local consumption (big downside: pulls in the whole dependency, so not really an option).formatsfor both places (downside: duplication withintl-messageformat)intl-messageformatat runtime and also gain more control over aspects like defaults, so we could consider supporting the same defaults for both APIs without duplicationI'm currently favoring (3), but this would be a breaking change.
Describe alternatives you've considered
User has to define all relevant formats in user space. These apply to either functionality.