After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 643350 - Broken UTF-8 encoding in the calendar heading
Broken UTF-8 encoding in the calendar heading
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
2.91.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 644405 (view as bug list)
Depends on: 644607
Blocks:
 
 
Reported: 2011-02-26 08:24 UTC by Changwoo Ryu
Modified: 2011-03-14 19:34 UTC
See Also:
GNOME target: 3.0
GNOME version: ---


Attachments
calendar screenshot (59.48 KB, image/png)
2011-02-26 08:24 UTC, Changwoo Ryu
  Details
Work around Spidermonkey problem with Unicode date formats (3.17 KB, patch)
2011-03-13 02:00 UTC, Owen Taylor
committed Details | Review

Description Changwoo Ryu 2011-02-26 08:24:20 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$
Comment 1 Changwoo Ryu 2011-03-05 18:51:40 UTC
More information:

'년' is U+B144, and 'D' is U+0044. '일' is U+C77C, and 'D' is U+007C.

High bits are stripped off.
Comment 2 kikidong 2011-03-11 04:52:12 UTC
I think the problem is that, translators should only adjust the order of %A, %B %d, %Y, not actually translate it.
Comment 3 Changwoo Ryu 2011-03-11 07:44:07 UTC
(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.
Comment 4 Owen Taylor 2011-03-13 01:59:22 UTC
*** Bug 644405 has been marked as a duplicate of this bug. ***
Comment 5 Owen Taylor 2011-03-13 02:00:15 UTC
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.
Comment 6 Owen Taylor 2011-03-13 02:01:58 UTC
GLib bug fix is needed to make g_date_time_format() actually localize properly.
Comment 7 David Zeuthen (not reading bugmail) 2011-03-14 18:43:47 UTC
(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 8 Dan Winship 2011-03-14 19:19:07 UTC
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 (
Comment 9 Owen Taylor 2011-03-14 19:34:50 UTC
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