Localization of month in dateFormatLong

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.

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.

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?

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}

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?

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.

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

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.

In Ubuntu it’s:

LC_TIME=de_DE.utf8
date +%B

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.

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?

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: Linux export Command - javatpoint, 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: date - PHP setlocale has no effect - Stack Overflow (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: php-src/string.c at d339e5fcdcbaf45693713754cd5ef6bb0bcc0fd3 · php/php-src · GitHub
I’m not much familiar with C, but I think you can find examples on the web, regarding how to test it, e.g.: c - Testing locale on Ubuntu using setlocale() and gettext() - Stack Overflow.

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