views:

202

answers:

6

What is the best practice to translate a commercial software for many different languages? Currently I see 3 possible solutions.

  1. You use professional translator. The large problem is that this people does not understand the context. The translations are very curious. Also there are large cost. On every release you need renew contact the translators. It is limit to a small range of languages.

  2. You use the customer of the product to translate it. Is this acceptable for a commercial software? The customer have spend money for the software. Are there any software that can handle this? It should have double login and a voting system to prevent vandalism. You will have a translation for all this languages which the customer want.

  3. We have the software only in English. There are no confusion through bad translations. The support is simpler, etc. But you will lost customer that not speech English.

+2  A: 

I think you should go for professional translators... These days it's very easy to find translators for almost any language on the Internet. There are specialised freelancing websites.

That's where I go when I need translating or writing work done.

It's very convenient and pretty pocket-friendly.

Cyril Gupta
A: 

There are professional technical translators. So that shouldn't be the problem.

We (the developers) provide for the English and the Dutch translation. The other languages are provided by professionals.

Gamecat
A: 

You can do both: translate the software to several leading languages. With help of professional, and continue supporting changes with help of ordinary workers that know the context and language.

Allow translation by customers for less frequent languages. Systems like gettext allow you creation of independent translation dictionaries that can be given to customers that may create translation full or partial according to their needs. Also updates of software would not brake completely the translation.

This is quite common practice in Open Source projects. When the software is developed in English and translations are provided by community.

We have the software only in English

This is generally not good idea, give a customer an option to use software in its own language. There are many countries where English is not known well.

Artyom
A: 

One thing that may help is to use icons for common tasks as far as possible. Also, if you list the item descriptions in a separate resource fork/data file, it will be much easier for the translators to work and update without recompiling... I have seen that done many times in commercial and open source packages. #2 is the kiss of death and #3 is not strictly necessary, if there is a smart use of icons. As long as the most common stuff has an icon with a translation under it (File load, save, open, etc.), and as long as error messages are meaningful, that would address many concerns.

Damien
A: 

Implement a "Translator" role in your application and give him simple interface to translate the words and msgs. If possible give him also the possibility to try the software (some of the msgs do need adjustment according to the context of the use case even the text is translated literally correctly

YordanGeorgiev
+1  A: 

This sort of thing is covered by internationalization, often abbreviated to i18n. There's a lot of questions about it on SO already, and a lot of resources. There's also a whole lot of issues other than just translation. This is a big subject, and if you're going to branch out of one culture you need to get familiar with it.

Whether customer translation is reasonable depends on the type of software. It isn't going to work for shrinkwrap software, but might be agreed on as part of consultingware installation.

If you have translation expertise in-house, you might want to use that. For example, perhaps you could translate into your native language (please don't tell me you're a native English speaker). Other than that, hiring professionals is the way to go. One problem to consider is context, as phrases can be translated differently depending on what they're intended to mean.

David Thornley