4

My site is multilingual (English and French) and built on WordPress. I have an event page which is translated. I get the right page version when I use lcMessages=(en_CA|fr_CA) in the URL. However, the date is always uses English month and day names regardless of the interface language. How do I fix this? I would have thought that this is something that would happen automatically in the multilingual site.

Screenshot of French labels and English date:

enter image description here

UPDATE: I posted some questions in what I thought was the developer area related and was met with silence. I can't believe no one else cares about this. Or maybe only I am having a problem. I'd really like to work on this, so if anyone has any direction on who to talk to to find the module maintainer to offer assistance, I'd appreciate it.

7
  • A similar problem for receipts came up a few months ago but there was no definitive solution. It seems like it works for some people but not others. civicrm.stackexchange.com/questions/34521/date-in-english
    – Demerit
    Apr 25 '20 at 16:33
  • Is it a setting in localisation, settings - date?
    – HanV
    Apr 25 '20 at 18:48
  • I have the same issues on all our CiviCRM sites. It's always mixed: 1 April 2020... I think there's a major improvement to be done in the code to help the internationalization work fine and unfortunately except complaining I can't really help :-/ Apr 29 '20 at 8:08
  • I'm looking to get involved in fixing this. I'm presuming that the issue is that the date content is coming from MySQL/MariaDB. It looks like it's possible to set @@lc_time_names for an individual connection without changing the server. I am going to do some local testing to confirm that, and see if I can patch my own code. Then I just have to figure out how to offer a patch.
    – kapn
    May 12 '20 at 19:22
  • I have done a little exploring in civicrm/CRM/Core/I18n.php and /civicrm/CRM/Utils/Date.php and found that the methods seem to be locale aware, but appear to use a more global locale (CiviCRM default, Wordpress default, or maybe System). I think I'll try to fiund the bug-reporting system and codebase to see if I can find a little guidance and maybe propose a patch there.
    – kapn
    May 12 '20 at 19:48
3

Your server must support the requested locale (ex: fr_FR.utf8).

On Debian-based systems, as root (administrator), you can enable it with:

dpkg-reconfigure locales

and then enable the locale. It does not need to be set as default. It will require restarting Apache or php-fpm.

To find out more, you can check in CRM/Utils/Date.php, the getFullMonthNames function basically does this:

  public static function &getFullMonthNames() {
    static $fullMonthNames;
    if (!isset($fullMonthNames)) {

      // set LC_TIME and build the arrays from locale-provided names
      CRM_Core_I18n::setLcTime();
      for ($i = 1; $i <= 12; $i++) {
        $fullMonthNames[$i] = strftime('%B', mktime(0, 0, 0, $i, 10, 1970));
      }
    }
    return $fullMonthNames;
  }

and this is what is used to replace the %B or %b placeholders in the date format settings.

There are two areas where we could definitely improve CiviCRM:

  1. in that function, it would seem fine by me to replace that code with a hardcoded list of months, which would be sent to translation using ts('January'). Many people do not have root access to their hosting.

  2. when installing into a specific language, automatically configure those settings because they are the worst possible treasure hunt in the world. There is an issue here, and the worst is mostly done, but just needs a bit of energy to get past the finish line: https://lab.civicrm.org/dev/translation/-/issues/1

If you are interested to contribute, please join the translation channel or the francophone channel. You can ping me on there too (@bgm), I also speak French.

2

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.