…and here we go again

In an article on l10n and i18n published in this month’s edition of LinuxForYou (the article isn’t available online), Kenneth Gonsalves makes a statement as (italics are mine):

The vast majority of applications today are internationalised – the need of the hour is to provide translations in Indian languages. Except for some major applications, very little work is being done in this field. I don’t know whether it is because people are not aware of the need, are too lazy or they do not know how to!

This thought seems to be the new black. Adding on to the pre-existing notions of:

  • translations are very easy to do
  • translations are for hobbyists

On some days I am surprised about why such perceptions prevail. If any language team/community works on

  • a single distribution
  • two desktop environments
  • a browser
  • a mail client
  • an office suite
  • web-site content translation
  • release notes translation

then, assuming that most projects end up following a 6 month release cycle, it leaves folks with around 3+ months (on an optimistic schedule) to work with. In fact with “string freeze” (or, the time when the developers hand off the English versions to the translators) the effective window to actually translate is around 1 month. And, I have seen that for whatever little translations I have done for GNOME and OLPC.

And, the fact that schedules are tight can be seen on the mailing lists during desktop environment release times. So, if we can assume that the teams aren’t lazy and they know what they are doing, adding any more applications to be translated (and localized) would require capacity to be added. Which means that those who do go about FOSS evangelism and FOSS advocacy have to comprehend the following:

  • translation is not easy. Idiomatic English does not lend itself easily to translations and more importantly, message strings are sometimes not well constructed to be translated. For example, read this blog entry.
  • translation is not for hobbyists. It is a process of ensuring newer applications and releases are available in the local language. Thus, it means that teams working on translations improve quality of existing translations, check for consistency and still manage to work on newer releases. It is a serious business and folks take pride in a job well done.

If there are more applications that require translations/l10n, it would be a good effort to start coordinating with the language teams (via the IndLinux mailing list perhaps) rather than assuming that teams don’t know about such applications or, are lazy.

6 thoughts on “…and here we go again”

  1. Translation _should_ be for hobbyists. Pretty all people that could deal with a given translation system, read the policy and so on, will speak (or at least read) English fluently. That means, they have little to no interest in translating things.
    That has tow consequences:
    1. Translations need to be really easy (on a “translate that string”-base)
    2. Translations should re-use all translated strings they can get

    That implies: One should set up a String-translation database to which normal users could send single fragments just when they come to their attention, po files (and other stuff) should be filled with the content of that db and then be reviewed by a professional .po maintainer.

    How about that?

    Reply

  2. > In fact with “string freeze” (or, the time when the developers hand off the English versions to the translators) the effective window to actually translate is around 1 month.

    Solution: Actually start translating as the software is developed, don’t wait for the string freeze! Then you have more time.

    Reply

    Runa Reply:

    *nod*

    Thats the best approach because besides giving an early start, it effectively also allows corrections in the English strings (lots of them are spotted by the localizers) to go through fast. During string freeze, developers generally have to wait for permission from the localization group to make changes.
    But yeah.. localizers also have to be mentally prepared to rework on bits because things change really fast.

    Reply

  3. @choeger: I’ll tell you one story about our (classic commercial) product. We had translations done by unprofessional translators – native speakers. Then one day we started to get really weird support calls. It turned out, that one translator messed up one of the strings. It wasn’t a huge mistake but it was enough to cause confusion among users. It took us 6 months to pinpoint the issue to the incorrect translation.

    Do not underestimate l10n.

    Reply

  4. Sorry, I missed this sentence “and then be reviewed by a professional .po maintainer.”

    You are right, a real pro is crucial.

    Reply

    choeger Reply:

    Yepp, pure community translation won’t work. But I think that any .po maintainer is pretty bored by translating the same sentences again and again. That leads to slow progress I have my own .po patches waiting for review on g-b-o since months.
    A single DB where a lot of suggestions are stored could really speed up things (and help ensure quality also, when the transifex step is done by pros)

    Reply

Leave a Reply