Published in Tectonic
Dwayne Bailey lives in Pretoria and comes from Cape Town, South Africa. In the world of free and open source software, he is well known for preaching the localisation gospel. Here he talks to Frederick Noronha about getting started with localisation.
“Localisation is everything that makes the computer work for you in your locale (country and language),” says Bailey. “Translating the computer interfaces is by far the biggest task and ongoing, but it is not the complete picture. Keyboards, fonts, locales, date systems and rendering are all part of localisation,” he says.
Bailey has been involved with a major translation project in South Africa. “At Translate.org.za we’re localising free and open source software into all 11 South African languages. One is English. It’s quite an easy one (smiles). The others are Afrikaans, Zulu, Xhosa, Venda, Tsonga, Tswana, Siswati, Northern Sotho, Southern Sotho, Ndebele.”
But this time, at Africa Source 2, we focussed on another issue: What’s the best route for a small-to-medium language to take, if it wants to enter the world of computing?
“What I’m discovering now,” says Bailey, “is that the first things to do (for any language) is to get in place the basic infrastructure. One reason is so that they can start, the other is so that they can write and do things in their language.”
Three things need to be checked, he explains:
Firstly, you need to know whether you can type your language, and have a keyboard to do so. Secondly you need to be able to see the text so font-rendering is the issue here.
The third important task is to define a locale for language and country. In simple language this is a configuration file that defines whether your language uses the metric or imperial system, what are the names in your language for the days of the weeks and months of the year, what calendar system do you use, and so on…
Then, says Bailey, you’re really free to do translations. That’s when you need to really start thinking about what you want to achieve. Even a small group can achieve change, he believes.
“The reason why you need to define goals is to ensure you don’t kid yourself about what you’re doing. If you’re localising [GNU]Linux into Bulgarian, and you say this is being done so that Bulgarians can use a computer in their language, when in fact they all use Windows, then you need objectives that are based in reality,” he says.
Your objectives could be anything. “I’m happy if someone says I’m translating Thunderbird, the email client, into Afrikaans for my 100 year old granny,” jokes Bailey.
“It’s all about focus. Your objective helps to focus where you put in your energies. In our organisation we found we were being pushed from pillar to post. Everyone wanted us to translate something, and there was always a good reason,” he says.
“My feeling is that you have to translate stuff that focuses on the end-user. And that narrows down your scope. End-users are the people that are mostly going to benefit from whatever you do,” he stresses.
Bailey also suggests that localisation teams look at cross-platform tools, i.e. those that work on multiple operating systems such as GNU/Linux, Windows or Apple Mac. “Even within that, I would define (the more useful tools as) a sub-set: anything to do with communication is probably the most important thing to work on,” he explains.
Has he emerged wiser from his experiences of past work? “If I was going to do things again, I would prioritise it in the following order: email client, instant messaging and a word processor. When you look at (the whole of) OpenOffice.org, it’s a relatively large project. But you can (begin by) translating only the word processor.”
Can localisation in computing really make a difference to a language’s future?
In answer Bailey tells an interesting story of the Venda language, which has some 700 000 speakers. “We needed to translate it but I found there were some extra characters needed — beyond the Latin characters. So I investigated how to make a keyboard, and made it just for fun. I made some fonts.”
One translator in the team was a linguist. He talked about ‘mechanical imperialism’, where the deficiencies of the computer were changing the way people could write a language. That is still a problem.
This worked itself out in odd ways: a professional translator employed by the South African parliament to translate into Venda, couldn’t type all the characters needed. So they would type things out, and then add the ‘missing’ characters by hand. “Which is completely sad. Valuable information which could be created for the language is completely lost. That’s a demonstration that simple things could do amazing things for a language,” says Bailey.
Isn’t it sometimes an uneasy relationship between techies and linguists, both of whom need a stable partnership to make a translation project a success?
“Wherever there are issues about techies and translators, the reality is that techies don’t appreciate translation,” says Bailey. “They appreciate translation when it looks good in a press release; but in their behaviour there’s not that kind of care. But having said that, there are certain projects where there’s a growing respect for the localisers. The key thing there is usually to have a representative for the localisers (in technical teams). They often act as the go-between.”
“Once programmers see localisers as valuable members of the community and once localisers see responsive programmers we will see a healthy relationship from both sides, says Bailey. “Something that can take us onto 100 languages.”
Check out the TranslateWiki, a great starting point for localisation of your language. It offers links to: The WordForge project; The Translate Toolkit (a toolkit to convert between various different translation formats); Pootle (a portal that will enable you to manage your translation project, do web-based translation and offline translation); the Localisation Guide (a guide to how to start and run a localisation project) and a glossary of translation terms.