InputNumber: Respect Global Locale?
Hello,
I'm having trouble to understand how to use locale correctly. According to the documentation I should simply call the locale method, but I've prepared 3 examples of using the locale and the behavior is different in each one of them.
The examples are based on an example I found in https://github.com/primefaces/primelocale/issues/182#issuecomment-2217449456
Expected behavior
- The application always works as in scenario 1.
Good enough behavior
If for some reason the expected behavior cannot be implemented:
- The proper way of locale configuration is described in the documentation.
- All components behaves consistently in each scenario.
Scenario 1 - calling locale globally
addLocale('pl', plLocale['pl']);
locale('pl');
root.render(
<React.StrictMode>
<App />
</React.StrictMode>
);
https://stackblitz.com/edit/react-zyv3qr-eut6jwny?file=src%2FApp.js,src%2Findex.js
In this scenario everything works fine:
- ✔️ Numbers are formatted using Polish locale, e.g.
1 234,56 - ✔️ Dates are formatted using Polish locale, e.g.
22.10.2025 - ✔️ Calendar uses Polish names
Scenario 2 - calling locale globally and using PrimeReactProvider
When the application is wrapped inside PrimeReactProvider component, the locale simply stop working
addLocale('pl', plLocale['pl']);
locale('pl');
root.render(
<React.StrictMode>
<PrimeReactProvider>
<App />
</PrimeReactProvider>
</React.StrictMode>
);
https://stackblitz.com/edit/react-zyv3qr-tauquecy?file=src%2FApp.js,src%2Findex.js
Calling the locale seems to have no effect - the primereact components use the default 'en' locale.
- ❌ Numbers are formatted using English locale, e.g.
1,234.56 - ❌ Dates are formatted using English locale, e.g.
10/22/2025 - ❌ Calendar uses English names
Scenario 3 - calling locale inside a component and using PrimeReactProvider
That's actually how I currently use locale (the locale depends on current user's context, so it cannot be set globally) and that's the most messy scenario.
https://stackblitz.com/edit/react-zyv3qr-947xus6s?file=src%2FApp.js,src%2Findex.js
The only difference compared to scenario 2 is that now the addLocale and locale methods are called inside the Appcomponent.
In this scenario:
- ❌ Numbers are formatted using English locale, e.g.
1,234.56 - ✔️ Dates are formatted using Polish locale, e.g.
22.10.2025 - ✔️ Calendar uses Polish names
I guess I should be using PrimeReactContext.setLocale in the 2nd and 3rd scenario, but that setLocale method is not documented. (And if I do that, should I call the locale method as well, or only the setLocale?)
Also (and most importantly) I think that all components should respect the same locale in the 3rd scenario - there is no reason for numbers and dates to be ever formatted differently (unless someone explicitly specifies different locale in different components).
Here is a working stackblitz i usually show people: https://stackblitz.com/edit/axcck4-ztfv6rtm?file=src%2FApp.tsx
Hi @melloware thanks for the response. That is basically the same locale usage as scenario 3 - if you add InputNumber there, you will see that numbers always have English formatting, even if you change locale to something else.
Ahhh that might be specifically an InputNumber bug not respecting the locale?
Yep try this example: https://stackblitz.com/edit/axcck4-kqvgdpgd?file=src%2FApp.tsx
the InputNumber now works it just looks like it doesn't respect the locale unless you tell it to.
It something wrong with this line: https://github.com/primefaces/primereact/blob/25f30cdf332cddb5cf65091d53ed90bf329cace2/components/lib/inputnumber/InputNumber.js#L48
It something wrong with this line
Well, that's one way to look at it. The other it that maybe there is something wrong with the context. Looks like the context defaults to en locale. My gut feeling is that context should default to global locale (it's a bit weird to me that when I set locale the way that is described in documentation, there still might be a piece of code that defaults to en locale) - if it did, the input number behavior would be correct.
But changing the context behavior would have a bigger impact than changing the input number, so I'm not sure if it's worth trying.
agreed there is someting bigger going on here.