People have asked a number of times about changing the languages in applications on the fly. This isn't something that's currently planned in GTK+, and it's a bit of a pain. However, if someone was sufficiently motivated, they could attempt it. Note that this is going to take more work than just a patch to GTK+. Applications will need to be ported to use a new API, and we might decide that the gains of language changing aren't worth the pain of porting.

Issues

There are a couple major problems with changing languages on the fly.

• Widgets need to keep the original C text around.
• Some human readable strings are a composite of multiple strings, and not easily encapsulable.
• Applications will have to do their own handling for things like models, custom widgets, etc.

Possible solution

We could add something like:

gtk_label_new_translatable (N_("This is a label"));

This label would keep the string in it's 'C' locale and translate it on demand. Thus, when the language changes, it can pass the string to gettext. It gets trickier with more complicated strings. For example, nautilus's status bar might have to look like:

gtk_statusbar_push_translatable (sb, context_id, N_("%d items"), n_items);

with varargs, so that we can translate the string before doing printf-style compositing.

• Note that these functions would also need to take a DOMAIN argument, in order to make them usable from libraries. If they can only be used to look up strings in the default translation domain, then it would be nearly impossible for a library to provide translatable labels, since the strings would need to be in every app's message catalog -- JamesHenstridge 2005-08-03 06:31:49

Other problems

It gets trickier still when joining two strings. Consider the following code:

str = g_strdup_printf (_("Your pet is a %s."), dangerous ? _("piranah") : _("goldfish"));

label = gtk_label_new (str);

g_free (str);

We obviously can't translate the composited string, so we need to translate both the format string and the substring on the fly. Maybe we can indicate that via an extra format marker -- something like %_s