Monthly Archives: March 2008

Diary editor

The main window of the Diary.I've been keeping a personal diary for a while, but recently I've found that my previous storage method for it – keeping each day's entry in a separate file, stored in a folder hierarchy – was getting too unwieldy. That's why over the last few weeks I've written a small program to manage a diary.

I initially started writing it in Vala, but I found that I was having to put in dirty hacks every couple of tens of lines just to get the simplest things working with an SQLite database. Either due to my own lack of knowledge of Vala, or teething problems for the language and its bindings, I couldn't get it to work, so about a week ago I scrapped it and ported the program to old-fashioned C.

So here it is: version 0.1 of my diary program. It supports basic editing of diary entries, a calendar view of the month and the ability to add "links" to each entry. A "link" is something which connects the diary entry to the wider world, much like a hyperlink connects one web page to another. At the moment only "URI", "file" and "note" link types are supported, but in the future I plan for one to be able to link to anything from an F-Spot album to a section of a chat log in Empathy. Such links would allow references to conversations, e-mails, photo albums (etc.) in diary entries to be easily followed to find the goodies mentioned.

I also have plans to add Evolution calendar integration, as well as potential integration with Mugshot. It would be nice to see diary entries which can show all of what happened on that day, from doctor's appointments in Evolution to the songs Mugshot says you listened to.

Keeping my feet more grounded in reality, however, I think the next thing on the agenda is encryption for the database the diary uses, so your darkest secrets aren't so easily discovered.

To get it, you can either download the tarball or get the latest bzr tree from my website using the following command:

bzr branch http://tecnocode.co.uk/diary/

Thanks to people in the comments for pointing out a better way of branching.

The only requirements are gtk+-2.0 >= 2.12, sqlite3 and gtkspell-2.0, and it's built in the usual fashion.

Feedback is welcomed warmly and given somewhere to stay for the night.

Improving language strings

In the past few days I've been looking at using en_GB translations to detect mistakes in the original C-locale strings. I've hacked a version of en_GB.pl to automatically translate the C-locale strings using its database of Americanisms (or should that be "Americanizms"?) and then compare them to the module's current en_GB strings, which have likely been caressed into shape manually.

The results are quite useful. About half of the strings are currently flagged up due to missing translations in en_GB.pl itself, which I've noted down in bug #524049. The other half are a combination of bad en_GB translations, en_GB translations which rectify mistakes in the original string and en_GB translations which improve the original string grammatically or punctuationally.

Using this hacked en_GB.pl and a few shell scripts which aid in iterating through a directory full of all of GNOME 2.22's en_GB PO files it hasn't been hard to come up with logs of all the problems in each module, so I'll be spending some time going through and fixing all the broken en_GB translations and then bugs will get filed about the string problems in each module.

I wonder if this – or something like it – could get put into use on a l10n tinderbox machine? I've yet to talk to someone about merging my changes with the proper en_GB.pl, which is the first step, but if it's possible to use something like this for l10n quality control, I'd happily put time in to get it working.

Auto-generated class hierarchy diagrams

Unfortunately still working on that coursework, I've just added support in the API documentation makefile to automatically generate a class hierarchy diagram using the GObject hierarchy file created by gtk-doc and marshalling it to GraphViz. It basically analyses the depth of each line in the hierarchy file and creates relationships in the dot file as appropriate. It doesn't sound complex, but it took a heck of a lot of fiddling to get automake happy with my syntax.

graph-build.stamp:
	echo "digraph class_hierarchy" > $(DOC_MODULE).dot
	echo "{" >> $(DOC_MODULE).dot
	(IFS=$$'\n'; \
	for current_line in `cat $(DOC_MODULE).hierarchy`; do \
		depth_colours=( red green blue yellow ); \
		depth=`echo $$current_line | grep -o "  " | wc -l | sed s/\ //g`; \
		echo "$$current_line [shape=box, color=$${depth_colours[$$depth]}]" >> $(DOC_MODULE).dot; \
		last_line[$$depth]=$$current_line; \
		if [ $$depth -gt 0 ]; then \
			echo "$${last_line[`expr $$depth - 1`]} -> $$current_line" >> $(DOC_MODULE).dot; \
		fi; \
	done)
	echo "}" >> $(DOC_MODULE).dot
	dot -Tpng $(DOC_MODULE).dot > $(DOC_MODULE).png
	touch graph-build.stamp

British English translation complete

After a couple of days' work to push it up the last 10%, the British English translation of GNOME 2.22 is complete, barring any further string changes, and assuming the changes I committed to GTK+-2.12 actually turn up in the translation statistics (which, worryingly, they haven't done so far). It's verging on being late, I know, but it's better than nothing.

Hopefully this is OK for my first attempt at translating GNOME.

With bkor's help, and after a dummy commit to GTK+, the translation is now officially at 100%.