! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
weekdays in Russian are displayed ugly in forecast tab


Description Sergey Fedoseev 2008-01-25 17:06:27 CET
Weekdays (Sunday and Monday) in Russian are displayed ugly in forecast tab. Sometimes they're cut, sometimes they aren't displayed at all.

In .xsessions-errors I get this:
(xfce4-weather-plugin:11535): Gtk-WARNING **: Failed to set text from markup due to error parsing markup: Error on line 1 char 12: Invalid UTF-8 encoded text - not valid '<b>\xa8\xe3n\u0008</b>'

(xfce4-weather-plugin:11535): Gtk-WARNING **: Failed to set text from markup due to error parsing markup: Error on line 1 char 12: Invalid UTF-8 encoded text - not valid '<b>\xd0{m\u0008</b>'

I believe this happens because of insufficient buffer variable size. In Russian both words Sunday and Monday have 11 characters. In UTF-8 Cyrillic symbol occupies two bytes.
Comment 1 Yves-Alexis Perez editbugs 2008-06-10 22:26:52 CEST
I guess this is because weather plugin uses strftime directly, using LC_CTIME, while gtk/glib expects pure UTF-8.

Datetime plugin seems to have a utf8strftime which may be usable in weather plugin too.
Comment 2 Yves-Alexis Perez editbugs 2008-06-10 23:29:52 CEST
Created attachment 1679 
Use UTF8 for time conversion

Attached patch seems to fix the problem at least wrt. debian bug #483952
Comment 3 Sergey Otinov 2008-06-11 23:32:48 CEST
Created attachment 1680 
Another one patch
Comment 4 Sergey Otinov 2008-06-11 23:42:25 CEST
On my box (gentoo with unicode locale) first patch seems a little bit useless because strftime returns utf8 string witch doesn't fit into buffer DAY_LOC_N length. So, the only thing that I did - just increase size of day_loc buffer. Works fine for me.
Comment 5 Yves-Alexis Perez editbugs 2009-03-10 06:40:11 CET
Well, the problem is not really with UTF-8 locales (except, maybe, the string size, but it's *another* problem). It's just that gtk expects an UTF-8 strings so it needs to be encoded as UTF-8 if you're using ISO. If you're already in UTF8 no problem with the current code, and the patch would be a no-op.
Comment 6 Sergey Fedoseev 2009-03-10 14:12:58 CET
I get this bug with ru_RU.UTF-8 locale.

About 'strftime' function from http://www.gnu.org/software/libtool/manual/libc/Formatting-Calendar-Time.html

Function: size_t strftime (char *s, size_t size, const char *template, const struct tm *brokentime)
The size parameter can be used to specify the maximum number of characters to be stored in the array s, including the terminating null character. If the formatted time requires more than size characters, strftime returns zero and the _contents of the array s are undefined_. Otherwise the return value indicates the number of characters placed in the array s, not including the terminating null character.

In general case 'undefined' != 'UTF-8 encoded string' =). So I guess string
size is *this* problem.
Comment 7 Yves-Alexis Perez editbugs 2009-03-10 14:17:11 CET
Oh, sorry. So your problem (and this bug then :) ) is not related to “mine” which is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483952 and is fixed by the attached patch.

Sorry for hi-jacking your bug :)
Comment 8 Sergey Fedoseev 2009-03-10 14:30:44 CET
I'm debian user... Will you fix *mine* bug in debian? ;)
Comment 9 Yves-Alexis Perez editbugs 2009-03-10 14:54:26 CET
That should be possible :)

(but it'd be nice to have upstream comment on both issues+patches anyway)
Comment 10 Jannis Pohlmann editbugs 2009-06-12 13:21:43 CEST
Re-assigning to Colin Leroy who is the new maintainer of the plugin.
Comment 11 Colin Leroy 2009-06-13 07:42:32 CEST
This should be fixed (both bugs discussed here) in SVN r7545.

Bug #3818

Reported by:
Sergey Fedoseev
Reported on: 2008-01-25
Last modified on: 2014-12-07


Colin Leroy
CC List:
4 users


0.7.3 or older


Use UTF8 for time conversion (2.03 KB, patch)
2008-06-10 23:29 CEST , Yves-Alexis Perez
no flags
Another one patch (317 bytes, text/plain)
2008-06-11 23:32 CEST , Sergey Otinov
no flags

Additional information