Moodle

Verified against 1.6.4+, patch will apply correctly!

Simple fix, can't this be merged?

I do not think this is correct: "If you have a multilingual environment you still have one locale,..."

The setting for system locale should be now blank, instead locale for language is now defined in each language pack - you have different locale for each language.

Hi Petr!
Even with locales defined on each language pack, there are a lot of them that are untouched on time entries, and %p is present,
this simple fix would avoid %p simply being translated to null string.
Paulo

I do not understand: ... untouched on time entries
does it mean there is a problem with definition in some locales?

Could you give me some examples, so that I can replicate the problem?

I was referring to the definitions of time related strings on moodle language packs, like on lang/../moodle.php:

$string['strftimedate'] = '%%d %%B %%Y';
$string['strftimedateshort'] = '%%d %%B';
$string['strftimedatetime'] = '%%d %%B %%Y, %%H:%%M';
$string['strftimedaydate'] = '%%A, %%d %%B %%Y';
$string['strftimedaydatetime'] = '%%A, %%d %%B %%Y, %%H:%%M';
$string['strftimedayshort'] = '%%A, %%d %%B';
$string['strftimedaytime'] = '%%a, %%H:%%M';
$string['strftimemonthyear'] = '%%B %%Y';
$string['strftimerecent'] = '%%d %%b, %%H:%%M';
$string['strftimerecentfull'] = '%%a, %%d %%b %%Y, %%H:%%M';
$string['strftimetime'] = '%%I:%%M %%p';

So, if the portuguese language pack had (and actually it has) $string['strftimetime'] was defined as above, it will produce this results:
06h30 --> 6:30
18h30 --> 6:30
because on pt locale (at operating system level) %p is set to a blank (and that's not the only case).

You should probably say, so why not fix all language packs? That's one approach, this one will prevent the scenario I stated before.
So, with the fix, the results would be:
06h30 --> 6:30 a.m.
18h30 --> 6:30 p.m
Which of course, for us wil be incorrect since we use the 24h-format, nevetheless we will be able to distinguish the times and noticed the error so we can easly identify and correct language packs.

Is it clear now?

Regards,
Paulo

Now I understand, but I do not like this kind of workarounds - I prefer to fix language packs and keep the code simple so that everybody understands it.

If you tell me what language packs are broken I will fix them.

That's the problem! I only can tell you about portuguese: all time representation must use %H and %M instead of %I %M and %p.
Then, the locale is OS dependent, so you can have %p blank or not...

test-closing.

thanks Eloy tracker was timing out for me

I have fixed the pt locale in lang cvs and reviewed all others that use %%p, seems pt was the only one with this problem.

Thanks for the report and cooperation!

Seems that one has missed
Looking at pt lang pack messagge.php:

<?PHP // $Id: message.php,v 1.6 2008/01/15 20:31:19 villate Exp $
// message.php - created with Moodle 2.0 dev (2007101506)
(... line 64 ...)
$string['strftimedaydatetime'] = '%%A, %%d %%B %%Y, %%I:%%M %%p';
(...)
—

where it should be:
$string['strftimedaydatetime'] = '%%A, %%d %%B %%Y, %%H:%%M';

Cheers,

Paulo Matos

This was an old issue and I did not recalled all the minor details on my previous comments.
The problem is related with the locale set on global settings not the language settings of the user.

Using a locale setting as pt_PT on global settings %p is set to blank. An user that has defined it's own language as English,
will have %p on date format, so it will loose AM/PM information, since on system locale %p is letf to blank.

The inital patch still makes sense, the scope of this problem isnt strict for Portuguese language nor language pack.

Regards,

Paulo

Can't confirm which systems/locales have %p set to blank but would dare to say that portuguese will not be alone on this quest.

That's right! We have the same problem with de_DE.UTF8.

So what's to do? Setting the locale to english before printing the time and then set it back to the global settings?

Pardon - didn't see the patch.

Here is the patch for the 1.8.x branch.

Paulo Matos

Please contact the lang pack maintainers to fix the problems there.

fixed de and pt packs in cvs

Petr!
Seems to be a miscommunication here! Although there were some minor problems with lang packs,
THE ISSUE IS NOT WITH LANG PACKS!

If (locale is pt_PT or de_DE) AND your user has English language

it will use English language pack, and

$string['strftimetime'] = '%%I:%%M %%p';

HOWEVER %p is set to null on locale.

That's what this patch addresses.

I do not understand - user selects language and locale is specified in that language pack, where is the problem?

There is not a "single locale" anymore, this was changed around Moodle 1.5.x

Hi Petr

Problem is that there are places where date/time format isn't taken directly from lang packs. I've "grepped" the code (1.8.4) and found the following:

calendar/lib.php:define ('CALENDAR_TF_12', '%I:%M %p');

files/index.php: $filedate = userdate(filemtime($filename), "%d %b %Y, %I:%M %p");
files/index.php: $filedate = userdate(filemtime($filename), "%d %b %Y, %I:%M %p");

lib/editor/htmlarea/coursefiles.php: $filedate = userdate(filemtime($filename), "%d %b %Y, %I:%M %p");
lib/editor/htmlarea/coursefiles.php: $filedate = userdate(filemtime($filename), "%d %b %Y, %I:%M %p");

mod/survey/download.php: $myxls->write_string($row,$col++, userdate($results["$user"]["time"], "%d-%b-%Y %I:%M:%S %p") );
mod/survey/download.php: $myxls->write_string($row,$col++, userdate($results["$user"]["time"], "%d-%b-%Y %I:%M:%S %p") );
mod/survey/download.php: echo userdate($results["$user"]["time"], "%d-%b-%Y %I:%M:%S %p")."\t";

Paulo's patch is one approach, but perhaps what should be done here is to take the format strings above and substitute by one of those strftimeXXX lang strings.

Thanks in advance

Oh, these should be definitely fixed, big thanks for pointing this out!

Ok in fact you are right Petr, there is a locale configuration per lang pack!
Namely:
$string['locale']= ...

However, I could not find (on 1.8.4+) any occurence of get_string('locale') in any part of the moodle source,
which means that this definition is not used at all. Please correct me if I'm wrong.

Steps to reproduce the problem:

Sometime after noon
1) Go to: Site Administration -> Language -> Language settings
and set:

lang = pt
langmenu : checked
langlist = pt_utf8,en_utf8
locale = pt_PT.UTF8

2) Go to your profile and choose English as "Preferred language"
3) Logout and login
4) Go to your profile (by clicking on your name on the right upper/lower corner of the screen)
Check the time of your Last access

You'll be able to see that ante/post-meridian information is not there.

Do not set the $CFG->locale !

"Choose a sitewide locale - this will override the format and language of dates for all language packs (though names of days in calendar are not affected). You need to have this locale data installed on your operating system (eg for linux en_US.UTF-8 or es_ES.UTF-8). In most cases this field should be left BLANK."

Lang pack locale is used, see moodle_setlocale()

Ok. I got it now! However, since locale names are OS dependent, the problem persist, for example the linux equivalent of pt_PT on Windows XP is prt_ptg, so you'll have to set $CFG->locale since it differs from the one defined on lang pack.

hmm, we have independent locales for *nix and windows

Ok, you'll cover a lot of cases then, but not all .
I rest my case, there's no point to continue this discussion.

Oops, sorry for the noise, resolving as not a bug - if $CFG->locale is empty the lang packs contain the correct locale settings. Please file separate issues for locales with incorrect settings, thanks.