|
[
Permalink
| « Hide
]
Gordon Bateson added a comment - 02/Apr/08 08:30 PM - edited
added screensnips showing the calendar and recent activity dates as they appear in English, Japanese and Chinese
You may notice that the attached userdate() function also has two other fixes.
First is an improvement for the removal of the leading "0" from %d (two-digit day of month). Currently the leading zero is removed, but it is replaced by a space. The result is a date string such as the following (yyyy.m.d) : Second, I would like to suggest is that the leading zeros on %m (two-digit month number) should also be removed. If you are deleting zeros from the day numbers, you certainly want to delete zeros from the month numbers. With these two additional fixes, the above date becomes ... ... which is much more the sort of thing a real person would write it. This fix worked perfectly for me as well. My specifics:
Moodle version 1.9+, build 20080331 Added, a screenshot, to show that it can get even worse (before the fix), the reason why i am so happy with this fix. My site is in chinese (Shenyang, not Hongkong... 1/ the static $localewin = null; will not work in cron, each user may have different locale
2/ I do not think we should be doing this in all locales 3/ I do not understand why you need new localewincharsetdaymonth > 1/ the static $localewin = null; will not work in cron,
> each user may have different locale Ah yes, good point. We probably have to set it up for each call to userdate() then > 2/ I do not think we should be How else could we do it? > 3/ I do not understand why you need localewincharsetdaymonth is necessary because localewincharset influences the entire date string, but on servers suffering from this "garbeled dates" issue, only parts of the date string need special treatment. Also, localewincharset has been around for some time and I presume it is working well for some people. If we tried to change the way it works, then there is a great risk of breaking dates on systems where localewincharset is sufficient. I can give you access to my windows server to investigate if that would be helpful. Revised the userdate() function in the attached file, userdate.txt, so that it maintains a cache of strings used for each language pack.
This allows the function to be efficient both when being called by a single user with a single language pack, and when being called by multiple users with possibly multiple language packs, for example while the Moodle cron.php is being run. In working with the MRBS block, I've been attempting to move the language stuff from the MRBS way of doing things to a more Moodle-like way. I came across an issue with strftime using the %p under certain locales. I initially thought I would just use userdate to replace it and handle it; however, it appears that userdate does not handle the %p format correctly. I'm attaching the language.php file from MRBS that has a function utf8_strftime that checks to see if in fact the locale returns the proper am/pm. If not, it adds it in. This seems related to the issue here. What I plan to do for the MRBS block is to use userdate and hope that the userdate function gets patched up so that it works nicely with the %p format in all languages. I'm also attaching a couple of screen shots of the MRBS block. One in English and one in Spanish which are using the userdate function with the format of %I:%M%p. I'm not 100% sure what is happening with the locales. I'll try to take a closer look at the userdate function to explain the differences in behavior. For example, I notice in viewing the Moodle logs in English I get am and pm displayed; however, in Spanish it converts to a 24 hour format. Curiously in MRBS block using the same function I am getting different behavior with just the am/pm being dropped in Spanish. Bottom line, I'm still trying to make sense out of what is happening but thought sharing this mess might help somewhat this issue. Peace - Anthony
– from the MRBS changelog:
Here is a patch file that I did some testing with using the format '%I:%M%p' which should return am/pm. In English, the am/pm show just fine; however, in other locales such as Spanish (es_utf8) it does not show up. I pulled in the fix that was used in the MRBS project (as shown in the language.php already attached) and incorporated the additional check into Moodle's userdate function (in /lib/moodlelib.php) and it seems to work. The logic seems pretty simple. I'm hoping that perhaps the patch will also help to partially resolve the issue that Gordon reported.
To ensure that was not some strange MRBS thing, I tested using the '%I:%M%p' format in the /course/report/log/live.php file and received similar results (i.e. the am/pm showed in English but not in Spanish). With this patch it shows for English and Spanish. In the MRBS block, I'm going to replace all the strftime functions with Moodle's userdate so it would help if this or a similar patch were introduced to provide for the proper formating of the time. I suspect that its a PHP issue with the strftime function although I did not find it documented as being problematic elsewhere. I'll do some continued testing and if needed file an issue with php.net. Also, for the record I am using PHP Version 5.2.4 and tested using Ubuntu, FF3. Peace - Anthony I found that disabling the following if statement of the userdate() function in moodlelib.php makes Japanese dates show correctly, without any further modifications. So I suppose the error lies with the $textlib->convert() function.
/// If we are running under Windows convert from windows encoding to UTF-8 if ($CFG->ostype == 'WINDOWS') { Hope that helps solving this issue. Regards, The $textlib->convert() function of \lib\textlib.class.php (line 111) is basically only a wrapper for the Typo3 conv() function which does all the work. It is found in \lib\typo3\class.t3lib_cs.php (line 590).
I did some more poking around.
The culprit seems to be PHP's inconv() function used in class.t3lib_cs.php (line 611). When using the following test script, I get the same mangled output as in Moodle. <?php Output of script: 2009??01? Using EUC-JP encoding instead of Shift-JIS results in this output: 2009? <?php Hopefully, a further step to a solution. Frank Thanks Frank for poking and reporting what you found. I am just returning from Nepal but it sounds like your comments may help us work toward a solution. Peace - Anthony
I did some thinking after the poking and might have jumped to a conclusion.
After all, my test script (the PHP file) itself isn't encoded in Shift JIS but in UTF-8. So I am feeding the inconv() function a UTF-8 string while telling it it is Shift JIS encoded. That causes the wrong output. So there seems to be some implicit converting to UTF-8 going on further upstream and the inconv() function is innocent after all. Frank http://moodle.org/mod/forum/discuss.php?d=118294
 might provide some related information (Problems with date display on Windows machine with non English locale)
Frank |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bug
Open
Minor
day names, month names and am/pm appear garbled in Chinese and Japanese on Windows servers
), simplified chinese
20?52?"); |
|
