GNOME Bugzilla – Bug 643350
Broken UTF-8 encoding in the calendar heading
Last modified: 2011-03-14 19:34:53 UTC
Created attachment 181968 [details] calendar screenshot With Korean translation, the calendar heading displays "2011D 2월 26| 토요일", which should be "2011년 2월 26일 토요일". Something seems to break UTF-8 encoded string in the translated date formats. For information, the Korean date format translations usually contain extra suffices after %Y and %e, like this in gnome-shell/po/ko.po: #: ../js/ui/calendar.js:720 msgctxt "calendar heading" msgid "%A, %B %d, %Y" msgstr "%Y년 %B %d일 %A" I investigated a bit like the following, but I have no idea what the argument type of toLocaleFormat() should be: duncan:~/gnome$ cat test.js const Gettext = imports.gettext.domain('gnome-shell'); const _ = Gettext.gettext; const C_ = Gettext.pgettext; print(C_("calendar heading", "%A, %B %d, %Y")); print((new Date()).toLocaleFormat("%Y년 %B %d일 %A")); print((new Date()).toLocaleFormat(C_("calendar heading", "%A, %B %d, %Y"))); duncan:~/gnome$ gjs test.js ** (gjs:20322): DEBUG: Command line: gjs test.js ** (gjs:20322): DEBUG: Creating new context to eval console script %Y년 %B %d일 %A 2011년 2월 26일 토요일 2011D 2월 26| 토요일 duncan:~/gnome$
More information: '년' is U+B144, and 'D' is U+0044. '일' is U+C77C, and 'D' is U+007C. High bits are stripped off.
I think the problem is that, translators should only adjust the order of %A, %B %d, %Y, not actually translate it.
(In reply to comment #2) > I think the problem is that, translators should only adjust the order of %A, %B > %d, %Y, not actually translate it. Your suggestion is just a workaround without fixing the real bug. Date formats have been translated in this way for years.
*** Bug 644405 has been marked as a duplicate of this bug. ***
Created attachment 183257 [details] [review] Work around Spidermonkey problem with Unicode date formats Monkey-patch Date.prototype.toLocaleFormat() with a version that uses g_date_time_format() since the Spidermonkey built-in can't handle format strings with Unicode characters.
GLib bug fix is needed to make g_date_time_format() actually localize properly.
(In reply to comment #5) > Created an attachment (id=183257) [details] [review] > Work around Spidermonkey problem with Unicode date formats > > Monkey-patch Date.prototype.toLocaleFormat() with a version that uses > g_date_time_format() since the Spidermonkey built-in can't handle > format strings with Unicode characters. JFTR, patch works fine - and with the bug-fix from bug 635840 (which is now on master), the shell clock now updates within a second when changing timezones if this patch is applied.
Comment on attachment 183257 [details] [review] Work around Spidermonkey problem with Unicode date formats seems sane >+ * Return value: the formatted date. If the date is >+ * outside of the range of a GDateTime (which contains >+ * any plausible , will return um? >+ datetime = g_date_time_new_from_timeval_local(&tv); space before (
Pushed with fixes. Corrupted sentence was meant to be: + * Return value: the formatted date. If the date is + * outside of the range of a GDateTime (which contains + * any plausible dates we actually care about), will + * return an empty string. Attachment 183257 [details] pushed as 7ad89dc - Work around Spidermonkey problem with Unicode date formats