The translation process is only applicable to certain field research projects but introduces a further logistical complexity when it is required.  In a country like South Africa, which has 11 official languages, even in highly targeted field studies or other data collection exercises, having surveys available in a few languages is often necessary.

On several occasions, I’ve had the experience where, after a survey has been sent for translation (and we were assured no further changes would be made), the inevitable “last” few modifications have followed soon thereafter.  Such changes could be as a result of mistakes made in the design of the original survey or based on feedback received from survey pilots.  In other cases, stakeholders who hadn’t been involved early on in the process suddenly want to add their feedback.

Short of sending surveys for complete re-translation every time a change is made, maintaining synchronisation between translations is difficult and frustrating – not to mention costly. This complexity increases exponentially with the number of additional languages.

Our approach

To overcome the logistical nightmares which often accompany multi-lingual surveys, we focused on three key areas.

Firstly, we built the survey designer to give users the freedom to design in any language and easily switch from one to another. The key point is that the structure remains intact, regardless of the language you’re working with. Logic, question order and constraints remain unaffected by the language. Only the text shown to the fieldworker changes.

Secondly, we decided to take a very practical view on the actual translation process. While it’s true that at some point in the future (watch this space) we may provide “fancier” and more collaborative mechanisms for translation, for now we settled on the concept of translation tables.

A translation table is simply an Excel export of the text used in the survey. There is a source language (e.g. English) and a destination language (e.g. isiZulu). The spreadsheet produced by the system, contains the source language for the translator as well as a cell for the translated equivalent. This file is sent to a translator who opens it and simply fills in the blanks. Upon returning the file to you, all that remains is to upload the file and the translated text will be imported and stored for the specified language.

Should a question change, the translation table is simply regenerated and sent to the translator. All their previous translations will be provided with highlighted cells indicating where their input is needed. Once their changes have been made, uploading the file overwrites the previous translation text.

The final step we took was to allow the generation of translations for any source and destination combination. Assume you have a survey which, for example, needs to be available in 3 languages: English, Afrikaans and German. You may have a translator who can speak English and Afrikaans and another who can speak Afrikaans and German. The translation functionality in Mobile Researcher allows you to export a translation table for English-to-Afrikaans and, once the Afrikaans translation has been performed, a table for Afrikaans-to-English.

Translation is an area we are planning to give a lot more attention to in the future. I think we have some really neat ideas which I’ll share with you in future posts. Hopefully as things stand currently, you’ll find the existing functionality a huge help.