Still rollin

Huh boy, I noticed the last post is old more than a month ago; the time is passing for me recently much faster than usually.

Probably the main reason for this is my new job, and some time I need to get used to new environment, people, workflow and the rest of the package that comes with it. As consequence, I had to shutdown (hopefully only temporarily) build farm, as build computers were hosted in facility owned my previous employee.

Other than that, I finally installed 64-bit Slackware 13, which I planned to do for some time. Maybe the main reason for this was to see how EDE will work on pure 64-bit platform; personally, 32-bit, 64-bit, they are all the same for me, except additional burden to learn assembler for different architecture (it is always good to know some asm when you do gdb beyond dumping simple backtrace).

Unexpectedly (duh!), I found problems in EDE code, both compiling and working. Compiling errors were mostly caused by newer gcc (due stdarg changes in glibc) and (as usually) PIC flag(s) for library creation.

Working errors were caused by some pointer magic (as expected) and my wrong assumption how WM property data is stored as CARD32 type. Other than this, I didn't find other 64bit specific issues, although this statement should be taken with some caution :)

Also, I added application icon support in ede-panel, as shown in the screenshot below.


This was (and still is) a quick hack and will be in some future stored in edelib, so the code can be used, for example, to show application icon in tooltip or pager.

Clock applet got some tiny refreshing with flat box and tooltip showing current date, like:


AFAIK this behavior is copied by others, so why EDE should be exception ;) Joke aside, this is pretty useful thing; for example I often forget current date and do not want to start ede-datetime just to check what day or weekday today is.

Translations and locale #2

Did you know that there is no generic tool to extract translation strings from non source files (anything else not related to some programming language, like .desktop files)? Neither did I, until I tried to find one.

Yes, I know about Intltool, but it is too much tied to Automake that makes it pretty cumbersome outside of it. In README, there is short how-to about Intltool usage outside autotools, but the solution simply cries for something better.

Now, taking into account how Intltool is mostly used by default from autotool users, I checked what autotool non-users has to say about this problem, primarly focusing on KDE, as they are using CMake.

Yes, they have solution and is not intltool, but after seeing it, intltool seems to me as the best choice I can get. Besides a full python framework dedicated to this problem, they have a help from cron script that nightly (or at some part of day or week) walks over repository merging and updating translations in .desktop files and presumably, documentation and other like files.

100 heads are smarter than one, but why this (their) solution looks to me pretty cumbersome? I mean, why someone couldn't made something that rest of the world can use, no matter are utilized make, cmake, scons or jam? Clearly, translation problem is not simple as it looks like.

The clear example was/is bad state about general translation are tools we had before. Not counting GUI frontends (like KBabel) which are mostly copies in different toolkits, solutions in form of web frontends (or for God sake anything else smarter than just calling xgettext in background) we only had in form of Pootle project, famous for it's slowness and memory usage.

Now you know why I see (and presumably others) Transifex project as gift from gods. Count to that free service they put on transifex.net for your project and we, users and developers, could not be happier.

But Transifex is still frontend... if we are going to find the root of this problem, maybe we should start from gettext tools. Hell, even xgettext (part of gettext chain) has differences between GNU and OpenSolaris version (presumably the same is for other Solaris-es). Sun version of xgettext is so dumb you can't even specify extraction keyword, so you must use 'gettext' instead e.g. '_' tag we are used to.

On other hand, GNU xgettext is no perfect either: it tries to be smart where it should be dumb. GNU xgettext can recognize programming language of source it scans and can extract translation strings in the way is best in that language. But, sometimes you want different things.

Recently I tried to add translation feature to theming engine in edelib, which includes some Scheme code, inspired with translation tags found in GIMP. Basically I wanted it looks like this:

 (display _"This text will be translated")

but GNU people visualized how things should be in more lispy like:

 (display (_ "This text will be translated"))

so there is no way you can force xgettext to see the first example as valid scheme source code without hackery with sed and shell.

Count to that how Intltool (which uses xgettext) does the same job as xgettext (extract strings from source code), but in own specific way, you simply lose any desire to do anything related to translation in your project.

Translations and locale

Aside from my busyness with daily job (and messing with ede-scriptbus to make something usable from it), there happened some changes in edelib too. Thanks to Thierry, locale bug and some installation issues in edelib are fixed now.

That was also a perfect time to finally do something about translation stuff in edelib and complete build scripts to install translated files.

I also created EDE related page on Transifex; for now online translation is not possible yet as I have to finalize and adapt translation facility in ede module. Facility exists, but I want to keep it in similar manner as in edelib (have po folders instead locale and store translation template in file named as application, instead messages.pot).