An idea which occurred to me just now: What if there was a drop-in replacement for the gettext library which took the locale name from a GConf key rather than the environment? Then when you chose a new locale, all the apps would know about it, and we could unmap and re-map all their windows and they’d all appear in the new language immediately. There’s no reason you should have to restart an app just to change the language.
gconfettext
Published by
Unfortunately, not all gettext calls happen “late” (i.e. just before text is displayed). Some of it happens quite early in the code paths, and what’s worst, most of it is disconnected from actual widgets that display it (i.e. widgets just get the actual resulting translated string).
That means that a change of locale won’t be able to trigger eg. GtkLabel translation change live, because the only thing a GtkLabel knows about is the translated string it contains.
The solution is for Gtk widgets to keep track of what English string/context and what translation domain they are based on. This will get complicated with things like string composition, but that is bad anyway (and we should support limited strf functionality, just like with glib functions). Basically, anything that is needed for the widget itself to execute the gettext/ngettext/pgettext and similar calls whenever it desires (i.e. when locale has been changed).
Maybe 3.0 material?
Btw, make sure to save some of those gconfettis for the New Years eve :)
Sounds teh awesome. I imagine the way to implement it might be a plugin to gettext. If you can make it fast enough, that would be awesome.
If you had said “session DBus so KDE could use it too”, it’d have been awesome+. And if you had said “rewrite apps so it works without remapping”, it’d have been awesome++. I guess the best way to do it would be a GtkSession property and then adding API to GtkLabel modeled after the GtkAction API would work?
Sounds like not a lot of work to get it almost working. I bet it’s the 80/20 thing again. ;)
Is there a bug about it?
It would be a fair bit more work than that. Many applications translate the majority of their strings on start up (e.g. gtk_menu_item_new_with_label(_(“Foo”)), or the equivalent using gtkbuilder/libglade).
Remapping the window is not enough to get a new language for this sort of thing: the widget would need to store the untranslated string plus gettext domain and know when to retranslate the text. That is a non trivial API change (much more than just listening for D-Bus signals and changing the locale).
It sounds like a feature of limited usefulness though — how often do people want to change the UI language?
I tend to change language whenever I report a bug, because developers tend to not understand waht I mane when I tell them that Einfügen failed. So it’s very useful for bug reports. I also know a fair bit of people that get very annoyed at semi-translated apps and then switch languages to get a consistent language. Last but not least I know people who sometimes switch languages while they are learning that language.
There’s likely more use cases.
Has been proposed a number of times – try porting an app to support this and you’ll quickly see the problems.
Every codepath that uses a string literal has to be re-run when the locale changes… printf format string args kept around … etc. Incredible amount of work.
As brilliant as it sounds, it might not really be useful for that many people, I guess.
Users tend to choose a language at the time of login and they stick with it. What they would want to change might possibly be the keyboard layout which is already supported, but the whole UI language doesn’t seem to matter much to many.
There’s worse than having to restart an app to change the language : having to restart your whole session when you add yourself to a new group on the system!
One interesting use case would be to see how good i18n is for an app: a developer who usually runs in English could easily switch to any language and see if something remains untranslated (of course, translation would have to be complete).
I’ve been dreaming about this feature for a long time.