Date formats should allow different configurations for each language

[NateWr]

Describe the problem you would like to solve
The date formats are defined in the config file. Different languages may require distinct formats. This makes it challenging to find date formats that are appropriate across all languages. In a multi-tenant setup, where each journal is completely distinct, it may also be challenging to find a format that all tentants agree upon.

Describe the solution you'd like
A couple of options.

1. Allow distinct settings in the config file for each language:

date_format_long[en_US] = "%B %e, %Y"
date_format_long[fr_CA] = "%e %B %Y"

2. All unique date formats to be set for each journal/press through the in-app settings.

It would be nice to support both, so that defaults could be set in the config file and each journal/press manager could override them with their own. This would be particularly important for SaaS or multi-tenant setups.

cc @mfelczak to see if this is something hosting is interested in.

Who is asking for this feature?
An administrator of a multi-lingual journal. See the original request.

[mfelczak]

Yes, each journal/press in a multi-tenant install would need to be able to set their own date formats on a per locale basis to override global defaults.

[asmecher]

I can predict that the next request will be for date formats by user... would it not be a good general solution to just go with that?

[mhvezina]

I would be quite happy with a per locale basis, as date format is primarily linked to language used. If you want to offer it on a per user basis, I would (as a user) still have to define/specify a syntax/format tied to the language interfaces I use (if I use more than one language). Another option would be not to offer date formats long or short and apply the international ISO 8601 format : YYYY-MM-DD. But I guess not everyone will like that...

[asmecher]

Thanks, @mhvezina, that's very helpful; I would have expected that the user (that's you!) would not want the formats to change when they used several languages, but rather that they would use the one format of their preference. Can you describe your use case a little more?

[asmecher]

(FWIW I would love ISO8601 to become universal!)

[mhvezina]

Hi @asmecher,

(...) would have expected that the user (that's you!) would not want the formats to change when they used several languages, but rather that they would use the one format of their preference. Can you describe your use case a little more?

I guess expected behavior is the same whether date format is set by admin or user.

Let say I have a multi-journal instance, with 3 journals. One (A) uses only French (forms, submission, UI), another one (B) is trilingual (French, English, Spanish) and a last one (C) is only in English.

I think, what I would expect, as a user, is to see the date (long format) in a correct (most accepted? https://en.wikipedia.org/wiki/Date_format_by_country) format according to the locale of the UI and hence that is coherent with the rest of the text content displayed :

A : “Réponse requise pour le 7 février 2020”

B : English UI : “Response required by February 7, 2020”
B : French UI : “Réponse requise pour le 7 février 2020”
B : Spanish UI : “Respuesta requerida antes del 7 de febrero de 2020”

C : “Response required by February 7, 2020”

What I don’t want to see :

• Mix of languages:
  A : “Réponse requise pour le February 7, 2020”
  C : “Response required by 7 février 2020”

• Unique "%e %B %Y" format (or some other unique format) that do not fit all languages:
  B : English UI : “Response required by 7 February 2020”
  B : French UI : “Réponse requise pour le 7 février 2020”
  B : Spanish UI : “Respuesta requerida antes del 7 febrero 2020”

Conclusion for me: it’s really tied to the locale used by the user (hence strftime() in conjunction with setlocale()). Variants for English date formats are also tied to locale (en_US, en_GB, en_CA). I think I wouldn’t make that journal-based, nor user-based choice.

Again, adopting ISO 8601 would solve this issue. I wouldn’t be bothered to see a YYYY-MM-DD date, even in the email text… but I can’t talk for users and editors...

[NateWr]

I can predict that the next request will be for date formats by user

I think there are a couple issues that would arise from this. First, these date formats are used for public-facing information (article landing page) as well as internal info (activity dates in submission lists). Journals typically want to exercise firm control over the public-facing information and consistency is important. If an American reader sees MM/DD/YYYY and a British reader DD/MM/YYYY, there's likely going to be some uncertainty which can result from that if the publisher is British. The source of the information is part of how its recorded.

Second, I can see some benefit to offering user-control over internal info, but this would raise some tricky questions. For example, what happens when dates (like review due dates) are put into emails. If we use the sender's date format, the recipient might get some weird format they've never seen before. If we use the recipient's date format, the sender will see in the email preview a date format that looks wrong to them.

For these reasons I think it's right to ensure consistent use at a journal level. Journals are the authority responsible for setting consistent publishing and operating standards, and often want control over the experience that people have interacting with their journal.

[asmecher]

👍 Happy to be walked back from the precipice on this, @NateWr and @mhvezina!

[mhvezina]

If an American reader sees MM/DD/YYYY and a British reader DD/MM/YYYY, there's likely going to be some uncertainty which can result from that if the publisher is British

Yes...emails.... good point.... well for dates that are to be "shared" between users (like in an email), I would enforce/use ISO8601 format (or maybe allow the display format to be set at the journal level)

For web interfaces - internal (OJS dashboard), I would go for the locale user-based choice

For web interface - public (article landing page), I would go with, in this order of priority/precedence: (1) the locale set by the OJS user if any (if language toggle is present on the OJS public website), then (2) the locale user's browser.

My understanding is that dates should always be stored in a standard format (ISO8601) ; format conversion functions should be use each time a different display format is needed (e.g. web interfaces).

[NateWr]

for dates that are to be "shared" between users (like in an email), I would enforce/use ISO8601 format (or maybe allow the display format to be set at the journal level)

We do use date_format_short, which is usually YYYY-MM-DD, as a fallback. However, I'd like to discourage this. Although for us it's a common format, it's unusual for non-technical audiences and can be one more unnecessary cognitive hurdle for them. This would particularly impact those with a sporadic relationship with the journal, like reviewers and authors.

For web interfaces - internal (OJS dashboard), I would go for the locale user-based choice

I think there's a case to be made for editors and editorial assistants to be have some control over how dates are displayed to them. But I am not sure how many would actually discover the setting and then take the time to customize it. In my experience, most users take the path of least resistance and I would be very surprised if more than 1% of them ever bothered to change the setting.

For web interface - public (article landing page), I would go with, in this order of priority/precedence: (1) the locale set by the OJS user if any (if language toggle is present on the OJS public website), then (2) the locale user's browser.

We can't rely on the locale of the user's browser because the content is delivered from the server side, which doesn't have access to that information. I think our current approach -- the journal's primary locale by default, with the user able to switch languages -- is the right approach. In the vast majority of cases, users are not logged in when viewing the article landing page, so it doesn't seem like there would be much to gain here from allowing users to set their own date formats.

My understanding is that dates should always be stored in a standard format (ISO8601)

Yes, all of our dates are stored this way.

[mhvezina]

Hi @NateWr,

Yes, I undersand that ISO8601 date format in correspondence might not be the most appropriate...

Regarding "non-shared" dates :

For web interfaces - internal (OJS dashboard), I would go for the locale user-based choice

I meant to go with the default date format based on the user locale conventions (the date rendering would then be something to what the JS method toLocaleDateString() does), not add a setting to offer the user to choose a date format in the user profile (which, as you said, no one will bother to set).

(...) like there would be much to gain here from allowing users to set their own date formats.

No, no gain. Again I meant to go with the date format associated to the locale chosen by the user, if any. If not, fallback on the date format associated to the locale user's browser.

So, what it would look like for a localized long date format would be something like that :

Format for long (or short) dates could be however set by Journal's editor for each of the chosen languages set by the Journal (e.g. whether "March 11, 2020" or "Wednesday, March 11, 2020"; "11 mars 2020" or "Mercredi 11 mars 2020").

[NateWr]

Ah, sorry for misunderstanding you! Then I think we're in total agreement here. Each journal needs to be able to set separate date formats for each locale they support. 👍

[Vitaliy-1]

@NateWr, I can't understand why there are 2 pairs of date and date-time formats and time format as a separate setting. Would it be simpler to diminish the number of settings by combining them? I mean, there are 5 settings: date_format_short, date_format_long, datetime_format_short, datetime_format_long and time_format but datetime_format... can be constructed just by combining date and time formats. Are there situations when it can't be done? If a delimiter between date and time can be important, it's more straightforward to have a setting just for that.

[Vitaliy-1]

After thinking about it for a while, my proposal is 3 mandatory fields: long date format, short date format and time format plus 2 optional fields: long and short date & time with 2 values - default, which simply consists of values from long or short date + time and custom field to allow user own input.

[NateWr]

We typically avoid concatenating two localised strings into one, because some languages may wish to change the order. For example, some languages may want <date> <time> and some may want <time> <date>.

I think that we can get to the same easy UX by automatically completing the datetime formats for people. If you are using the FieldRadioInput, you can create a custom Form component that automatically updates the preset options whenever the date_format_long or other values are changed.

So the options can be:

• %Y-%m-%d %I:%M %p (2020-07-10 12:31 pm)
• ______________ (input field)

And if the user changes date_format_short to %m/%d/%Y the options can change to:

• %m/%d/%Y %I:%M %p (07/10/2020 12:31 pm)
• ______________ (input field)

[Vitaliy-1]

PR to ui-libary master: pkp/ui-library#113
pkp-lib master: #6144
OJS master: pkp/ojs#2845

[NateWr]

Thanks @Vitaliy-1! I gave it a test and it's working well. Looks like the datetime format syncing got pretty complicated. 🔨

I've left some comments on the PRs -- mostly just some text and variable naming adjustments. In addition:

1. Remove date_format_trunc and dateFormatTrunc. I don't believe we use it anywhere.
2. In the form, move the long formats up above the short formats.
3. Run npm run lint on the UI Library. There are still some formatting warnings showing up.
4. We'll need PRs for OMP/OPS as well.

Otherwise it looks good to go, nice work!

[NateWr]

🎉 All merged! Thanks @Vitaliy-1.

[NateWr]

@amandastevens This may effect documentation. In 3.3 it will be possible to configure the date formats for each journal and locale. In previous versions the format could only be set in the config file, and the same format was used for all journals in all locales.

This screenshot shows OMP but it's the same in OJS, OMP and OPS.

[asmecher]

@Vitaliy-1, I think something related to this is causing the OMP Travis tests to fail recently. The logs fill with..

[02-Dec-2020 18:46:37 UTC] PHP Warning:  array_key_exists() expects parameter 2 to be array, null given in /home/travis/build/pkp/omp/lib/pkp/classes/context/Context.inc.php on line 308
[02-Dec-2020 18:46:37 UTC] PHP Stack trace:
[02-Dec-2020 18:46:37 UTC] PHP   1. {main}() /home/travis/build/pkp/omp/index.php:0
[02-Dec-2020 18:46:37 UTC] PHP   2. Application->execute() /home/travis/build/pkp/omp/index.php:64
[02-Dec-2020 18:46:37 UTC] PHP   3. Dispatcher->dispatch($request = class Request { public $_router = class PageRouter { public $_installationPages = [...]; public $_page = 'management'; public $_op = 'settings'; public $_indexUrl = 'http://localhost/index.php'; public $_cacheFilename = NULL; public $_application = class Application { ... }; public $_dispatcher = class Dispatcher { ... }; public $_contextDepth = 1; public $_contextList = [...]; public $_flippedContextList = [...]; public $_contextPaths = [...]; public $_contexts = [...]; public $_handler = class SettingsHandler { ... } }; public $_dispatcher = class Dispatcher { public $_application = class Application { ... }; public $_routerNames = [...]; public $_routerInstances = [...]; public $_router = class PageRouter { ... }; public $_requestCallbackHack = NULL }; public $_requestVars = []; public $_basePath = ''; public $_requestPath = '/index.php/publicknowledge/management/settings/website'; public $_isRestfulUrlsEnabled = FALSE; public $_isPathInfoEnabled = TRUE; public $_serverHost = 'localhost'; public $_protocol = 'http'; public $_isBot = NULL; public $_userAgent = 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/83.0.4103.116 Safari/537.36' }) /home/travis/build/pkp/omp/lib/pkp/classes/core/PKPApplication.inc.php:353
[02-Dec-2020 18:46:37 UTC] PHP   4. PageRouter->route($request = class Request { public $_router = class PageRouter { public $_installationPages = [...]; public $_page = 'management'; public $_op = 'settings'; public $_indexUrl = 'http://localhost/index.php'; public $_cacheFilename = NULL; public $_application = class Application { ... }; public $_dispatcher = class Dispatcher { ... }; public $_contextDepth = 1; public $_contextList = [...]; public $_flippedContextList = [...]; public $_contextPaths = [...]; public $_contexts = [...]; public $_handler = class SettingsHandler { ... } }; public $_dispatcher = class Dispatcher { public $_application = class Application { ... }; public $_routerNames = [...]; public $_routerInstances = [...]; public $_router = class PageRouter { ... }; public $_requestCallbackHack = NULL }; public $_requestVars = []; public $_basePath = ''; public $_requestPath = '/index.php/publicknowledge/management/settings/website'; public $_isRestfulUrlsEnabled = FALSE; public $_isPathInfoEnabled = TRUE; public $_serverHost = 'localhost'; public $_protocol = 'http'; public $_isBot = NULL; public $_userAgent = 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/83.0.4103.116 Safari/537.36' }) /home/travis/build/pkp/omp/lib/pkp/classes/core/Dispatcher.inc.php:143
[02-Dec-2020 18:46:37 UTC] PHP   5. PageRouter->_authorizeInitializeAndCallRequest($serviceEndpoint = [0 => class SettingsHandler { public $_isBackendPage = TRUE; protected $_apiToken = NULL; public $_id = 'management'; public $_dispatcher = class Dispatcher { ... }; public $_checks = [...]; public $_roleAssignments = [...]; public $_authorizationDecisionManager = class AuthorizationDecisionManager { ... }; public $_enforceRestrictedSite = TRUE; public $_roleAssignmentsChecked = TRUE }, 1 => 'settings'], $request = class Request { public $_router = class PageRouter { public $_installationPages = [...]; public $_page = 'management'; public $_op = 'settings'; public $_indexUrl = 'http://localhost/index.php'; public $_cacheFilename = NULL; public $_application = class Application { ... }; public $_dispatcher = class Dispatcher { ... }; public $_contextDepth = 1; public $_contextList = [...]; public $_flippedContextList = [...]; public $_contextPaths = [...]; public $_contexts = [...]; public $_handler = class SettingsHandler { ... } }; public $_dispatcher = class Dispatcher { public $_application = class Application { ... }; public $_routerNames = [...]; public $_routerInstances = [...]; public $_router = class PageRouter { ... }; public $_requestCallbackHack = NULL }; public $_requestVars = []; public $_basePath = ''; public $_requestPath = '/index.php/publicknowledge/management/settings/website'; public $_isRestfulUrlsEnabled = FALSE; public $_isPathInfoEnabled = TRUE; public $_serverHost = 'localhost'; public $_protocol = 'http'; public $_isBot = NULL; public $_userAgent = 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/83.0.4103.116 Safari/537.36' }, $args = [0 => 'website'], $validate = FALSE) /home/travis/build/pkp/omp/lib/pkp/classes/core/PKPPageRouter.inc.php:246
[02-Dec-2020 18:46:37 UTC] PHP   6. SettingsHandler->settings($args = [0 => 'website'], $request = class Request { public $_router = class PageRouter { public $_installationPages = [...]; public $_page = 'management'; public $_op = 'settings'; public $_indexUrl = 'http://localhost/index.php'; public $_cacheFilename = NULL; public $_application = class Application { ... }; public $_dispatcher = class Dispatcher { ... }; public $_contextDepth = 1; public $_contextList = [...]; public $_flippedContextList = [...]; public $_contextPaths = [...]; public $_contexts = [...]; public $_handler = class SettingsHandler { ... } }; public $_dispatcher = class Dispatcher { public $_application = class Application { ... }; public $_routerNames = [...]; public $_routerInstances = [...]; public $_router = class PageRouter { ... }; public $_requestCallbackHack = NULL }; public $_requestVars = []; public $_basePath = ''; public $_requestPath = '/index.php/publicknowledge/management/settings/website'; public $_isRestfulUrlsEnabled = FALSE; public $_isPathInfoEnabled = TRUE; public $_serverHost = 'localhost'; public $_protocol = 'http'; public $_isBot = NULL; public $_userAgent = 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/83.0.4103.116 Safari/537.36' }) /home/travis/build/pkp/omp/lib/pkp/classes/core/PKPRouter.inc.php:391
[02-Dec-2020 18:46:37 UTC] PHP   7. SettingsHandler->website($args = [], $request = class Request { public $_router = class PageRouter { public $_installationPages = [...]; public $_page = 'management'; public $_op = 'settings'; public $_indexUrl = 'http://localhost/index.php'; public $_cacheFilename = NULL; public $_application = class Application { ... }; public $_dispatcher = class Dispatcher { ... }; public $_contextDepth = 1; public $_contextList = [...]; public $_flippedContextList = [...]; public $_contextPaths = [...]; public $_contexts = [...]; public $_handler = class SettingsHandler { ... } }; public $_dispatcher = class Dispatcher { public $_application = class Application { ... }; public $_routerNames = [...]; public $_routerInstances = [...]; public $_router = class PageRouter { ... }; public $_requestCallbackHack = NULL }; public $_requestVars = []; public $_basePath = ''; public $_requestPath = '/index.php/publicknowledge/management/settings/website'; public $_isRestfulUrlsEnabled = FALSE; public $_isPathInfoEnabled = TRUE; public $_serverHost = 'localhost'; public $_protocol = 'http'; public $_isBot = NULL; public $_userAgent = 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/83.0.4103.116 Safari/537.36' }) /home/travis/build/pkp/omp/lib/pkp/pages/management/ManagementHandler.inc.php:67
[02-Dec-2020 18:46:37 UTC] PHP   8. PKP\components\forms\context\PKPDateTimeForm->__construct($action = 'http://localhost/index.php/publicknowledge/api/v1/contexts/1', $locales = [0 => ['key' => 'en_US', 'label' => 'English'], 1 => ['key' => 'fr_CA', 'label' => 'Français (Canada)']], $context = class Press { public $_data = ['id' => 1, 'urlPath' => 'publicknowledge', 'enabled' => TRUE, 'seq' => 1, 'primaryLocale' => 'en_US', 'submissionChecklist' => [...], 'supportedFormLocales' => [...], 'librarianInformation' => [...], 'name' => [...], 'openAccessPolicy' => [...], 'privacyStatement' => [...], 'readerInformation' => [...], 'defaultReviewMode' => 2, 'emailSignature' => '<br/>\n________________________________________________________________________<br/>\n<a href="{$ldelim}$contextUrl{$rdelim}">{$ldelim}$contextName{$rdelim}</a>', 'disableSubmissions' => FALSE, 'itemsPerPage' => 25, 'numPageLinks' => 10, 'numWeeksPerResponse' => 4, 'numWeeksPerReview' => 4, 'keywords' => 'request', 'authorInformation' => [...], 'contactEmail' => 'rvaca@mailinator.com', 'contactName' => 'Ramiro Vaca', 'customHeaders' => [...], 'mailingAddress' => '123 456th Street\nBurnaby, British Columbia\nCanada', 'searchDescription' => [...], 'supportedLocales' => [...], 'supportedSubmissionLocales' => [...], 'supportEmail' => 'rvaca@mailinator.com', 'supportName' => 'Ramiro Vaca', 'themePluginPath' => 'default', 'type' => 'enable', 'coverThumbnailsMaxWidth' => 106, 'coverThumbnailsMaxHeight' => 100, 'paymentPluginName' => 'ManualPayment', 'acronym' => [...]]; public $_hasLoadableAdapters = FALSE; public $_metadataExtractionAdapters = []; public $_extractionAdaptersLoaded = FALSE; public $_metadataInjectionAdapters = []; public $_injectionAdaptersLoaded = FALSE }) /home/travis/build/pkp/omp/lib/pkp/pages/management/ManagementHandler.inc.php:172
[02-Dec-2020 18:46:37 UTC] PHP   9. Press->getDateTimeFormats($format = 'dateFormatShort') /home/travis/build/pkp/omp/lib/pkp/classes/components/forms/context/PKPDateTimeForm.inc.php:71
[02-Dec-2020 18:46:37 UTC] PHP  10. array_key_exists($key = 'en_US', $search = NULL) /home/travis/build/pkp/omp/lib/pkp/classes/context/Context.inc.php:308

Could you take a look?

[asmecher]

@Vitaliy-1, hmm, this must be something related to my repo, as it's not failing on the official master branch. Let me look into it more before bringing you in.

[NateWr]

I've encountered it in my OMP test failures here: https://travis-ci.com/github/pkp/omp/builds/205889218. I'll look into it now unless either of you have already figured it out?

[NateWr]

I think this arises when there are no custom datetime formats defined for a journal, press or preprint server. It should be fixed in 872a4fe. It's being tested now at pkp/omp#890 and will get merged in with that if it passes.

[NateWr]

The commit fixes the PHP notice even though the tests are still failing. Anyway, nothing more related to this issue I think.

[ajnyga]

I know this is closed, but just wanted to drop by and say that this was a great new feature that has been requested many times by our journals. Thanks for the work!