Not working on I18N anymore (vocationally)

Last year I left the I18N team at work. Although I hope this doesn’t mean anything — I can still do some work in my spare time as other people do, you might have observed a decline in my activity in that area. In any case, I would be more than happy if someone could help with the projects, e.g., gettext, libunistring, GNOME Characters, input methods by taking over the pending tasks (or the maintenance). Thank you.

Cooking Japanese noodles in Europe

Ramen is undoubtedly one of the most popular fast food in Japan. When I was leaving the country, I was sure that I will be missing it. So I purchased a dedicated machine to create the noodles. It is a simple, manually operated machine (like pasta makers), but has multiple functions that I needed some training to get used to.


Anyway, here are some outcomes.



The good thing here is that I can easily get quality flour in supermarket. There are actually many types of flour: wholewheat, buckwheat, etc. so I can create any types of Japanese noodles in theory. One thing missing here, however, is the Chinese magic powder that makes noodles chewy.

The broth can be made from chicken legs or pork bones which are also easy to find, and we have great mushrooms here in Czech Republic.


On weekends I enjoy trying to cook different types of noodles. I created Soba today:


It was a bit of a challenge, because buckwheat flour tends to dry out quickly.

GNOME.Asia 2016

Last month I had a chance to attend GNOME.Asia 2016, held in Delhi this year. While it was my second time to visit India – the last visit was the memorable FOSS.IN in 2012 in Bangalore, it still feels special. I arrived on the day before the first day so I could attend the whole conference. The first day was for workshops and I learned the GStreamer API for the first time.

The second day started with Cosimo’s keynote on sandboxed applications and distribution. I only have a brief experience with Flatpak and the OSTree based OS images but it seems to be the future. After that Pravin gave a keynote on Indian specific issues in GNOME and it was great to see most of the things work out of box.


On the third day, Michael talked about the GNOME based desktop environment customized for the various needs of Chinese users, which I found most interesting. Following his talk I gave a (non-technical) talk on my own experience of writing applications. In the evening, the local volunteers kindly invited us to a criket match and taught us the rules.

After the conference days, I went to Pune for work. While I had to skip the outing to Taj Mahal on the Sunday because of this, Pune was also a really nice place to visit.

I would like to thank the local organizers and GNOME.Asia team for this great conference and the GNOME Foundation for partially sponsoring my trip.



I have just got back from GUADEC, held in Gothenburg this year. It was a pleasure to attend the conference for the third time. I enjoyed meeting with a lot of smart people and chatting on various topics in GNOME. There were several inspirational talks, particularly on GTK+ and the design process, which motivated me to try out the new features and methodology in the projects I’m involved in.

I would like to thank the organizers, volunteers, and participants for the great event, and GNOME Foundation for travel assistance.

Other random stuff:

  • I had a chance to give a lightning talk on Emacs
  • while the connecting flight through UAE was a bit cheaper, it took more time to arrive (20+ hours plus train); that made me exhausted on the first day. I would suggest anyone traveling from Japan to plan the trip more carefully



Sorry for a bit belated post. I attended GUADEC this summer, in Strasbourg, France. This was my second GUADEC and it was again a great experience.

The keynotes were inspiring and the status updates on GNOME core components were really insightful. I particularly liked the Cheese, Documents/Photos, and GTK+ talks, as I learned a lot of new concepts, along with the ideas behind them. I also found the Python and GNOME talk thought-provoking.

I presented a talk on input-method. It mainly discussed smart input-method features which can be found in other platforms, while exploring ways of improving the current architecture. Afterwards, I had nice chats with Aron and William, working on the same area.

On the BoF days, I was planning I18N BoF, which ended up as a random hacking/chatting session. Sorry about that, but it was fun and there were interesting discussions about translation tools and spell checking.


Thanks GUADEC organizers for the great event. Thanks GNOME Foundation for sponsoring my trip.

GNOME.Asia Summit 2014

Sorry for a bit belated post. In the last month I attended GNOME.Asia, held in Beijing this year, in conjunction with FUDCon APAC. The conference was perfectly organized and I had a lot of fun with the enthusiastic people. Congratulations to the organizers on the successful event.

aPhoto by Rye Yao, licensed under CC BY-NC-SA 2.0

The conference started with the keynotes from both GNOME and Fedora sides, which gave me a nice overview of what’s happening/planned in those projects. The talks by the GNOME core developers were great. Allan exhibited the UI design of the access control of sandboxed applications and Lennart talked about the systemd development plan.
I had a chance to meet with a couple of speakers from Indonesia and found the geographical features and the culture very interesting, from the I18N point of view. Anish and I gave a talk about input method. He discussed the user interface focusing on text prediction and I talked about the implementation matters (slides).
Oh, and there was a mention that Japan could be a potential host of a GNOME event. Luckily, an expert was there, so we can expect it happen in near future 😉

Even after the conference we had a fun time at the speaker dinner, one day trip to the Great Wall, a Beijing GNU/Linux user group meetup, and a visit to the Red Hat Beijing office. Thanks all the people I met.

Thanks GNOME Foundation for sponsoring my travel and accommodation.


Native “.desktop” file support in gettext

The “.desktop” file format is simple, but it is a pain for translation tools such as gettext, which assumes that every output file (MO file, Java .properties file, etc) is generated for a single locale.

A translated .desktop file looks like:

[Desktop Entry]
Name[fr]=(French translation of "foo")
Name[de]=(German translation of "foo")

As you see, it mixes up the translations in multiple locales. This does not naturally fit in the current xgettext/msgfmt workflow. Traditionally, application developers have to use a wrapper script (aka intltool) to deal with this.

On the other hand, there has been a long-standing request to support the .desktop file format in gettext, to eliminate the extra dependency. So, I decided to give it a try. With the current patch set, you can extract translatable strings with xgettext as usual:

$ xgettext yourapp.desktop -o yourapp.pot

It doesn’t have much difference with intltool-extract, but xgettext properly interprets character escapes (\s, \n, \t, \r) and lists (foo;bar;baz;). This could prevent translation errors such as missing ‘;’ at the end of a list value.

Then, you can merge translations back to a .desktop file with msgfmt, one locale at a time:

$ msgfmt --desktop --locale=fr -o fr.desktop fr.po
$ msgfmt --desktop --template=fr.desktop --locale=de -o de.desktop de.po
$ msgfmt --desktop --template=yo.desktop --locale=zh -o yourapp.desktop zh.po

It could be inefficient, as it requires writing entire file for each locale, while intltool-merge processes multiple locales at once. However, I don’t think it would be an issue, since .desktop files are usually small.

I’d like to land this in the next release, so GNOME3 applications can be localized without intltool (perhaps you might remember that gettext recently got support for GtkBuilder and GSettings schema). I’ve created a sample project using those features, based on GTK+ application tutorial.

libtextinput, a minimal input method framework, as a library

Lately, I’m working on a new input method framework called libtextinput. Well, actually, I was doing some experiments making ibus-daemon lighter, but later I decided to write a new one with my own design. Yes, I know I’m reinventing the wheel but the design is quite different from other frameworks:

  • It is not a session service, but a library, so it can be directly linked to a compositor, etc. The API is modelled after the Wayland input-method protocol and much simpler than other frameworks. The main difference is that there is no concept of “input context”, so clients can directly interact with IMEs.
  • While it mainly supports in-process IMEs, it also supports IMEs running as a separate process. This feature is particularly useful for heavy IMEs like Chinese Intelligent Pinyin or Japanese Kana Kanji conversion. Out-process IMEs are automatically restarted after crash.

For more details, see the overview and TiEngineManager chapters in the reference (still terse though). It is still in early development stage but a demo program has just started working:

If you are unable to play the movie with your browser, you can download it from here (WebM, 3.1MB).


A few days ago, we RH i18n team had a lightning talk session using a TV conference system. Unfortunately, the system was non-free and not privacy aware. So I presented the lowest priority topic among my public todo items — a data format which efficiently represents the Unicode character database (UnicodeData.txt, note: 1.4MB) while providing flexible search functionality. Actually, though there are similar libraries already, few of them provide partial keyword matching.

I showed a simple algorithm using two suffix arrays, along with the size estimates. Today, I’ve prototyped it in Python as mental gymnastics. For those who might be interested, here is the code (and also a bit modified slides).

It can be used like this:

$ ./ UnicodeData.txt

$ du -ah names.* words.*

$ ./ PROLO

$ ./ 'OF P'

DSO experiment

At the GNU 30th meeting, I was doing some experiments toward a lightweight input method architecture.

IBus is based on “everything is a process” model, where each engine runs as a separate process. This is good for security and also helps developers to prototype IME in their favourite programming language, like Python. On the other hand, the approach has a potential drawback: performance. To handle a single key event, it requires context switches between processes and D-Bus IPC. As mentioned at the input method BOF at GUADEC, the performance penalty could be significant when used under Wayland, as there will be more processes involved: application, compositor, protocol translator (ibus-wayland), ibus-daemon, and engine.

So, basically, the idea is to reduce the number of processes. For IBus, given that almost all major IME have been ported to C, it should be possible to load them as a DSO instead of spawning them as a separate process.

Here’s the code for this experiment, called gisl (g* input source loader).

As noted in README, engine binary needs to be linked as PIE (Position Independent Executable) and export a stub function. The engine can then be called through the simple API of gisl, as follows:

#include <gisl/gisl.h>

static void
commit_text_cb (GislInputSource *source, const gchar *text)
  g_print ("Got commit_text ('%s')\n", text);

main (int argc, char **argv)
  GislLoader *loader;
  GislInputSource *source;
  GError *error;

  error = NULL;
  loader = gisl_loader_new ("/usr/libexec/ibus-engine-enchant", &error);
  if (!loader)
      g_printerr ("Cannot load ibus-engine-enchant: %s\n",
      g_error_free (error);
      exit (1);

  error = NULL;
  source = gisl_loader_create_input_source (loader, "enchant", &error);
  if (!source)
      g_printerr ("Cannot create enchant input source: %s\n",
      g_error_free (error);
      exit (1);

  g_signal_connect (source, "commit-text",
                    G_CALLBACK (commit_text_cb), NULL);

  g_print ("Calling focus_in\n");
  gisl_input_source_focus_in (source);

  g_print ("Calling process_key_event ('a')\n");
  gisl_input_source_process_key_event (source, 0x61, 38, 0);

  g_print ("Calling process_key_event ('\\n')\n");
  gisl_input_source_process_key_event (source, 0xff0d, 36, 0);

  g_object_unref (source);
  g_object_unref (loader);

  return 0;

Note that the engine binary itself still works with IBus. Also the API is not IBus specific, though it currently only supports IBus enignes.

I don’t know where this project is going though, I’ll show some benchmark results with a complete IM example in the next post.