-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The added date is mm/dd/yyyy, should be localised and/or configurable #123
Comments
That's not how this works, date formats are tied to countries - not languages. There are english speaking countries that officially use dd/mm/yyyy and only dd/mm/yyyy. Language selection is not an answer. And besides, people may have preferences that differ from their localisation. |
Hmm. I've been poking around crowdin, but I can't figure out how to touch english or add any of the localised englishes as a target language so that I can fix the date. I assume crowdin is the correct tool, unless I have to go off and fix the date formatter in react... |
I'm updating this to a bug. English language uses dmy, a similar language called American uses mdy. The localisation for English is incorrect and since it's the projects root language it's uneditable. |
Ok now it is. Maybe I got too upset to hit save settings? π€·ββοΈ |
Ah, I see that client/src/javascript/util/detectLocale.ts is specifically ignoring localisations. That won't help. |
Console output showing overriding to be the source of the problem: (new Date()).toLocaleDateString();
"14/12/2020"
Intl.DateTimeFormat().format(new Date())
"14/12/2020"
Intl.DateTimeFormat('en').format(new Date())
"12/14/2020"
Intl.DateTimeFormat('en-GB').format(new Date())
"14/12/2020"
Intl.DateTimeFormat('en-GB'.substr(0,2)).format(new Date())
"12/14/2020" |
Currently Flood uses FormattedDate of |
"It uses the current language settings"
Sorry let me rephrase. Yes react-intl is using current locale, however flood is setting locale by truncating where there isn't an existing match. This is good enough for string translation, but affects date format - and possibly affects decimal seperator elsewhere as well. |
detectLocale now respects the locale of user and passes it to the IntlProvider. Though, Flood still uses the old behavior if you specify language manually. I think it would be too much maintenance burden for the project if a separate manual selection menu needs to be added for locale. |
Or a single very long list of "languages"/locales. This is an elegant solution which is working well, thank you. I'm impressed. P.S. if anyone does want to take this further I boiled the English locales down to four "types": en, en-CA, en-001, and en-150.
But, frankly, that way lays madness. |
Thanks guys, the dates look much better now in Flood. en-GB locale now shows dd/mm/yyyy |
Using a format that users of a certain locale typically expect is probably fine. But at least an option to switch to ISO 8601 |
name: 'π Bug Report'
about: 'Report a general bug'
Type: Bug Report
Your Environment
4.3.1
Commit ID (development release)git --no-pager log -1
node --version
v12.19.0
npm --version
7.1.0
name and version
Firefox version 83.0
Windows 10 v20H2
Summary: dates are wrong
For me mm/dd/yyyy is specifically wrong, confusing, & neigh unreadable. yyyy-mm-dd would be my preference (and an international standard, readable by everyone π) but even dd/mm/yyyy would be better.
Edit: I'm updating this to a bug report, because frankly the date format is completely incorrect if being tied to the language English. The date format used is American.
Expected Behavior: being able to read the date.
Current Behavior: date format unreadable.
Possible Solution
My solution would be a place for a setting in
settings > user interface
, directly under the language setting.Could be a drop down menu with predetermined formats, a field for entering a custom format - or both, with custom being an option in the drop down menu.
Steps to ReproduceN/AContextThe text was updated successfully, but these errors were encountered: