Issue Details (XML | Word | Printable)

Key: MDL-14149
Type: Bug Bug
Status: Open Open
Priority: Minor Minor
Assignee: Martin Dougiamas
Reporter: Gordon Bateson
Votes: 3
Watchers: 6
Operations

Add/Edit UI Mockup to this issue
If you were logged in you would be able to see more operations.
Moodle

day names, month names and am/pm appear garbled in Chinese and Japanese on Windows servers

Created: 02/Apr/08 08:13 PM   Updated: 08/Apr/09 07:53 PM
Return to search
Component/s: Languages, Unicode
Affects Version/s: 1.7.4, 1.8.4, 1.9
Fix Version/s: None

File Attachments: 1. File language.php (16 kB)
2. File MDL-14149-p.diff (0.8 kB)
3. Text File userdate.txt (5 kB)
4. Text File userdate.txt (5 kB)

Image Attachments:

1. dates.chinese.gif
(13 kB)

2. dates.english.gif
(6 kB)

3. dates.japanese.gif
(13 kB)

4. screenshot-1.jpg
(125 kB)

5. strftime_p_en.png
(134 kB)

6. strftime_p_es.png
(126 kB)
Environment:
Windows 2003 server (English OS and Japanese OS both exhibit same behavior)
Apache 2.2
PHP 5.2.4 (mbstring and iconv enabled with default settings)
database is not relevant
browser is not relevant
Issue Links:
Dependency
 

Database: Any
Participants: Anthony Borrow, Frank Ralf, Gao Han, Gordon Bateson, Martin Dougiamas and Petr Skoda
Security Level: None
Affected Branches: MOODLE_17_STABLE, MOODLE_18_STABLE, MOODLE_19_STABLE


 Description  « Hide
Dates in Japanese and Chinese appear garbled on Moodle sites running on a Windows server. By "garbled" I mean the date and the text around it on the page in the browser are morphed into irrelevant characters and question marks (see screenshot)

Apparently PHP's strftime() function used by Moodle's "userdate()" function (in lib/moodlelib.php") is where the text gets mangled.

In Japanese, date strings containing %A, %a, %B, %b, %p are consistently mangled by strftime().

In Chinese, dates strings ending in a multibyte character cause the mangling:
    $string['strftimedate'] = '%%Y?%%m?%%d?';
    $string['strftimedateshort'] = '%%m?%%d?';
    $string['strftimemonthyear'] = '%%Y?%%m?';

I experimented with many values for ...
    (1) the Moodle site locale (Language -> Language settings -> Sitewide locale)
    (2) the 'locale' string in the language pack
    (3) the 'localewin' string in the language pack
    (4) the 'localewincharset' string in the language pack

but I could not find values for the above settings to fix the multibyte dates.

In the end I modified the userdate() function to fix %A, %a, %B, %b, %p in a similar that %d is fixed. Firstly, replace with "AA", "aa", "BB", "bb", or "pp", then format the date, then replace "AA" with %A that has been correctly converted to utf8, "aa" with a% that has been converted to utf8, and so on.

As well as replacing the userdate function in moodlelib.php with the function in the attached file, "userdate.txt", it is also necessary to modify "get_string()" as follows:

    (1) locate the following line in the "get_string()" function (in "lib/moodlelib.php"):
                            'localewin', 'localewincharset', 'oldcharset',

    (2) replace the above line with the following line:
                            'localewin', 'localewincharset', 'localewincharsetdaymonth', 'oldcharset',

The fixing will only be triggered by the presence of a new string in the language pack: 'localewincharsetdaymonth'. This string needs to be added as an empty string in the English language pack and as a non-empty value in the relevant language packs on sites where the fixing is required.

During testing the last year on a live university Moode site in Japan, I have found that with the following language settings in the language pack and the modified userdate() and get_string() functions, the dates in Japanese display as requried:
    $string['localewincharset'] = '';
    $string['localewincharsetdaymonth'] = 'CP932';

Similarly, for Chinese dates, I use:
    $string['localewincharset'] = '';
    $string['localewincharsetdaymonth'] = 'CP936';

The same function and fix was recently confirmed for a Chinese site in Hong Kong:
    http://moodle.org/mod/forum/discuss.php?d=93697#p414588

many thanks
Gordon

 All   Comments   Change History   Version Control      Sort Order: Ascending order - Click to sort in descending order
No commits have yet been performed on this issue.