Skip to content

Translation is the art of failure. (or: What makes our lifes hard)

April 1, 2009

If you have nothing to say, say KDE::DoNotExtract

While translating KDE, I sometimes see strings like “Config gui goes here…“, “application icon” or my favourite, “Label“. These come from Designer UI files where the author used labels as placeholders for texts, images and such. Using placeholders is important for layouting while creating or modifying the UI file since it shows text where text will be shown later. So leaving these labels blank is not an option. But surprise, there is the special comment KDE::DoNotExtract. Just edit the UI file with the text editor of your choice and change labels like:
<string >TextLabel</string>
<string comment="KDE::DoNotExtract" >TextLabel</string>.
That’s it. No translator is harmed. :)

Note to myself: Look if there is a way to set comments in Designer. :)

The Power of Context

Who is the president of America? No, it is not George W. Bush, good morning. But it also is not Barack Obama. In fact, America has not one single president, but many. America is a continent, not a country. Despite this fact, most people think of the USA if speaking of America. And in most of the cases it is enough, because the mentioning of America stands in some kind of context, e.g. the bailout or the war on Iraq. The context is more important than we are aware of. It changes the meaning of words from useless to useful.
This is the same for translation work. There are many words or phrases that can have several meanings if not seen in context.
E.g. writing
i18n("Edit Block Color") or
i18n("Animate Switch") is not enough.
E.g. the “Edit Block Color” could mean to “edit the color of a block” or the “color of an edit block”; the latter it is in this example. Looking at the code or application is no option since it takes too much time and not every piece of code is self-explanatory. But developers can help setting strings in question in a context. There is the i18nc() call that takes context information as a first argument. The above examples could be written as
i18nc("a database form to be filled by the user", "Form"),
i18nc("color of an edit block", "Edit Block Color") or
i18nc("option for enabling animation for the desktop cover switch action", "Animate Switch").

Note to developers: Have a look at your application’s Krazy statistics at the English Breakfast Network for some common context-needing strings.

Lokalize vs. Vim

When KBabel died, i started using Vim with the po mode plugin. Since I do everything with Vim for years now, there was not much to learn, just a few command keys:

  • \f – next fuzzy
  • \m – next untranslated
  • \r – remove fuzzy

That is enough for my daily work.
If you open several files in one Vim session, the commands are only available in the first file, though. I think that is a bug but I was not annoyed enough yet to report it.

But there is a new star on the horizon. Lokalize looks promising and it is a quite young project, so there will be progress. However, currently it freezes often while editing, edits files, that I did not touch(!), edits the templates if I create new po files, crashes after that and so on. It is nice to see if a developer is sponsored to work on new features, but it is also a pity if the bug report responsiveness suffers from that. I use it nonetheless sometimes to be pampered by great features like the translation memory or for having an overview in the project manager. That however means I have to safe after every string, restart the frozen application every 30 minutes and edit the resulting files manually afterwards to avoid wrong header information. Until this changes, I often prefer to manage the translation memory in my head and use Vim. :)

Note to myself: File more bug reports if you find the time to reproduce the bugs properly which results in step by step scenarios.

Note to developers: Lokalize needs some love.

Treatment — do not bite the hand that translates your application

First of all: These are real-life examples I translated to English but I do not want to exhume old disputes. They are only here for documentation purposes.
Sometimes programmers contact us in the following way:

i stumbled upon your translations and was kinda shocked.
I’m sorry but it’s awful.
Come on guys, is it so hard to contact the author?

Things that went wrong:

  • telling translators that you are shocked is clearly the wrong start
  • being sorry for the awfullness is not helpful
  • contacting the author for strings that do not make sense if seen out of context is no option

Note to translators: If you find strings that are not clear to you, need context, have typos, missing plural forms or anything else, please write to the kde-i18n-doc mailing list. If you are not subscribed there, do it now. It is the most important mailing list for translators.

I am more or less actively or passively involved in several projects’ translation teams. As far as I can see, our KDE translation is in a very good shape. There are applications like Step or KStars which need more than a translator to be translated properly. For many of the strings you need to be firm in physics or astronomics. If you are not it takes hours to investigate and the result might still be insufficient. This is unfortunate but also unavoidable. The overall quality however is quite good, better than I see it in the other projects.

Project Structure

One of the reasons for the lack of quality in the other projects’ translations might be, that other people are just more stupid than we are. Oooorrrr, the KDE translation infrastructure is just great. The projects I look at manage their files by uploading them (renamed as .png) to a wiki and then send the final version per email to a bugtracker or a human coordinator, the translations are not available publicly, translators have to update and merge their po files manually, and so on. Hey, the nineties called, they want their… anyway. It takes some time to get used to the way translation works in KDE but it is worth the initial overhead. There are many projects out there which infrastructures feel like rusty old bridges without guardrails. For one of these projects I offered my help and I will take the KDE way as an example, shrink it to fit the project’s needs and hope it works out.

Another real-life example:
Last week somebody reported erroneous translation of a MIME type he saw in KDE. After grepping our translation I remembered that KDE uses the mime-shared-info from So I went to their website and looked around a bit. After an hour or so I was not smarter than before. There is an old CVS repository which seems to be partly moved to Git repositories. The translation I found in the CVS repo is two years old, none can be found in the Git repos. So I decided to file a bugreport with a patch. While at it I fixed quite a bunch minor and less minor mistakes. All in all around 40 changes. The result? Closed: translations are managed at Great. Another project to be explored. After a few minutes I found the right entry in their tables. shared-mime-info is managed by… external. Great! Since I did not want to subscribe to their mailing list, I mailed the coordinator. He answered quickly and tried to help me but “external” just seems to be another word for “we do not know and we cannot check anything”. The external translator does not talk to the project at all. (Maybe some of the external translators do but external in the first place means they do not want to.) So next stop, the external translator.
Why did I not contact him in the first place? Well, I did so in 2007 but he insisted that the issues I considered mistakes are not wrong at all. Furthermore since there was no action since then I thought he might be inactive and finally saw my chance to have these changes done through the rear entrance. ;)
So it was him and me again. Two years later. We both grew up a bit, became more prudent and … didn’t change a bit. Well, two or three of the changes will likely make it into the translation but it still feels dissatisfying to me, since there are no acceptable arguments from the other side. For one change he liked, he asked me if I made it in consultation with the GNOME translators since they use the form I dropped. I did not know that, so I looked for the GMONE translators. Project number three, another mailinglist, another subscription. Oh, wait. I can write to their mailing list moderated without subscription. Now it is about two weeks later; still waiting for moderation. I am not sure if I should try hader.
Two days of browsing, reading and understanding project structures I better could have spent doing laundry.
While translating I also found two mistakes (or rather things that could be done better) in the original strings. But after that I do not want to look at the website for a while. Project Structure Fail, to use contemporary internet speech.

Note to myself: Stop here.

8 Comments leave one →
  1. April 1, 2009 8:52 pm

    Thanks for useful tips. I’ve added comment=”KDE::DoNotExtract” to 4 placeholders that I found a few months ago in kteatime.

  2. Konstantinos Smanis permalink
    April 1, 2009 9:32 pm

    If I’m not awfully mistaken, Qt Designer definitely supports comments. I remember using it extensively in the past. I think every text field has a “+” button that upon clicking reveals the Comments field.

  3. April 1, 2009 10:07 pm

    On the other hand, KDE’s translation guide needs some serious work. There’s the guide on techbase (, which is woefully incomplete, and links to the old KDE translation HOWTO (, which is extensive but out of date in many places.

    When I decided I wanted to help with the en-GB translation, I spent hours wandering around trying to find out where to start. When I eventually found out that I had to svn checkout various bits of /trunk/l10n and run some magic commands (I can’t even remember where I found those instructions), I started up Localize and was confronted with all these terms (“fuzzy”, “approval” – words that I know, but context is everything) that confused me. Am I supposed to do anything with the fuzzies? Am I supposed to mark stuff as approved, or is that for someone “special” to do?

    Now, all this is documented, but it requires looking in 3 or 4 different places and working out which bits of each are relevant. Eventually, I gave up, but I probably wouldn’t have if I’d had a clear 10-step guide (or whatever) to how to get files that I could send to the relevant mailing list and/or commit to svn.

    And this is why I’m a bit of a documentation nut and keep attacking the API documentation. Systems that make people’s lives easier are no good (or, at least, not as good as they could be) if newcomers can’t navigate them sufficiently to perform a simple task. Especially when all that is needed is some straightforward documentation.

    I would volunteer to improve the documentation in this case, but I don’t know the system (because there is insufficient documentation to get me started) and so I’m in a kind of catch-22 here.

    Anyway, that’s my two cents.

  4. Jeff permalink
    April 2, 2009 12:48 am

    I know I’m splitting hairs here, but couldn’t “America” refer to one of TWO continents?

  5. April 2, 2009 5:27 am

    Erm, are you running Lokalize on Qt 4.5? If so the freezes can be treated with a small patch to Lokalize ;)

  6. Jannick Kuhr permalink
    April 2, 2009 5:56 am

    Hmm, for me on openSUSE 11.1 with KDE 4.2.1 from Factory (Qt4.4) Lokalize is absolutely stable. I use it almost every day and never (!) had a crash.

  7. maninailft permalink
    April 2, 2009 7:18 am

    Thanks, interesting stuff

  8. April 2, 2009 8:36 am

    @Konstantinos: I looked at it quickly but could not find it.

    @randomguy3: Yes, the documentation is a bit cluttered. When I started, I had the German documentation as well and, more importantly, people to harass. :D
    Some of the issues you mention, like the string approval, are team dependant. In our team the translator approves strings. In other teams the coordinator might want to do it exclusively, though. That’s why we have documentation on our team website that describe the way we want to work.

    @Jeff: Yes, there is North and South America. It is sometimes referred to as only America. I adopted that habit.

    @DeeJay1: No, I run Qt 4.4.3. Such a patch might be fine for developers who run a self-compiled KDE anyway, but I try to keep this low and use distribution packages when possible. If there is a patch that solves issues, it should make it into 4.2.x so it reaches everybody.

    @Jannick: That is the evil thing with bugs. They do not bite everybody. I run da 64 bit Debian Sid with stuff from Experimental, my l10n checkout consists of several git-svn repositories (not cleanly svn; so many scripts/* fail here as well, no idea if Lokalize chokes on this too) and I refuse to activate stuff like Nepomuk/Strigi since they eat my CPU for breakfast and I love my battery power. Every system is different and shows different issues. On my system Lokalize has several issues it might not show on yours.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: