[OJS] Submissions page: date of last activity doesn't follow configured date format

[melat0nin]

On the Submissions page, the date shown alongside "Last activity recorded" does not follow the date format defined in config.inc.php. It displays at yyyy/mm/dd regardless of the latter.

[melat0nin]

True in OJS 3.1.2.4

[asmecher]

See also: https://forum.pkp.sfu.ca/t/how-to-change-mm-dd-yyyy-to-dd-mm-yyyy

[NateWr]

This is because the date transformation happens in the browser so we rely on a JavaScript transformation. The data comes from the API, which returns our standard machine-readable date format (YYYY-MM-DD). See: https://github.com/pkp/ui-library/blob/master/src/mixins/global.js#L98-L127

We use toLocaleDateString to format the date based on the browser's locale.

It would be nice to figure out a way to draw on the config option in the browser, but when the feature went in it was too late in the 3.1.x cycle to investigate thoroughly. Unfortunately, for this reason, it's probably a bit too difficult for the "Try Me" label.

I'd be eager to hear ideas anyone has on how to align formatting between PHP and JavaScript.

[asmecher]

We're using strftime on the PHP side, which is a standard function with support in many languages, and appears to have several JS ports available, e.g. https://github.com/samsonjs/strftime and https://thdoan.github.io/strftime/.

[NateWr]

🎉 This should be easy to do for 3.2.

[NateWr]

Having looked at this briefly, I think the barrier we face is in the translation. The strftime module will read our date formats, but it only has a limited set of supported locales and is missing some key ones for us like fr_CA.

I think we'll need to consider either asking our own translators to contribute the necessary strings:

var it_IT = {
        days: ['domenica', 'lunedi', 'martedi', 'mercoledi', 'giovedi', 'venerdi', 'sabato'],
        shortDays: ['dom', 'lun', 'mar', 'mer', 'gio', 'ven', 'sab'],
        months: ['gennaio', 'febbraio', 'marzo', 'aprile', 'maggio', 'giugno', 'luglio', 'agosto', 'settembre', 'ottobre', 'novembre', 'dicembre'],
        shortMonths: ['gen', 'feb', 'mar', 'apr', 'mag', 'giu', 'lug', 'ago', 'set', 'ott', 'nov', 'dic'],
        AM: 'AM',
        PM: 'PM',
        am: 'am',
        pm: 'pm',
        formats: {
            D: '%m/%d/%y',
            F: '%Y-%m-%d',
            R: '%H:%M',
            X: '%T',
            c: '%a %b %d %X %Y',
            r: '%I:%M:%S %p',
            T: '%H:%M:%S',
            v: '%e-%b-%Y',
            x: '%D'
        }
    }

Or consider returning localized dates alongside machine-readable dates in the API response.

I'm going to bump this to 3.2.1 but let me know if you can think of any short-term improvement that we could do in time for 3.2.

[asmecher]

Yuck, I had assumed that the implementation would rely on toLocaleDateString, which would rely on the client side to format/translate to the specified locale. I agree, we should not use anything that includes hard-coded languages, and this can wait.

[mhvezina]

I hope it's not irrelevant to add this here (as this is not tied specificaly to the Last activity recorded date issue) but I wanted to say, in my opinion, that the displays for the date formats used across the application should always be language specific.

Actually it's not the case as the date formats defined in config.inc.php apply uniformly to all locales.

I managed to find a way to accomodate our bilingual environments (French and English) by adopting an accepted bilingual way for us, that is to say :

date_format_long = "%e %B %Y"

7 February 2016
7 février 2016

(Consequently, I didn't keep the default U.S. kind of way to write the date (months first : February 10) eventhough I would have preferred this last syntax)

But this isn't always possible (depending on the combination of languages you are dealing with) and I would have preferred to use differents formats following the locale used.

Does that make sense?

[NateWr]

Thanks @mhvezina, that's a good point. I've filed that as a separate issue at #5540 because it's likely to not get resolved at the same time as this issue.

[NateWr]

Intl.RelativeTimeFormat is a new JavaScript object that may help us with the X days ago part of this. It has very low browser support so would need to make sure Babel is polyfilling it.