Thanks for spotting that, Ralf.

Estimated time: 7 hours

Hi Apu, as we discussed this issue I assigned you as Peer Reviewer. I have two solutions. MDL-31622-23 for a basic handling of the strings, and:

https://github.com/FMCorz/moodle/compare/MOODLE_23_STABLE...MDL-31622-23-2nd

for i18n using the system locale, as the calendar system does pretty much everywhere. This patch is actually messy and I don't really like it, even though it creates consistency with the system.

The first patch create lang strings which won't be used very often, probably only for the date selector at that stage, but that's cleaner (IMO).

Both patches are not meant to be pushed for integration yet, but to demonstrate possible ways of doing it. (the substr() is definitely a bad approach)

Hi Fred,

• have you noted moodle_setlocale() ? just noting that there are cross OS issues etc being handled there.
• according to some quick googling, yui calendar has some built in language sets - how do we use those?
• presently i like the '2nd' solution but i don't like that we're calculating time and substr()'s everytime. (not sure we have to or not though)

note:have you seen the bug trail from MDL-17672 -> MDL-26391 & MDL-22625 re timing issues.

• http://developer.yahoo.com/yui/examples/calendar/taiwan.html shows there can be more complications in this calculation with various locales having different possible settings for time offsets wrt julian calendar. (i shudder to think of gregorian or other cultures)

Mainly, i think there must be a better, more supported way to do this though : maybe compatible easily with http://localize.drupal.org/translate/downloads?project=yui_calendar :-D (not sure if we already do)

Anyway, for good measure i've added our renown language master, David Mudrak, to lend his wise opinion.

Hi Apu, thanks for reviewing this.

You are right, the second solution shouldn't be calculating those values each time. I also noticed that using substr() is probably very bad! Thinking about languages like Japanese or others using a different alphabet, one character shorter/longer could lead to a completely different word.

Thinking about the YUI translations, I first noticed that they were missing a lot of translations. The second problem is those extra parameters. I am not sure we want people to change their calendar to another type than Gregorian for now (seeing related issues about TZ). I think the first thing we should focus on is to translate those weekdays/months names.

Now, the last thing is that in order to have those complete translations for weekdays and months, we need 1-char, 2-chars, 3-chars and full length weekday names, which LC_TIME does not provide. As I mentioned, substr() is not a good option to shorten those words. We could also change the layout of YUI to have those 3-chars length weekdays, but that requires a bit of theming.

All in all, having $string['monday'] = strftime('%A', 12345); in lang/langconfig.php is maybe not the worst option. Assuming that AMOS will understand it. This file already contains some 'advanced translators strings'.

Sorry, things like

 $string['monday'] = strftime('%A', 12345);

in Moodle string files are unacceptable. Only static strings are allowed there, no PHP eval, no concatenation (and not only because of AMOS).

WRT one-char abbreviations of week day names - note these are not an option in some languages, including English. Even two-chars might be an issue in some langs. And of course, substr() is generally bad for these things, as is noted above.

Without looking into this issue deeply, I would suggest 1) let us try the reuse the current approach (ie using names provided by locale) as much as possible. 2) Only when at the end we find that approach too limiting, we might introduce these names as Moodle native strings and inject them into YUI. Ideally in a way that is easily maintainable during YUI upgrades (compare to what we already do for TinyMCE, for example). However, I believe we are not the first project facing this issue...

Thanks for your feedback David. There is a method which relates on locales, I guess that would be enough as long as we don't want to have longer/shorter weekdays/months in the calendar.

Apu, it's up for your review .

I like the patch, thanks Fred.

Hi Fred,
this look alright to me.

i did wonder about how this isn't using any of our caching on disk. looked at langconfig.php but i'm not so familiar there. anyway spent enough time and this does look alright to push up for further integration review.

Thanks for your review Apu. I guess we are not using any caching system because we are usually outputting the months/days of week by using strftime(). We would need to first use strftime() to extract the month from a timestamp and then read the cache (in most cases), which does mot make sense.

The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

TIA and ciao

Thanks Fred, i've integrated this now.

I'm not so keen on those bare epoch time values, I might've been tempted to use some string to time
function, but I suppose we're saving some CPU cycles this way.

strftime('%a', strtotime('Monday'));

After discussing it with Tim, assigning the test to Andrew as I was both assignee and tester on this issue.

I'm having some trouble testing this in master.

"Installing corresponding locales on your system `sudo locale-gen --no-archive ja_JP.UTF-8`"

Is there any reason to do this rather than going to /admin/tool/langimport/index.php to install language packs? I've not had to modify my system outside of Moodle before just to support other languages.

The answer to that may possibly invalidate the following results.

I tried Bahasa Melayu, German and Arabic. No translation in Malay. The translation in German and Arabic was inconsistent. Days of the week are translated in calendar blocks but not in the calendar popup while adding an event. Either Im misunderstanding the testing instructions, I need to test this in a specific language or something is wrong. screenshots attached.

I'll be offline for a few hours. If necessary this can be re-assigned to someone else to test.

Actually, the one and only place where Moodle requires some locales to be installed on the machine is when handling date translation. The calendar uses LC_TIME to print out month and week of days. To keep consistency with that behaviour, I used the same principle for the popup calendar.

The command line that I wrote in the test instructions is to install the Japanese language pack. I don't know what is the lang code for Arabic, German is probably de_DE.UTF-8.

I've installed de_DE.UTF-8 (German) and ar_QA.UTF-8 (Qatar Arabic I believe) and will see how I go now.

Works as described with German. I'm still having trouble with Arabic but I suspect that I haven't got it set up correctly.

*Notice*: Undefined variable: friendlyintegrator in /Users/danp/git/tokenintegrationthanks.php on line 26

Congratulations

!

You've made into Moodle

+

I would like to personally thank you for this contribution on behalf of all Moodle users throughout the world.

cheers!

The code changes to formlib.php are causing a regression bug. MDL-34708

To fix it, we changed the code from:

$config = array(array(
'firstdayofweek' => get_string('firstdayofweek', 'langconfig'),
'mon' => strftime('%a', 360000), // 5th Jan 1970 at 12pm
'tue' => strftime('%a', 446400),
'wed' => strftime('%a', 532800),
'thu' => strftime('%a', 619200),
'fri' => strftime('%a', 705600),
'sat' => strftime('%a', 792000),
'sun' => strftime('%a', 878400),
'january' => strftime('%B', 14400), // 1st Jan 1970 at 12pm
'february' => strftime('%B', 2692800),
'march' => strftime('%B', 5112000),
'april' => strftime('%B', 7790400),
'may' => strftime('%B', 10382400),
'june' => strftime('%B', 13060800),
'july' => strftime('%B', 15652800),
'august' => strftime('%B', 18331200),
'september' => strftime('%B', 21009600),
'october' => strftime('%B', 23601600),
'november' => strftime('%B', 26280000),
'december' => strftime('%B', 28872000)
));

To:

$config = array(array(
'firstdayofweek' => get_string('firstdayofweek', 'langconfig'),
'mon' => strftime('%a', strtotime("Monday")), // 5th Jan 1970 at 12pm
'tue' => strftime('%a', strtotime("Tuesday")),
'wed' => strftime('%a', strtotime("Wednesday")),
'thu' => strftime('%a', strtotime("Thursday")),
'fri' => strftime('%a', strtotime("Friday")),
'sat' => strftime('%a', strtotime("Saturday")),
'sun' => strftime('%a', strtotime("Sunday")),
'january' => strftime('%B', strtotime("January")), // 1st Jan 1970 at 12pm
'february' => strftime('%B', strtotime("February")),
'march' => strftime('%B', strtotime("March")),
'april' => strftime('%B', strtotime("April")),
'may' => strftime('%B', strtotime("May")),
'june' => strftime('%B', strtotime("June")),
'july' => strftime('%B', strtotime("July")),
'august' => strftime('%B', strtotime("August")),
'september' => strftime('%B', strtotime("September")),
'october' => strftime('%B', strtotime("October")),
'november' => strftime('%B', strtotime("November")),
'december' => strftime('%B', strtotime("December"))
));

Fred, in case you didn't see - MDL-34708

Thanks Dan, I guess trying to minimize unnecessary processing was a bad idea here. Thanks for the report and the patch Matthew.