Translating languages in CAPI - Lost In Logistical Translation?
At SwissPeaks we are well accustomed to dealing with complex surveys, but when we are dealing with surveys that also require translations why is it that they are so much more complicated than they should be?
It’s become apparent over the past few weeks, through recent projects, that language inclusion into a CAPI survey is often over-complicated and done with poor work practices leading to potential mishaps.
So, why is adding one or more languages into a survey script so complicated?
- The languages themselves can be incredibly difficult to work with, especially when languages have no formal written form and therefore are often tricky to translate to/from English.
- Obtaining translations before a questionnaire is deemed “final in English” is a huge potential banana skin.
Regarding point i) first – we know from first hand experience that different translators or even the same translator working on a different day might translate the same text construct within two different sections of a questionnaire differently. For example, we’ve seen four, five or even six different variations of the phrase “Don’t Know” within one particular survey.
This obviously should not happen…but sadly, it does!
Please also keep in mind that we are not working with conventional European languages, we are working within Africa predominantly where tribal language variations are prolifically in use.
A recent project required the questionnaire to be translated into Bemba. We utilised the service of a “local” field agency within central Africa and although we have no one within the office who is fluent in Bemba we are able to offer some language support.
The key to being able to check languages that are not familiar to you is to pattern match. Pattern matching words and symbols alike and establishing the likeliness of error from just looking at common sentences constructs, words etc.
We appreciate that language composition is complex and one sentence can take on different forms, depending on the person writing it, and hence this is one of the main issues with facilitating translation. We would advise using one person only with any given survey script translation and, where possible, to conduct a pre-translation meeting with the data processing manager.
In such a meeting you can make sure everyone is on the same page, especially as the responsibility normally falls on the data processing person to upload and check the language constructs to the script.
Regarding point ii) - when the survey is hosted on CAPI then it is imperative that a final questionnaire in the default language (e.g. English) is obtained first.
The default language questionnaire should be uploaded into the survey script and only thereafter should the project requirement be to get the survey translated into the local language. We have proved time and time again the efficiency in this 3-stage process but still we see, even from within the big MR companies, a policy where the questionnaire is translated before it has been uploaded into the collection script.
Also, and even more frustratingly, annotating the questionnaire (normally as written using MS Word) by adding the language translation into the MS Word questionnaire. Why is this so bad? Technology has allowed us to become more efficient and to become less reliant on user intervention and therefore to become less error prone.
By creating the script first, then from within the CAPI script, to export the questions and answers to a structured Excel file, means the translator needs to do nothing more than to type into the Excel file the local language equivalent for each and every question, answer, instruction etc.… How can we convince the powers that be to stop getting translators to write directly into the MS-Word formatted questionnaire document?
The translator has to battle their way around the MS-Word formatting that has been employed and then someone, normally in the data processing team, has to copy and paste the local language text into the survey script. Yes, for those people and companies that do follow the correct path there is still a person and/or company that follow the old method of obtaining and uploading translations to the data collection script.
The correct path should be
- obtain final questionnaire in default language then
- script the final questionnaire in default language only to the CAPI platform then
- export the questions, answers, instructions etc.… (the metadata!) to an Excel file then
- get the translator to type in the local language translation into to Excel file and finally
- import the revised XL file back into the CAPI script.
It is simple if done correctly!
However, please note, even if you follow this correct path, in practice, it is really important to make sure the final questionnaire and the final script in the default language are not changed, or if changed, then very minimally only once translation starts. Most of the logistical issues that happen occur because the final questionnaire and the final script change and change again and again, even once translations are in play.
This is so difficult a stage logistically to control and where local languages need to be “translated to” and checked and uploaded, this time point can get stressful. Now, add to the fact that you haven’t just got one local language, but two, three, four or more, then this stage becomes even more stressful and time sensitive. The golden rules must be to
RULE 1: Co-ordinate translation after the questionnaire has been scripted into the CAPI platform and
RULE 2: No changes (or very minimal changes only) allowed to the questionnaire (or the script) once translation starts.
And herein lies the issue; in that RULE 1 and RULE 2 are seldom adhered to.
Feel free to contact us if you have experienced translation issues with CAPI scripts.