Preparing a survey for translations

The following article provides tips on how to prepare your survey for translation.

For information on using the Translations applet, see Translations (r9).

Translation preparation checklist

Translations can add significant complexity to a survey. Before translating a survey, it is best to ensure that:

• The survey revisions are final (or as close to final as is practical).
• The survey programming has been thoroughly tested.
• Ideally, the survey has already launched in its primary language and live data has been reviewed.

The goal is to minimize the need for revisions to the survey after it has been translated. Managing survey revisions and translation revisions at the same time can be challenging. Translating a survey after the revisions phase reduces the possibility of human error.

The following SPL features and techniques are intended to provide a smooth translation experience.

Offering a language selection

If your survey offers multiple languages and you allow respondents to select their language, there are two ways to do this.

1. You can enable the In-Survey Picker in the Translations applet to let them select their language throughout the survey.
2. You can use the language picker tag on a radio or pulldown question so respondents can select their preferred language before they begin.

Regardless of the language chosen, the recorded data is stored in the same survey location.

Excluding content from translations

Use the translate: n tag to exclude a widget's text content from translation. This tag can be used on many types of widgets, including lists and groups.

USE. Programming Variable - Products Used
type: coded multiple select
optsfrom: PRODUCTS
translate: n

You can also add { translate: n } as an element decorator on a specific option to exclude it.

Translating sheets

Any survey spreadsheet content that has "text" in the column header is automatically included in translations. This includes the default "text" column, as well as any user-defined columns. A column labeled "example_text" would be translated; a column labeled "example" would not.

To exclude an entire sheet from translations, use the definesheet widget with translate: n.

definesheet: surveyid.mysheetname
translate: n

Including content by specifying languages

If a survey has multiple translations, the translate tag can be used to specify which languages should include certain content in translations, rather than exclude it.

For r8 software versions, enter the language codes from the 'URL suffix' column here, separated by commas.

1. What's your favorite color?
type: radio
optsfrom: COLORS
translate: spa,ger

For r9 software versions, enter the translation key, separated by commas.

1. What's your favorite color?
type: radio
optsfrom: COLORS
translate: spa-1,eng-2

Translating open-ended responses

For translated surveys, back-translation of open-ended responses is often needed. To enable AI translations of responses back to the primary language, add the autotranslate tag to the app config widget. This tag must be added before the data is collected.

Translation-friendly text piping

In some cases, survey content that uses text piping or set text widgets may not translate smoothly to other languages due to differences in grammar and sentence structure.

To avoid complications in the translation process, program the piped text so that the entire phrase or sentence is included in the overlay. This gives the translator the flexibility to provide a more accurate and grammatically correct translation.

set conditioned text: YOU_CHILD
1. do you          { if anyChecked($QGROUP,1) }
2. does your child { if anyChecked($QGROUP,2) }

2. How often __YOU_CHILD__ go to the dentist?
type: radio
1. 1-2 times/year
2. 3-4 times/year
3. 5 or more times/year
97. Only when necessary

set conditioned text: YOU_CHILD 
1. How often do you go to the dentist?          { if anyChecked($QGROUP,1) }
2. How often does your child go to the dentist? { if anyChecked($QGROUP,2) }

2. __YOU_CHILD__
type: radio
1. 1-2 times/year
2. 3-4 times/year
3. 5 or more times/year
97. Only when necessary

Creating a quota based on 'language' or 'locale'

Since language and locale are open-ended system variables, programmers often create a secondary survey variable to convert these into closed-ended data, enabling further data analysis and variable creation, like building quotas.

For r8 software versions, you could reference the language variable to set up a quota to track respondents who take the survey in different languages. For example, the quota below tracks which respondents took the survey in English versus those that took the survey in Arabic. See List of languages and abbreviations for a full list of possible values for language.

LANGUAGE. QUOTA | Language
type: quotas
1. English    {if $language eq 'english'  }
2. Arabic UAE {if $language eq 'arabic_ae'}

Similarly, for r9 software versions, you could reference the locale variable to set up a quota to track respondents who take the survey in different languages. The quota below serves the same purpose as the example above, but references the locale instead. See List of locales for the full list of country-language combinations, or find your locale listed in the Survey Links applet.

LANGUAGE. QUOTA | Language
type: quotas
1. English    {if $locale eq 'us-eng'}
2. Arabic UAE {if $locale eq 'ae-ara'}

Separating matching content in the overlay

The platform automatically combines, or chains, matching content in the overlay. To prevent this behavior, add the unchain: y tag. This allows for unique translations for content that matches in the primary language but needs different translations.

Without unchain: y:

With unchain: y: