feat: improve locale handling #1025
Conversation
There was a problem hiding this comment.
I'm not against it, but the whole purpose of useFormatLanguage was for it to be different from the translation language.
ie: You could have the app translated in english but have dates and numbers formated in FR format.
I personally thinks that this PR is simplifying the matter but I think it's better to ask @Pascal-Delange if it's really what we want.
|
@Pascal-Delange what are you thoughts on this ? |
There was a problem hiding this comment.
Hmm, I'm unsure.
I do think that having the possibility of having different formats (for numbers, dates...) between american english, british english, etc... is not stupid and overkill, and I'm not sure that hard coding to "we only handle "fr-FR" and "en-GB" is the best fix to our issues.
I'm biased to think that better using what information the browser already gives us, is a better direction. But let's discuss this one orally this week.
| case 'fr': | ||
| return 'fr-FR'; | ||
| case 'ar': | ||
| return 'ar'; |
There was a problem hiding this comment.
shouldn't there be a region here ?
|
closing since we go with the initial PR #1000 |
3 participants
Fix rehydration errors on date formats by using the applied language from the translation hook instead of the navigator.