Localization: What are we missing?

[This blog post is kind of self criticism and written not forgetting the valuable contribution that l10n communities are doing. ]
Some observations on the Localized desktops in Indian Languages
* Not all localization team members try the application that he/she translate at least once before working on the PO file. Result: If somebody does the localization without understanding what the application does and try the en_US interface, he/she miss the context of the strings. An example I have seen : the string “Querying” was translated to xx_IN language string which means “Questioning” instead of the required string corresponding to “Searching”. Sometimes we miss to understand how much space the string is going to take in the screen and we translate a small English word to a long xx_IN string to make the meaning clear. Result: Ugly interface.

Tamil gedit from Ubuntu 8.10(Click to enlarge)
* Not all localization team members *try* the application that he/she translated after completing the PO file or even after the application is released. This happens when he/she translates many applications(sometimes if it is part his/her job).
* Practically, there is no process called *testing* localized desktop in our SDLC. L10N members translates a PO file and sometimes he/she translates it as text file rather than a user interface. It is must that we should bring some process to make sure that the localized desktop is tested for usability, contextually correct translation, spelling mistakes, wrong short cut keys, fuzzy strings , non translated strings in main interface etc etc.
* Since the ratio between the total number of applications in a desktop environment and number of team members is very less, we end up in translating one application by many people. Result: inconsistent translation and no ownership for ensuring the translation quality. Ramadoss from Tamil team was suggesting that ideally , for each application there should be a person from each language , who is responsible for timely translation, testing. He can take more than one application responsibility but not more than say, 10. Practically, this requires a big l10n community per language and unfortunately we don’t have it as of now.
* Peer review, one of the important and mandatory process in l10n is not happening properly when the release date is approaching. L10N communities often try to meet the percentage of completion somehow. IMHO, the new l10n tools frameworks often miss to give importance for peer review in the workflow they design. FOSS community, being inclusive in nature often welcomes new l10n contributors. I have seen many members improving their l10n skills after making the corrections as per the review comments from others. When a new l10n workflow allows every contributor to submit their translated PO file without the peer review from community, the ultimate result is very bad user interface. We have seen this many times with Rosetta translations of Ubuntu. Everybody going there tries out the Rosetta “features” and leave few strings “translated” there. And Ubuntu takes those strings for their immediate release. Upstream translations are never taken on time or the “translated” strings are never submitted to upstream. Result: Very bad localized desktop with many spelling mistakes, inconstant translations etc.. We ml_IN team used to watch who is “contributing” through Rosetta and make him work with the community. I hope the new translation frameworks will give sufficient attention to this problem. If we are not keeping a balance between newbie translation and quality assuarance , our localized desktops will not improve.


Again Tamil gedit, but from Debian Lenny. Compare it with the Ubuntu version shown above(Click to enlarge)

* User feedback: The number of users who use the desktop in their own mother tongue, even though the % of translation is more than 80% for many languages, is very less. IMHO, It is because of a ‘dependency conflict’ of the following things
a) A person who is not good in English
b) A person want to use computer in mother language for some “purpose”
c) A person who is capable of spending Rs ~20K for a computer
Most of the cases, there is a conflict between any 2 of the following and that ends up in a) Person use his desktop in english b) Person not using computer at all. I am sure that if there are good number of users, we will not end up in interfaces I showed in the screen shots.
* One inconsistency I noticed across localized desktops is regarding the shortcut keys/accelerator keys. Some languages use English short cut keys and give at the end of the word in Brackets for eg: അടയ്ക്കുക (C). As you can see in screen shots sometimes we have small letter and sometimes capital letter for that. Some languages use letters in xx_IN itself. But there is no consistency. For Control and Alt keys, some language translate them, some others keep it in English. What is the problem with English short cut key? For using English short cut key , the user should be using English layout keyboard. For shortcut keys in xx_IN, one should be using xx_IN keyboard layout. For a user(assume that he use xx_IN desktop since he is not good in English) typing in xx_IN in gedit using xx_IN keyboard, is it possible to use the short cut keys if we give in English? Are we expecting that for using short cut key while typing the document, he change switch his keyboard layout ? (btw, anybody noticed that Apple doesn’t use Accelerator keys in its OS?)

bn_IN gedit in Ubuntu 8.10(Click to enlarge)

ml_IN gnome dictionary client in Ubuntu 8.10(Click to enlarge)

Suggestion/Ideas are welcome… How can we make our localized desktop more beautiful and user friendly?

3 Responses to “Localization: What are we missing?”

  1. Anonymous says:

    Localization issues

    Having a *real* community (not just 1 or 2 person) of localizers (most importantly translators) should have resolved all of the above issues for Indic Localization.

  2. Anonymous says:

    Localization is a pretty big effort and as Santhosh points out, it is time for looking into the quality of translation. When SMC started localization efforts, we worked with the idea of context sensitive translation. We even keep a guideline for translations and glossory of terms. But this is not enough for completing the cycle. Peer review is one good method and it takes up a lot time than normal translation. Before we used to have sprints for translations, i think we should have sprints(online/offline) for review of translation.

    About the keyboard shortcuts/accelerator keys, i believe its a necessity. We may have to do some innovations(one idea is keeping the same keys, and if it triggers an acceleration, irrespective of the locale set on keyboard or tranlit interface, point it to accelerator). I know its not easy and right solution. This just came to my mind. I should say, i don’t know the control flow in the programs, but we should be able to find some way around.

  3. alok says:

    the answer lies with the user

    Creating (very broad) guidelines for translations and making it easy for people(users) to submit bug reports will help a lot and it will even make the sometimes mechanical translation work so much more interesting too.

    The real issue as you pointed out, is: are we doing l10n for the sake of seeing the %ages go up in the graphs for our $LANGs or because we want to create something useful for the person who doesn’t know English but knows $LANG?

    If we keep in mind this fact while translating, things would change.
    Lastly hats off to all the volunteers for all $LANGs.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>