Localization of month in dateFormatLong

Software Support
1

I’m using OJS 3.3.0.8 and healthScience 1.1.0

When showing a date in long format (e.g. “June 4, 2020” in “homepage-issue-published”), the name of the month is not translated to the chosen locale. How can we change this? It also doesn’t seem to be depending on the locale of the browser.

2

Hi @edelm,

In short, it depends on the locales installed on the server, meaning the operational system. On Ubuntu, I use locale -a command to check installed locales. If you don’t have access to the server’s command line, I recommend asking your system administrator about that to exclude the possibility that it’s not installed.

4

Thanks for your reply.

I use the docker ojs (GitHub - pkp/docker-ojs: Open Journal Systems (OJS) is a journal management and publishing system.), which builds on alpine linux. Unfortunately, on alpine, it doesn’t seem to be easy to add locales. So I used the way described on Add locales to your Alpine Linux Docker image | GRRR Tech to install locales (I need “de_DE”).

Still, the date gets displayed as “June 4, 2020”.

Do you have any ideas how to solve this?
Or is anyone else having this issues?

5

Can you check which locale is used by PHP when the date is formated?

{setlocale(LC_ALL, 0)}

before the line: healthSciences/indexJournal.tpl at 722d2baf853fb1d936aa50d7a2d2bfc99824029e · pkp/healthSciences · GitHub
This will display the locale before the formatted date, thus, if it’s a production instance, it would be better to route this to the error log, e.g.:

{capture}{setlocale(LC_ALL, 0)|error_log}{/capture}
6

Good idea for debugging! I did it and it showed “de_DE.utf-8 Publiziert December 1, 2020” (still wrong).
I checked “/usr/share/i18n/locales/musl/de_DE.UTF-8” and it contains “Dezember” (which is correct).
I also copied the file “de_DE.UTF-8” and named the copy “de_DE.utf-8” to check if it’s a upper/lower case issue. Didn’t have any effect, though.
Do you have any more ideas on how to get to the source of this behaviour?

7

This means that the system uses the right locale. I’d also check LC_TIME category

{setlocale(LC_TIME, 0)}

Usually, categories are installed all together but it makes sense to double-check.

8

“{setlocale(LC_TIME, 0)}” shows “de_DE.utf-8” as well.

9

In the next step I’d try directly change the system locale to de_DE and see if date is getting translated by typing something like date +%B in the terminal. I’m not familiar with Alpine Linux, thus cannot give more direct recommendations.

10

In Ubuntu it’s:

LC_TIME=de_DE.utf8
date +%B
11

I tried that and it still uses the English word.
Guess it’s an issue with the alpine/locale installation, then.
Have to dig deeper there.

12

Ok, it shows the correct translation in the console of alpine linux, if I do:

export LANG=de_DE.UTF-8
date +%B

So it seems to work on OS level but not on PHP/OJS?

13

Unlikely it’s OJS. In this case, there should be other reports as well.

I’m not sure about the export command. E.g. here: https://www.javatpoint.com/linux-export-command, it’s said that:
It does not affect the existing environment variable.
But I’m not an expert here.

Test PHP directly is quite easy, just create a script and run it through a web server: https://stackoverflow.com/questions/10909911/php-setlocale-has-no-effect (not through a command line as we don’t want to test CLI version).

Also, it looks like from a PHP source code that it relies on the setlocale() function from C language: https://github.com/php/php-src/blob/d339e5fcdcbaf45693713754cd5ef6bb0bcc0fd3/ext/standard/string.c#L4808
I’m not much familiar with C, but I think you can find examples on the web, regarding how to test it, e.g.: https://stackoverflow.com/questions/34655966/testing-locale-on-ubuntu-using-setlocale-and-gettext.

14

I was playing around with php and your inputs. Strangely, it had to test out several php calls in different orders, but in the end what worked was:

setlocale(LC_ALL, ‘de_DE.utf-8’);
echo strftime(‘%B’);

Since I got those calls also in the beginning of my playing around, I assume it must have been a cache issue somewhere, but I made sure the browser wasn’t caching.
Anyway, the translation works now. I still get “Publiziert Dezember 1, 2020” and not “Publiziert 1. Dezember 2020”. But it might depend on settings I can change in the OJS backend, have to check that.
Thanks for your inputs!

1 Like