Add humanTimeDiff() date utility
#4100
Conversation
|
This is ready for review. |
|
@jaswrks since we already use moment.js in Gutenberg, could we use |
|
@adamsilverstein This PR uses the moment.js |
|
@jaswrks ah, looks good! Sorry, I missed the use of moment.js. |
|
Cool, thanks. Are you able to merge? |
| // Convert to moment. | ||
| const fromMoment = moment( from ); | ||
| // Set the locale. | ||
| fromMoment.locale( window._wpDateSettings.l10n.locale ); |
There was a problem hiding this comment.
Something that worries me here, is that I'm not sure these are translated properly because we do not use the built-in moment translations but we use generated translations from WP i18n files.
There was a problem hiding this comment.
If it helps, the relevant translation strings for this Moment functionality can be found here in Gutenberg, which comes from this localization.
To your point, I think the remaining issue is that these strings have not yet been translated in Gutenberg. I'll see if I can resolve that.
There was a problem hiding this comment.
I'm not sure I follow - doesn't this line set the moment.locale and thus rely on moment.js translation functionality for the difference string? In my case for example _wpDateSettings.l10n.locale is en_US. https://momentjs.com/docs/#/i18n/
There was a problem hiding this comment.
Thanks for catching that! Yep, that line can be removed. Looks to me like that same line can be removed from the existing dateI18n() utility also. The locale is set at the end of this file already, in the proper way.
There was a problem hiding this comment.
Actually, no. Those lines can stay and are correct. The setupLocale() method is defining the translations for _wpDateSettings.l10n.locale, and then restoring the original default Moment locale. So it's still necessary to set the locale again before using Moment elsewhere in this file.
The translation strings are already prepared for this, given the setupLocale() function that runs in this file. So the following:
fromMoment.locale( window._wpDateSettings.l10n.locale )Is setting the locale (e.g., en_US), which has had its translation strings preconfigured ahead of time by setupLocale() in this file.
There was a problem hiding this comment.
To understand this better, see: https://momentjs.com/docs/#/customization/
And then look at what setupLocale() does in this Gutenberg file, and where setupLocale() is called from when the file is imported.
|
Appreciate the help :-) In c01d7b1 I translated a few remaining strings that are needed by relative time calculations in Moment, which were previously hard-coded in Gutenberg. They now come from |
The `humanTimeDiff()` utility is like `human_time_diff()` in PHP. However, this version also supports a third argument that enables an automatic suffix of `ago` (past) or `from now` (future).
|
There was no activity in this PR for almost 6 months. It looks like it isn’t required feature for Gutenberg core. Let’s close it. We can always reopen and rebase it with master branch to align with the current state of Gutenberg. |
Description
The
humanTimeDiff()utility is likehuman_time_diff()in PHP. However, this version also supports a third argument that enables an automatic suffix of 'ago' (past) or 'from now' (future) — taken from the current locale, viawindow._wpDateSettings.Where is this used?
It currently is not used. I'm just submitting this for consideration, because I found this new utility to be helpful while working on Annotations in #4068
How Has This Been Tested?
Unit tests are included in this PR.
Types of changes
New date utility.
Checklist: