I wrote before about internationalisation. Albeit I’m a good English reader (I don’t speak or write it too well, but I can read it pretty well), I do think about the people who are not this lucky, and I can ensure you, I know a lot of those people, because in Italy it’s not as in a lot of other countries where knowing English is a common thing.
One of the nice things I can tell about Fedora is that they are quite concerned with this kind of problems, and they deprecated GTK+ 1.2 because its Unicode/UTF-8 and i18n supports are pretty much missing, while GTK+ 2 has a very good support for both. This was quite a good thing to do, in my opinion, because it focuses the attention of people to the need for modern toolkits and reasonable translation support.
Ubuntu also is concerned with the availability of free software for people who don’t speak English, and this is shown by their tries to improve the availability of translated software through the Rosetta application in Canonical’s Launchpad framework — that if I have to be honest I don’t trust, as I don’t understand the reason why they don’t try to free Launchpad, if they have the success of Free Software at heart, but that’s another story entirely.
I also read quite a bit of entries in Planet Debian about their efforts to improve localisation support in their packages, and that is quite good.
Something I instead never seen in Gentoo are people concerned with improving the internationalisation support in Gentoo, either packages, tools or ebuilds themselves. I used to fix some ebuilds so that they answered correctly to LINGUAS instead of abusing the cjk flag, I used to work on CJK packages to improve them, so that they actually worked, and I started adding proper support for the LINGUAS variable to a few KDE packages, but these are really little things, they don’t really change the user experience so much, as the bases still require you to know English to an higher degree than is required for other distributions.
Maybe asking for every bit and string of Gentoo being translated is too much of an overkill, but it would be nice to see at least some tests on getting Portage, baselayout, or whatever else to actually be translated.
Why am I writing all of this? Well if there is one thing that I suppose everybody would agree on about last year’s Summer of Code, most of the ideas proposed weren’t thought about for too long, and the results were badly affected by this. So as now we start talking about Summer of Code 2007, I want to write my proposal here.
It would be nice to have a project for Google Summer of Code 2007 that actually has an impact on users. Someone could try to add good i18n support for Gentoolkit, or for Portage-Utils, maybe even for Portage itself. Although these seems to be easy tasks, there is at least one that is non trivial and might be worth pointing for: finding a good way to allow internationalised messages in init.d files and ebuilds. For init.d files it might be easier than you think: gettext can be used to translate strings directly, you just need to have a tarball with the init.d file, the .po files, compile the .mo files, and get baselayout to have a “echonls” function so that the strings you echo there are passed through gettext (if you installed baselayout with nls useflag of course). Ebuilds can be harder, but I have a couple of ideas myself, the problem is to find a way that is good enough not to hinder the general ebuild maintenance, and not to bloat the tree too much.
I know most likely my suggestions won’t be considered at all, or might just be considered ramblings of a fool former dev, but, well, I have still hope that someone will work on that sooner or later.