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 101420 - rhythmbox msgid includes non-ASCII character
rhythmbox msgid includes non-ASCII character
Status: VERIFIED FIXED
Product: rhythmbox
Classification: Other
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
Depends on: 99005
Blocks:
 
 
Reported: 2002-12-17 08:03 UTC by Christian Rose
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Christian Rose 2002-12-17 08:03:08 UTC 
The file shell/rb.c contains a non-ascii character that
causes many warnings from xgettext when I update the sv.po (which is in
UTF-8) with "intltool-update sv":

xgettext: warning: The following msgid contains non-ASCII characters.
                   This will cause problems to translators who use a
                   character encoding different from yours. Consider
                   using a pure ASCII msgid instead.
                   Copyright © 2002 Jorn Baayen. All rights reserved.
xgettext: invalid multibyte sequence
xgettext: invalid multibyte sequence
xgettext: invalid multibyte sequence
xgettext: invalid multibyte sequence

Also, the character (©) will not be displayed in the msgid in the po file,
it will simply be an extra space. Thus, this message cannot be translated
correctly as it is.
Comment 1 Christian Rose 2002-12-17 08:04:52 UTC 
I'll mark it dependant on bug 99005 in the mean time, but I really
doubt intltool can do much about this. Either rhythmbox or gettext
needs to be fixed.
Comment 2 Abel Cheung 2003-07-14 09:18:51 UTC 
is this bug still valid? I just had a checkout and found no error. My
guess is that this problem is already fixed in source.
Comment 3 Christian Rose 2003-07-14 09:57:28 UTC 
Seems this has been fixed, yes.