Sun, 25 Jul 2004

Mozilla translations - the translator POV

Chris Blizzard posted about Mozilla translation management. While I haven't been involved directly in Catalan translations of Mozilla, I maintain a few Debian packages of Mozilla translations to Basque and Catalan, and know now painful it can get to translate a Mozilla product.

The biggest problem, to the eyes of a translator completely used to gettext, is that Mozilla uses its own native i18n/l10n system and that's a very immediate barrier, as Chris points out. I think it would be very beneficial if Mozilla created an "official" bridge from their native formats to the PO format, which was integrated in the Mozilla build setup. Mozilla could distribute the POT file of their releases (alpha, beta, rcX), which translators could pick up, translate using well-known tools, and submit back to bugzilla. The po files would be integrated in upstream CVS, and could be available for the final releases. This would probably mean enforcing a string freeze of some kind in the final stage of the release process, so translations for rc2 would still be complete in the final version, like GNOME does already.

Right now, the Translate project is on the lead providing a suite of scripts that convert from mozilla to po and viceversa, but the process is still annoying enough and error prone to scare non-technical translators away. If Mozilla could take this and integrate it in their trees so that translators just need to care about translating the messages, and not about creating XPI files and so, I'm sure the translating effort would improve a lot in the mozilla world. MozillaTranslator is just not good enough anymore.

There are other minor problems, like some Mozilla dialogs having an apparent fixed size. For example, the account creation helper in the Catalan version of Thunderbird just shows half of the "Cancel" and "Ok" buttons, probably because the Catalan text is one or two lines longer than the original, and the dialog doesn't resize to fit correctly or so; you get a scrollbar instead. In other cases, like the About dialog, you don't even get a scrollbar. In some cases, the translator can define the size of the dialog, but this is just another problem in the translation process. GTK apps, for example, do resize and wrap text as needed. I don't know much about XUL, so I'm probably saying nonsense here.

Programs I'm missing

(In a GNOME desktop, really)...

The other day I was looking for some easy-to-use GNOME frontend for GNU parted, but all I could find in Debian was QtParted, which isn't quite GNOMEish at all. So I started thinking on the apps GNOME is missing and I'd like to use, besides the parted frontend.

I'm still using EPIC4 as my main IRC client, although I've started to explore irssi-text to see if I end up switching, given I still don't find the perfect epic script that makes me comfortable enough. These days I wouldn't mind switching to a graphical IRC client in some cases (ie, all except when I'm on a remote link), but XChat is too complex, and I'm used to HIGgy GNOME software now. I haven't tried gnomechat, but it seems to be a bit stale lately, and I really need Jimbob to work on other fronts. ;)

I'd like to manage some stuff like my CD collection, but GTKtalog is still using GTK+ 1.2, but it seems they've been working on a GTK+ 2.0 version. I really want to avoid dealing with GTK+ 1.2 apps at this stage, and it seems the porting work is a bit stalled in CVS. For books, I want to explore Alexandria, but haven't had time yet. It looks promising. I'm not sure what the state is for Photo managers. It seems GThumb is the natural choice (as suggested by gnome-volume-manager), but as my camera isn't supported by the "Import photos" thingy, I can't say how good or bad it is.

I had thought of a nice list of programs that I would like to see born in the GNOME world, but I've forgotten of most of them. It's lovely to be underslept.