Tuesday, September 23, 2008

Fixing Ubuntu translation problems in a CoC-adhering way

(sorry for spamming the planet earlier when I joined, I blame Blogger, and hi all)

It's not always easy to be an Ubuntu translator. Ubuntu has always gotten a good share of critic towards Launchpad, its translations handling and its lack of devotion towards KDE. Let's first list the problems briefly:
  • Rosetta has struggled with translation imports, performance etc. each release, only slowly getting better. The struggle continues each release, but usually for different reasons than with the previous one.
  • Fixing problems directly in Rosetta is impossible since Launchpad is closed source
  • Initially some or many of the translation teams evolved chaotically, resulting in similarly chaotic translations in some cases, with no systematic way to fix all the problems until after Ubuntu 7.04.
  • Some imports have historically been messed up, and the worst apparently were on the KDE side
  • Ubuntu chose GNOME for the first flavor, and therefore KDE only for the second flavor.
There. Now that those are listed, let's just concentrate on making the most popular desktop distribution the best localized distribution there is with the aid of unique tools that are provided to enhance Ubuntu. The tools make it possible to translate every last bit (in main) regarding a distribution release, regardless of the multitude of release schedules or lack of with individual projects. If everything would be just mainline GNOME or KDE programs and distributions did zero customization (or integration), this would not be needed of course. As it is, Launchpad's Rosetta tool is still a bit unique. It's hard to have a devoted translator knowing each software's schedule for every language. An example is eg. F-Spot or any other individual, smallish project.

I have often felt alone pushing very visible i18n bugs in eg. installer and elsewhere, getting the source codes, trying to find the culprit, checking if all languages have the problem and trying to be as polite as possible when approaching all too busy developers, hopefully with ready made patches. I've enough free time only barely to check the most visible problems on the GNOME side in my language, since many problems are relatively complex and might be a combination of source code side problems and Rosetta's import problems.

So, the KDE4 Rosetta import problems are new, very bad but should not only result in bashing Ubuntu/Launchpad. Reportedly the main problem should also be resolved by week's end, let's hope so. After that, a lot of work remains to have top-notch KDE translations in Ubuntu. Here's hoping that if you do care about KDE translations (I would, if I simply had either free or paid time), don't just rant about the problems. Find out the package that actually has the problem, do exact bug reports, ask politely from the maintainer but only when you know what to ask, get the source code (if available ie. not Rosetta problem), do patches and PPA uploads with fixed packages. I'm not claiming such would not be done, I have just seen whenever I've booted into KDE in earlier releases that there are things that look like long-hanging fruits with that ugly English (it's ugly when you expect some other language:)) that could be fixed. On the GNOME side, like I stated, I've felt there are not too many people doing what I've done - helping in i18n of codec installation, ubufox, installer, hwtest, .desktop entries in default installation etc.

Of course the current KDE4 problems are bad, but we've had bad problems before, and there are bad problems on the GNOME side too :) Luckily there is also the possibility of post-release language packs, though I certainly hope there will be no need for those just because of the current situation. I'm also fearing how the documentation side turns out, since the deadline for documentation is 2nd of October, the delay from archive upload to Rosetta import completing is sometimes huge and the deadline for translations is 16th of October...

Regarding Rosetta-specific problems, I'd like to share a few additional observations:
  • You need to do some ugly stuff to fix everything. Some import problems might not get debugged for a good time, so in addition to filing a bug report, please upload the upstream PO file as "Published upload". And I have to admit even I haven't filed bug reports of everything, currently unfiled is at least an investigation plea for why libc translation was never automatically imported in Finnish. I have filed some bugs, though, almost all fixed now.
  • Go through everything relevant in Rosetta, yes browse through all 1400 template titles for those low-hanging fruits that can be fixed simply by making more translations. Check if anything highly visible is untranslated for one reason or other, and translate it.
  • Do a basic installation of an Ubuntu flavor and use it in your own language - if you see anything not in your language, it's a bug. Try first figuring out if the problem is fixable by just translating something in Rosetta. You may also install additional language support (some big language like French or German might be good idea, since they have relatively good coverage) and check if the problem is global. Find out if the problem needs a source code patch, is a Rosetta import problem or something different.
  • Sort by "Changed in Launchpad" in the template view for your language, revert whenever possible to upstream translations and commit fixes to upstream, see my instructions in a post to ubuntu-translators.
  • Also see the same post and think if your language's Ubuntu translator team should be more strictly controlled.
In addition to those translation team members that are technically competent, I would hope that more non-native English speaking developers would use their native language, despite the fact that many computer hobbyists use English. The ordinary users don't use English, and even developers don't need to use English. With English, a non-native speaker might kind of lose the contact with the concepts of what the UI terms mean, since the images that words form in one's mind work the best only in one's native language. The same reason some even good translations sound funny to a English UI user, since they hadn't thought the "F-i-l-e" menu actually means a certain real-world thing adapted into non-real world's use.

If you got lost with the last chapter, concentrate on the previous ones ;)

Friday, September 19, 2008

Clutter usage increases in future Nokia devices

Just a tidbit from maemo summit I'm visiting: Clutter will be available and used in the so called "maemo 5", which is an SDK and eventually results in a device from Nokia. Clutter is a OpenGL "2.5D" library, which means in practice easy manipulation of 2D objects in 3D space, with all the OpenGL smoothness you will want. Even though I still wonder if it will ever be that Nokia devices will use 100% free software in the whole functionality, like is possible with the Openmoko devices, I definitely have to congratulate on choosing Clutter. Good usage of Clutter will show example to others, too.

Hopefully Clutter usage will also increase on the desktop side, as I think it's the enabler of more aesthetically pleasing user interfaces in all kind of devices. Just a random example of a suggestion for Ubuntu using new gdm face browser.