This Time Self-Hosted
dark mode light mode Search

Internationalisation is important

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.

Comments 3
  1. I’ve had this idea of i18n-ing ebuilds, initscripts etc. already some weeks ago.Why not creating a “po” or “translations” directory in the portage tree, which contains subdirs like “en_US”, “de_DE” .. ?Then depending on the LINGUAS set, the other subdirs could be excluded.Although you’re not a Gentoo dev anymore, it’s something you maybe could develop in an overlay.If you’re really planning doing this, please contact me. Maybe I could help a little bit and/or provide German translations.Regards, Elias P.

  2. This is from a translator: There are huge barriers of entry to translating anything within Gentoo. It is more or less possible to do the GuideXML journey but anything beyond that, which isn’t separated like .po files or sth like it, is just unworkable. Seriously, revision history can be horror in itself!

  3. This is why I’d use .po files as much as possible, but for ebuilds, I don’t really thing that is feasible, something similar can be arranged though, at least I think it’s possible, a generic translation method is feasible, it’s just to see how much the process can be streamlined.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.