GNOME Bugzilla – Bug 377298
dogtail is not localized
Last modified: 2011-02-07 06:07:56 UTC
dogtail is not localized. To reproduce: 1. Invoke dogtail-recorder Then the notification dialog "Dogtail requires that Assistive Technology Support be enabled for it to function...." is not localized. To reproduce: 1. Invoke sniff. Then "Name", "_View" "_Help", "Name:", "Role Name:" are not localized. I'm attaching the patch.
Created attachment 76895 [details] [review] Patch for Makefile, configure.in, dogtail/config.py, dogtail/utils.py, recorder/Makefile.am, recorder/dogtail-recorder, recorder/dogtail-recorder.desktop.in ... The patch fixes: - Assign /usr/share/locale instead of Solaris default dir /usr/lib/locale - import gnome.ui to override init() to load libgnomeui.mo - Added *.desktop.in to be localized. - Added configure.in to update .pot file I cannot find configure.in, Makefile.am from CVS so also added Makefile.
Thanks for the patch! I forward-ported it to CVS HEAD, but I can't get it to build. I don't know much about autotools, but I think we need a configure.in.
Created attachment 76990 [details] [review] patch forward-ported to CVS HEAD This should be the same patch as the previous, but forward-ported to CVS HEAD.
Thanks for your work. dogtail.spec may need to be updated. --- dogtail.spec.orig 2006-11-22 10:13:28.934787000 +0900 +++ dogtail.spec 2006-11-22 10:14:17.654571000 +0900 @@ -26,6 +26,7 @@ communicate with desktop applications. %setup -q %build +intltoolize -c -f --automake python ./setup.py build %install Could you integrate the patch?
Integrating the patch, even if I add the intltoolize line, causes dogtail to fail to build. Have you tried it?
Yes, I could succeed the build on Solaris. What kind of build errors did you get? The build is: intltoolize -f -c --automake make python setup.py install --prefix=$RPM_BUILD_ROOT%{_prefix} cd po make DESTDIR=$RPM_BUILD_ROOT install cd .. The Makefiles are generated by Makefile.am/configure.in so it may be different between platforms but dogtail does not have configure.in so I copied platform-depended Makefiles from other components. Ah, sorry, po/Makefile includes Sun specific path: +INSTALL = /jds/cbe/bin/install -c +mkdir_p = /jds/cbe/bin/install -d -m 755 -o root -g other
Created attachment 77050 [details] po/ja.po I'm attaching ja.po for the test purpose. The .pot file can be generated: # cd dogtail/po # touch POTFILES.in # intltool-update -m # cat POTFILES.in missing | sort >> POTFILES.in # intltool-update -p # ls *.pot
Created attachment 88150 [details] [review] Revised patch from #76895 and #76990 I revised the patches to be worked on linux. Please review this patch.
Could you review the latest patch whether you fail to build dogtail or not?
First, the build failed because libtool isn't installed and not in the BuildRequires. So I added it and installed libtool. Now it fails, showing: libtoolize: `configure.ac' does not exist
Sorry, I thought you have libool. > libtoolize: `configure.ac' does not exist libtoolize is a script and the message is called from the following lines: =============================== if test -f configure.ac; then configure_ac=configure.ac elif test -f configure.in; then configure_ac=configure.in else echo "$progname: \`configure.ac' does not exist" 1>&2 echo "$help" 1>&2 exit 1 fi =============================== My latest patch includes the configure.in below. --- dogtail-0.6.1/configure.in.orig 1970-01-01 09:00:00.000000000 +0900 +++ dogtail-0.6.1/configure.in 2007-05-14 10:14:27.292660000 +0900 Could you please check if the configure.in is generated with my patch? It means the Source0 is applied my patch in the dogtail.spec. Source0: http://people.redhat.com/zcerza/dogtail/releases/dogtail-%{version}.tar .gz Thanks, fujiwara
I'm not sure how I'm supposed to get this to build. I'm using an svn working copy. How exactly are you doing it?
Created attachment 92581 [details] [review] Revised patch from #88150 OK, I updated the BuildRequire lines. The following is the instruction: # svn co http://svn.gnome.org/svn/dogtail/trunk dogtail # cd dogtail # patch -p1 < /packages/patch/dogtail-xx-i18n-ui.diff # cd .. # mv dogtail dogtail-0.6.2 # tar cfvz dogtail-0.6.2.tar.gz dogtail-0.6.2 # mv dogtail-0.6.2.tar.gz /usr/src/redhat/SOURCES/. # rpmbuild -bb dogtail-0.6.2/dogtail.spec Could you try this?
Could you try the latest patch? I think you can check the fix.
So, your patch doesn't work, needs glib2-devel as BuildRequire. I think bringing in autotools just to get localization is a bit pointless. I have a patch (including dogtail.pot) with which we don't need autotools. All that is needed is the msgfmt program to generate .mo files from .po; i used this one: http://svn.python.org/projects/python/trunk/Tools/i18n/msgfmt.py i haven't changed the .spec file yet, though.
Created attachment 99671 [details] [review] localization patch for dogtail includes the translation for a lot of strings & dogtail.pot; also some strings from sniff.
Created attachment 99672 [details] Slovak language file for dogtail (only about 10% translated, for testing only)
So, to test this out: svn co dogtail/trunk, apply patch create a dogtail.mo from slovak.po (or any .po): # msgfmt -o dogtail.mo slovak.po then, move it into the right locale dir, e.g. "/usr/share/locale/sk/LC_MESSAGES/" then run export 'PYTHONPATH=/my/localized/dogtail', run "LANG=sk_SK.UTF-8 python", and do "from dogtail import tree", you should see localized messages for "creating log file...". to try out sniff: "LANGUAGE=sk_SK.UTF-8 sniff"
Yep, works for me. Thanks for the patch. Now to get it worked into the build system. I'll start looking. Sidenote: This will be a horrific patch to merge into the pyatspi branch :)
> your patch doesn't work, needs glib2-devel as BuildRequire. That is not for this issue since dogtail has already used glib2. > attachment (id=99671) [edit] It breaks many i18n issues. > that is needed is the msgfmt program to generate .mo files from .po; i used It's not this problem. Actually we need Makefile to build .po files and we use intltoolize and should work with any msgfmt commands. We need to use Solaris msgfmt in Solaris. Note we also need to i18n of .desktop files and most of the translators use intltool to get .pot files. Anyway I'll put the correct patch.
(In reply to comment #20) > > your patch doesn't work, needs glib2-devel as BuildRequire. > That is not for this issue since dogtail has already used glib2. > glib2 does not include files from glib2-devel. It is an issue, at least on RHEL5, where it fails with some AM_ macro undefined. Even after installing glib2-devel, it fails to rpmbuild because in %install it tries to install to / root, not RPM_BUILD_ROOT. Have you tried it in some linux ? > > attachment (id=99671) [edit] > > It breaks many i18n issues. Could you be more specific ? > > > that is needed is the msgfmt program to generate .mo files from .po; i used > > It's not this problem. Actually we need Makefile to build .po files and we use > intltoolize and should work with any msgfmt commands. We need to use Solaris > msgfmt in Solaris. > Note we also need to i18n of .desktop files and most of the translators use > intltool to get .pot files. Yes, you're correct, msgfmt should be used the one present in the system, and dogtail already contains BuildReq gettext, so that's fine. Let's forget the msgfmt.py. I know about intltool and .desktop file, yes intltool is nice - i tried it on .glade for sniff, it works fine. But - afaik it has zero support for python, just as the whole autotools and gettext. How can i expect xgettext to get .pot files when it doesn't recognize python syntax ? Aside from this, i would like much more to use python's facilities (gettext, distutils) than intltool/automake for a *python* project. Unfortunately python's support for i18n isn't all-star either. > > Anyway I'll put the correct patch. > I'll take a look. Thanks ! :)
Created attachment 99833 [details] [review] Revised patch from #92581 and #99671 OK, I updated patch. Please review the patch. > glib2 does not include files from glib2-devel. Do you mean dogtail does not use glib2-devel if my patch is not applied? I applied it at the moment but actually I have been thinking the patch will be applied when the maitainer resolves the build issue. > where it fails with some AM_ macro undefined. Which macro is not defined? it maybe automake/autoconf is old. > not RPM_BUILD_ROOT. Does your .spec file has "BuildRoot: " in the header? /usr/lib/rpm/macros: # Configurable build root path, same as BuildRoot: in a specfile. # (Note: the configured macro value will override the spec file value). # #%buildroot > Have you tried it in some linux ? Yes, the patch works fine with RHEL4 and Fedora 7. > Could you be more specific ? - gettext.install does not work GUI translation. - bindtextdomain needs to set the locale dir. - Some of .py loose '_' macro. It causes execution errors. - The single quotation does not work with intltool which is used by many translators. - gnome.ui needs to be loaded. > just as the whole autotools and gettext. How can i expect xgettext to get .pot files when it doesn't recognize python syntax ? Yes, I put the sniff and dogtail-recorder is saved in POTFILES.in at the moment however I think that finally we need to renamed sniff to sniff.py in the source files so that intltool-update can detect the file. > Unfortunately python's support for i18n isn't all-star either. I think when the python official package is available, the option is considered. At the moment, none python intltool is available and it's used by several python applications, gnome-menus, orca and etc.
(In reply to comment #22) > OK, I updated patch. Please review the patch. I'm looking at it now. > Do you mean dogtail does not use glib2-devel if my patch is not applied? > I applied it at the moment but actually I have been thinking the patch will be > applied when the maitainer resolves the build issue. > > > where it fails with some AM_ macro undefined. > > Which macro is not defined? it maybe automake/autoconf is old. No, auto* is fine. This is how it fails: + aclocal aclocal:configure.in:14: warning: macro `AM_GLIB_GNU_GETTEXT' not found in library + autoconf configure.in:14: error: possibly undefined macro: AM_GLIB_GNU_GETTEXT If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. error: Bad exit status from /var/tmp/rpm-tmp.44707 (%build) And that's because AM_GLIB_GNU_GETTEXT is defined in this file: /usr/share/aclocal/glib-gettext.m4 which belongs to glib2-devel. > > > not RPM_BUILD_ROOT. > > Does your .spec file has "BuildRoot: " in the header? I used the specfile you provided in your previous patch. This is not the issue; see my next answer. > > > Have you tried it in some linux ? > > Yes, the patch works fine with RHEL4 and Fedora 7. Let me guess - you're running rpmbuild as root. That's why it works for you and fails for me. It's a bad practice - if you had a screwed specfile, it could screw up your system. In this case, it merely overwrites system's dogtail. When i run rpmbuild: rpmbuild runs %install: + make DESTDIR=/var/tmp/dogtail-0.6.2-2-root-mike install list='po recorder sniff'; for subdir in $list; do \ (cd $subdir && make DESTDIR=/var/tmp/dogtail-0.6.2-2-root-mike install) \ done; \ python setup.py install ^^^^^^^^^^^^ this is the problem ... right after make, it runs "python setup.py install": running install running build running build_py running build_scripts running install_lib copying build/lib/dogtail/path.py -> /usr/lib/python2.4/site-packages/dogtail error: could not delete '/usr/lib/python2.4/site-packages/dogtail/path.py': Permission denied make: *** [install] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.71489 (%install) It tries to overwrite my system's dogtail, and it fails since i'm not root. So, the problem is in dogtail's Makefile. I fixed it; see my next patch. > > > Could you be more specific ? > - gettext.install does not work GUI translation. Uh, sorry, i don't understand. What doesn't work ? > - bindtextdomain needs to set the locale dir. > - Some of .py loose '_' macro. It causes execution errors. > - The single quotation does not work with intltool which is used by many > translators. > - gnome.ui needs to be loaded. > > Yes, I put the sniff and dogtail-recorder is saved in POTFILES.in at the moment > however I think that finally we need to renamed sniff to sniff.py in the source > files so that intltool-update can detect the file. No, i think you miss my point. > > > Unfortunately python's support for i18n isn't all-star either. > I think when the python official package is available, the option is > considered. At the moment, none python intltool is available and it's used by > several python applications, gnome-menus, orca and etc. Good news:
Update: > - bindtextdomain needs to set the locale dir. i didn't use bindtextdomain, sorry, i didn't find any need to provide a path to locales, the system default path works fine. Now i see Solaris has a different locale path, so yes it needs some fixing. > - Some of .py loose '_' macro. It causes execution errors. Yeah, that needs correction. _() is created by calling gettext.install(), so before that call it's not available. So far i put it into tree.py and sniff only. > - The single quotation does not work with intltool which is used by many > translators. See my note below. > - gnome.ui needs to be loaded. I don't understand this one, sorry. > Yes, I put the sniff and dogtail-recorder is saved in POTFILES.in at the moment > however I think that finally we need to renamed sniff to sniff.py in the source > files so that intltool-update can detect the file. Note: Renaming sniff to sniff.py won't help at all, intltool-update uses gettext on all files it can't parse itself - including python. Not only gettext doesn't understand python's single quotation, even if it's valid. An example: change the quit() function in sniff to: def quit(*args): """ haluska print _("asdfsadfsdfgdf") """ gtk.main_quit() and run intltool-update. It's going to create: #: ../sniff/sniff:59 msgid "asdfsadfsdfgdf" msgstr "" because it doesn't understand python comments (and who knows what else). > > > Unfortunately python's support for i18n isn't all-star either. > I think when the python official package is available, the option is > considered. At the moment, none python intltool is available and it's used by > several python applications, gnome-menus, orca and etc. I found that pygettext.py (python's xgettext, http://svn.python.org/projects/python/trunk/Tools/i18n/pygettext.py) is packaged for Fedora already in a package named "python-tools". Yeah that's true intltool is not there, unfortunately. But then the only reason i see for using intltool is sniff.glade.
(In reply to comment #24) > > - Some of .py loose '_' macro. It causes execution errors. > Yeah, that needs correction. _() is created by calling gettext.install(), so > before that call it's not available. So far i put it into tree.py and sniff > only. Why not put it in __init__.py ?
Created attachment 99898 [details] [review] Revised patch from #99833 > No, auto* is fine. This is how it fails: > + aclocal > aclocal:configure.in:14: warning: macro `AM_GLIB_GNU_GETTEXT' not found in library > + autoconf OK, it makes sense. Actually we need AM_GLIB_GNU_GETTEXT on Solaris. I provided the automake method to generate the Makefile not to depend on the platform because the maitainer didn't succeed to build my patch and my first patch didn't use automake. Now I think you can build my patch and understand it so I reverted the method not to use automake again. It's the same reason to provide the patch of .spec to understand my patch. Actually many distributers don't use the bundled .spec file and I don't mind you customize the build. e.g. # make MSGFMT=your_msgfmt This can override the definition. But I need to provide patch to build .mo files and i18n .desktop in dogtail. > It tries to overwrite my system's dogtail, and it fails since i'm not root. So, the problem is in dogtail's Makefile. I fixed it; see my next patch. I fixed it. See my patch. > An example: > change the quit() function in sniff to: I don't think this is a actual problem to fix the dogtail i18n code. Many translators use intltool to get the latest POTFILE.in and .pot file for GNOME applications. So I think it makes sense to provide the framework with intltool so that translators get all untranslated strings by themselves. > I found that pygettext.py (python's xgettext, Is it related with the discussion of the i18n code? Translators can select any xgettext tools but I think they should get all untranslated strings with any xgettext tools through all applications. Could you review the attached patch? Thanks.
Takao, It looks like since you're hardcoding GNOMELOCALEDIR, things will break if e.g. running from the source tree. Does gtk.glade.bindtextdomain('dogtail') really fail on solaris, and if so, can we only hardcode the path if it isn't found automatically? Also, I'm concerned about how hard this will be to merge with the pyatspi branch once it's ready... work on that branch is being hindered by bug #465103, though. I've been working on a python distutils command that so far can generate dogtail.pot and compile/install any .po files it finds in po/. That means the work is done by setup.py (Fedora and RHEL don't even use the Makefile, they just run setup.py). If I can get it to do the rest, I think I might prefer to use that rather than lots of Makefile glue code, since my distutils command is meant to be a somewhat drop-in replacement. And who knows, maybe get it into upstream python to benefit others.
Zack, > fail on solaris, and if so, can we only hardcode the path if it isn't found automatically? Normally we prepare .py.in files and configure.in and generate .py file from the result of configure. Can you generate .py file with setup.py? > Also, I'm concerned about how hard this will be to merge with the pyatspi Has the dogtail with pyatspi branch already worked without crashes? If so, I can generate the patch. > I've been working on a python distutils command that so far can generate dogtail.pot and compile/install any .po files it finds in po/. In intltool, - 'intltool -m' generates $module/po/POTFILES.in file. - 'intltool -p' generates $module/po/$module.pot files. - $module/po/Makefile loads $module/po/LINGUAS file. Translators will update LINGUAS file and .po files. Also if you don't Makefile, you need to prepare the logic to generate localized .desktop files from .desktop.in files. 'intltool -m' also detects the .desktop.in files. If all files are properly i18ned and all translatable strings can be exracted by translators, I have no concerns.
dogtail development has been stalled and it has been unmaintained for a few years now. Maintainers don't have future development plan so i am closing bugs as WONTFIX. Please feel free to reopen the bugs in future if anyone takes the responsibility for active development.