09 July 2016, 0:20

Hello

We upgraded our test platform to Mahara 16.04.1 - french langpack.

We have an issue when we share page with specific dates that generates an error :

See picture :

If i switch to english langage, of course it works perfectly.

Is it fixed with recent versions or a know issue ?

Thanks for your support

Emilie

Enregistrer

Enregistrer

Enregistrer

11 July 2016, 14:11

Hi Emilie,

It looks like this was a problem in the French langpack for 16.04. There's a particular string in the langconfig.php file called "pieform_calendar_dateformat", which controls the date format in the calendar widget. One of the translators changed it from the default English langpack "%%Y/%%m/%%d" to "%%d/%%m/%%A". I think the intent there was to change it from "Year/Month/Day" format to "Day/Month/Year". But the "year" placeholder needs to be "%Y" rather than "%A", because it feeds into the PHP strftime function.

I've updated the French langpack in Launchpad, so that should update on langpacks.mahara.org in the next couple of days.

If you want to manually update your langpack in the meantime, in your langpacks directory look for this file: langpacks/fr.utf8/lang/fr.utf8/langconfig.php

And then in that file, change this line:

$string['pieform_calendar_dateformat'] = '%%d/%%m/%%A';

... to this:

$string['pieform_calendar_dateformat'] = '%%d/%%m/%%Y';

Cheers,

Aaron

11 July 2016, 14:41

... and in case anyone stumbles across this forum post in the future while looking up a similar problem, here's the technical background on the calendar widget. It's basically all written up in the comments in htdocs/lib/pieforms/pieform/elements/calendar.php, and on Launchpad bug 1445137, but this is the short version.

The calendar widget that we use throughout most of Mahara when you need to pick a date, is the JQuery UI calendar. The tricky thing about letting langpacks localize the date formats, is that we need to be able to specify the date format in three different ways:

1. PHP strftime (for handling it on the server side), like %Y/%m/%d

2. JQuery UI calendar (for the JS side), like yy/mm/dd

3. Human-readable, like YYYY/MM/DD (for the help popups)

We previously had these different date formats stored as separate language strings, but this basically caused bug 1445137, because translators using the Launchpad interface would have no reasonable way to know that these different date format strings need to correspond to each other, or what technical format to write them in. Moreover, the Javascript format might change from one release to the next if we swap in a new calendar widget (as we had done before).

So I wrote up a system that uses the PHP date and time format strings as the "canonical" one, and converts that as needed into the Javascript and human-readable formats. To support the human-readable formats, it includes a whole bunch of lang strings like 'element.calendar.format.help.dayofmonth1digit', which in English is "M".

So specifically:

1. In langconfig.php, there are strings "pieform_calendar_dateformat" and "pieform_calendar_timeformat", which contain the strftime-style format for dates and times. These strings are only used on the backend, and only by computer programs. Due to limitations in Mahara, you have to use two percentage marks instead of one, and for cross-compatibility with the Javascript calendar and localization, it's limited to only a subset of the allowed tags:

• %%e: day of month (no leading zero)
• %%d: day of month (two digit)
• %%m: month of year (two digit)
• %%y: year (two digit)
• %%Y: year (four digit)
• %%k: Hour (24-hour, no leading 0)
• %%H: Hour (24-hour, two digit)
• %%l (lowercase L): Hour (12-hour, no leading 0)
• %%I (uppercase i): Hour (12-hour, two digits)
• %%M: Minute (two digits)
• %%S: Second (two digits)
• %%P: am or pm (lowercase) (obviously shouldn't be used for locales where 24-hour time only is used)
• %%p: AM or PM (uppercase)

2. Alongside these, in the "pieforms.php" langfile, there are a bunch of langstrings with names like "element.calendar.format.help.dayofmonth1digit', etc. Each of these should be something like "YYYY", "MM", "HH", etc; however you would normally shorten these to tell the user e.g. to enter a date and time in the format "DD-MM-YYYY HH:MM am". Because this part is human readable, it's the one part where you should change the letters to match the language being translated. So for instance "element.calendar.format.help.year4digit" would be "YYYY" in English, but "AAAA" in Spanish.

3. When Mahara needs to tell the calendar widget what format to use for its dates & times, it uses the functions "pieform_element_calendar_convert_dateformat()" and "pieform_element_calendar_convert_timeformat()" to convert from the PHP format to the Javascript format.

4. When Mahara needs to print a human-readable shorthand for the date format, it uses functions "pieform_element_calendar_human_readable_dateformat()" and "pieform_element_calendar_human_readable_timeformat()" along with all those "element.calander.format.help..." strings, to generate a human-readable description of the date and/or time format.

5. When a user submits a form with a calendar widget in it, Mahara tries to flexibly interpret it into a Unix epoch time by using the PHP strtotime function. We use that, rather than a function that relies on a specific input format, to try to accommodate users who might bypass the JS calendar and type in a date by hand. But, one unfortunate limitation of strtotime is that it's Americo-centric, so if it sees an XX/YY/ZZ string, it'll always assume it's a m/d/y date. In the funtion "pieform_element_calendar_convert_to_epoch()" we work around that by examining pieform_calendar_dateformat and manipulating the input string if it seems to be a "dmy" date format.

Hm, I should probably put this up on the wiki...

Cheers,

Aaron

11 July 2016, 20:11

Hi Aaron

Thanks a lot for your feedback, i changed manually my langpack accordingly. Now, it works ! :-)

Cheers

Emilie