Open jardakotesovec opened 6 months ago
@asmecher @bozana @Vitaliy-1 Please let me know if you have some additional context to this issue.
@jardakotesovec, I can't help much with browser-side localization, but we did recently have to replace our use of (localized) strftime
on the PHP side, as it was deprecated. Unfortunately much of our use of strftime
is via Smarty's date_format
function, which they've apparently chosen not to replace until PHP9. So our server-side date formatting is also somewhat in flux. For parts of date formatting that have been migrated away from strftime
(that is, parts that are not Smarty date_format
based) we have a configuration mapping from strftime
conventions to date
conventions; see PKPString::getStrftimeConversion
.
I remember working date formatting and moment.js in the DateTimeForm.vue
. I don't see an explicit locale import there or am I missing something?
Looks like moment.js folks recommend to migrate to the Luxon
@Vitaliy-1 When investigating yesterday, I noticed some devs claiming that when moment.js used with webpack - it would bundle all locales. So maybe that was the case in past and maybe thats why it was working in past. And I did expect this to be the case for 3.3 and 3.4, but surprisingly when I called moment.locales() it listed only ['en']. So maybe it already regressed with some moment.js or webpack version update, not sure.
Moment.js provides good list of recommendations what to use as modern replacement - https://momentjs.com/docs/#/-project-status/recommendations/
Given our wide range locale support - we would need to bundle way too many locale specific configurations and maintain the list. I think browser support for Intl.DateTimeFormat is good enough to rely on that instead at this point.
Given this assumptions we have two options
Moment.js docs points out that browsers are inconsistent on date parsing ('yyyy-mm-dd') format which we use a lot. Therefore adopting Luxon which address these inconsistencies, plus give us some useful functions to for example calculate number of days between two days seems like convenient way forwards.
I was interested to know what locales the Intl API supports. And was not really able to find anything else than just directly check via Intl.DateTimeFormat.supportedLocalesOf(['de',...])
in my browser.
Therefore I tried to dump the languages.csv file on it to see how much it will tell it supports and got 142 from total ~720 in languages.csv.
In comparison to what moment.js offers - they have 138 locales. From this simple comparison I would conclude that Intl.DateTimeFormat is not falling behind.. and will get better as the browsers/OSs improves the locale support.
Tagging @ajnyga in case have some suggestions or ideas how to push this even further.
In the past I've used date-fns
, but Luxon
is the natural choice, given it's maintained by the moment
folks (smaller probability of missing features when updating).
I guess the languages.csv
reference is coming from here https://github.com/pkp/pkp-lib/issues/9707, while both issues are scheduled for 3.5, it makes sense to ignore the current/older locales :)
Coming from a completely different design perspective, I researched a bit into this and audited different standards and websites and I believe that we should follow ISO 8601 standard.
This means that we should be following formats
YYYY-MM-DD
hh:mm:ss
where hh refers to the zero-padded hour between 00 and 24YYYY-MM-DD hh:mm:ss
For example, 11.15pm on 19th March 2024 will be expressed as 2024-03-19 23:15:00
I am maybe not convinced if localisation for dates is a good idea but this has been a feature we've had.
Luxon mentions
Luxon DateTimes can be configured using BCP 47 locale strings specifying the language to use generating or interpreting strings.
https://moment.github.io/luxon/#/intl?id=how-locales-work
So this should work ok with our choice of using the Weblate list which is based on BCP47.
Hello,
I think it will be meriltuous for me to explain the rationale behind me proposing a unified format for date in the platform. I'm presenting a few snippets from a thorough research I conducted along with a suggestion that I think could work for everyone.
Advantages of the ISO 8601 standard date notation compared to other commonly used variants. These advantages about been included in many research papers recently on the topic.
We promote a standard as it helps streamline and invite a lot of globalised effort with the flexibility of users wanting to change the format for their OJS installations and themes if they wish to
Just about the entire software world uses ISO8601 for shuttling dates between systems. Beyond storage and import/export (where ISO8601 is fine) we really only have two requirements:
I think both of these can be pushed as close to the browser as possible using 3rd-party libraries, where intl support will be closest in alignment with the user's expectations.
Devika, this is close to what you're proposing, except that it doesn't throw the baby out with the bathwater by 100% dropping support for localized dates.
(We do have a community that wants to use OJS with Jalali dates, and it's been a longstanding challenge for them to do that. See e.g. this forum thread. But it appears that good 3rd-party libraries that we might consider also miss this support.)
100% agree with you Alec :D Thank you so much for bringing this to light was not aware of the Forum thread before you mentioned it
The standards are great, such as the numeric system, international system of units, and I'd love to have a unified language too, it would be much easier to share information.
But people are complex and love their creations (e.g. imperial system of units). We need to give what they want :)
Describe the issue While doing code review for PR I was looking for correct way how to adjust following date formatting statement to reflect current locale.
Given that we have
getMomentLocale
function I assume that moment works with locale.Tried things like
But the problem is that for moment.js to be able to format per locale - each individual locale needs to be explicitly loaded
I did test it with 3.3 and 3.4 and main. And all of them had only 'en' locale which is always present.
Solution Probably start relying on some modern library which is leveraging native browser functionality for formatting dates, so we don't have to include extensive locale specific data for so many languages.