Tips for localizers, even from Microsoft

Many might not remember this, because I haven’ t blogged on that topic in quite a long time, but one of my interests is also localization of software. This mainly springs from the fact that I saw and I continue seeing people who don’ t even want to use Linux because they don’ t know English nor they are willing to learn it just for that.

For instance, I wrote before a proposal for internationalizing ebuilds, early this year. I also tried coming up with a feasible way to internationalize init scripts without having to deal with different scripts per every language possible.

With my interest in internationalization and localization, I also started following a Microsoft employee blog, Sorting It All Out by Michael S. Kaplan. A very interesting blog that deals with international issues like language support, Unicode and keyboards. Even if it’s of course mostly centred upon Microsoft products, it’s still an enlightening reading for Free Software developers, as it tends to explain the reasons for some choices made in Windows for properly support internationalization.

Also, the blog is quite interesting because it really takes a critic eye on the problems, showing even what Microsoft did wrong, and those are errors that other developers should really learn from. He also is a Mac user, beside the obvious Windows user, so he sometimes compare Apple and Microsoft products, giving an objective look at the implementations. So it’s really a suggested reading for any of my readers also interested in internationalization and localization problems.

Anyway, today I read his entry about redundant messages, and I was sure: Free Software developers should really learn to check out technology blogs even when they are from “the other side”.

That’s really a common mistake for free software too, using way too many strings to convey the same message. This makes translation quite more difficult, sometimes very difficult, and they might as well confuse users pretty badly.

The same applies to non-identical messages, and I’m actually seeing this in xine right now. The description of plugins is internationalized, but the problem is that even similar plugins use very different descriptions, This means that fuzzy translations can’t really help with translating new plugins.

So for 1.2 one of the entries in my personal TODO list (which I should remember to write on xine’s actual TODO). is to design and document a proper description scheme to be followed by the description of the plugins, this way the description would follow the same scheme, wouldn’t throw off the user with very different messages, and will make translation quite easier.

Kaplan announced that today’s post will be the first of a long series; I will certainly follow it so that I can learn from it and make it easier to localize xine.. then I’ll be hoping that more people will join the xine project to update the translations. On this note, I’ll also write a new entry to call for translators.

Update (2017-04-28): I feel very sad to have found out over a year and a half later that Michael died. The links in this and other posts to his blog are now linked to the archive kindly provided and set up by Jan Kučera. Thank you, Jan. And thank you, Michael.