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 320561 - unable to execute dogtail in CJK locale
unable to execute dogtail in CJK locale
Status: RESOLVED NOTABUG
Product: dogtail
Classification: Deprecated
Component: Framework
CVS HEAD
Other All
: Normal normal
: ---
Assigned To: Dogtail Maintainers
Dogtail Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-11-02 23:52 UTC by Lawrence Lim
Modified: 2005-11-21 21:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
screenshot of dogatil in es_ES after patch applied (156.40 KB, image/png)
2005-11-02 23:53 UTC, Lawrence Lim
  Details
screenshot of dogtail in zh_TW locale after patch applied (159.23 KB, image/png)
2005-11-02 23:54 UTC, Lawrence Lim
  Details
patch to use ugettext instead of dgettext (1.82 KB, patch)
2005-11-02 23:55 UTC, Lawrence Lim
needs-work Details | Review
sub menu is empty (133.47 KB, image/png)
2005-11-03 02:19 UTC, Lawrence Lim
  Details
sub menu ihas more options available (143.17 KB, image/png)
2005-11-03 02:20 UTC, Lawrence Lim
  Details

Description Lawrence Lim 2005-11-02 23:52:34 UTC
Please describe the problem:
Seems dogtail is unable to support chars outside ASCII range, as a result,
dogtail cannot be execute properly in CJK locale.

Steps to reproduce:
1. evolution --force-shutdown
2. LANG=zh_TW.UTF-8 evolution &
3. LANG=zh_TW.UTF-8 python evolution-test-switching-components.py


Actual results:
Traceback (most recent call last):
  • File "<string>", line 1 in ?
  • File "/usr/lib64/python2.4/gettext.py", line 517 in dgettext
    codeset=_localecodesets.get(domain))
  • File "/usr/lib64/python2.4/gettext.py", line 465 in translation
    t = _translations.setdefault(key, class_(open(mofile, 'rb')))
  • File "/usr/lib64/python2.4/gettext.py", line 177 in __init__
    self._parse(fp)
  • File "/usr/lib64/python2.4/gettext.py", line 324 in _parse
    tmsg = unicode(tmsg, self._charset)
LookupError: unknown encoding: CHARSET

Expected results:
See screenshots

Does this happen every time?
YES

Other information:
Created a patch to workaround the issue. Hope it helps.
Comment 1 Lawrence Lim 2005-11-02 23:53:57 UTC
Created attachment 54253 [details]
screenshot of dogatil in es_ES after patch applied
Comment 2 Lawrence Lim 2005-11-02 23:54:28 UTC
Created attachment 54255 [details]
screenshot of dogtail in zh_TW locale after patch applied
Comment 3 Lawrence Lim 2005-11-02 23:55:33 UTC
Created attachment 54256 [details] [review]
patch to use ugettext instead of dgettext

patch created with cvs diff against the trunk.
Comment 4 Dave Malcolm 2005-11-02 23:57:27 UTC
Sounds a lot like a problem we ran into with the translation files for the popt
package; in the end zack put in a specialcase to avoid "popt"

Is there a specific mo file that breaks things?
Comment 5 Zack Cerza 2005-11-03 00:32:39 UTC
Hmm, I can run evolution-test-switching-components.py under ja_JP.UTF-8 with no
problems. I haven't tried zh_TW yet, as I don't have support for it installed ATM.
Comment 6 Zack Cerza 2005-11-03 00:37:14 UTC
It looks like the patch breaks the test on my system, while it fixes it on yours. :(

Couldn't find: descendent of {"Window"
("\uffff\uffff\uffff\uffff\uffff\uffff\uffff\u0265\uffff(W)",
"\u30a6\u30a3\u30f3\u30c9\u30a6(W)") menu}: "Mail" ("\u30e1\u30fc\u30eb(M)")
menuitem
Comment 7 Lawrence Lim 2005-11-03 00:54:03 UTC
Comment #6, Are you still referring to evolution-test-switching-components.py test?
Comment 8 Zack Cerza 2005-11-03 01:03:39 UTC
Comment #7, yes I am
Comment 9 Dave Malcolm 2005-11-03 01:19:38 UTC
There are probably many differences between your systems.  What distribution is
each of you running on?  what versions of what packages?  what locale are you
starting the desktop session in?  etc etc
Comment 10 Lawrence Lim 2005-11-03 02:19:24 UTC
Comment #9,
I am using rawhide and default locale is zh_TW, however it is changed using
export depending on the locale to be tested. The reason why it is not working in
ja_JP locale is because it is not "humanly possible" to perform the switching
function in ja_JP. 

Please take a closer look at the screenshots for both evolution in both ja_JP
and zh_TW. In ja_JP locale, the options to switch is not available, whereas
zh_TW is. This is a bug in evolution. 
Comment 11 Lawrence Lim 2005-11-03 02:19:59 UTC
Created attachment 54258 [details]
sub menu is empty
Comment 12 Lawrence Lim 2005-11-03 02:20:34 UTC
Created attachment 54259 [details]
sub menu ihas more options available
Comment 13 Zack Cerza 2005-11-03 02:34:39 UTC
I should have explicitly said that the test worked *before* the patch, so the
menu items must be there.

I'm on Ubuntu Breezy with evolution 2.4.1. My desktop is en_US.UTF-8.
Comment 14 Dave Malcolm 2005-11-03 02:38:20 UTC
Re: comment 9-12, what does "rpm -q evolution" say?
Comment 15 Lawrence Lim 2005-11-03 04:08:07 UTC
Re: Comment #14

# rpm -q evolution
evolution-2.4.1-4
Comment 16 Zack Cerza 2005-11-08 17:00:55 UTC
I cannot reproduce the bug on FC4 with evolution-2.2.3-2.fc4 either.
Comment 17 Dave Malcolm 2005-11-08 17:12:17 UTC
Lawrence: re comment #10: please can you file the lack of the menu items as a
separate bug please (and give a link in this bug to it).  Thanks
Comment 18 Zack Cerza 2005-11-15 20:07:13 UTC
Is this actually a dogtail bug?
Comment 19 Lawrence Lim 2005-11-21 06:08:16 UTC
RE: Comment #17

Bug 322001 has been created.
<http://bugzilla.gnome.org/show_bug.cgi?id=322001>

RE: Comment #18

The missing menu in evolution cos the script to fail in ja_JP locale. All other
locales are ok.
Comment 20 Zack Cerza 2005-11-21 21:23:05 UTC
woohoo! resolving NOTABUG.