For example in an english/arabic qx I have string variables which are used in questions and static text. But the contents of these string variables don’t make it into the translation template. So I would need to know the language i.o.t. switch between different variables.
Klaus, no, this will not be implemented. This goes against our ideology. The status of a question should depend only on other questions and static conditions. Questionnaire should be invariant to the language it is administered on.
1 Like
Okay, I see your point. Then I modify my suggestion:
Include option text in the translation templates!
Imagine an arabic (chinese, russian) questionnaire offering options in english. The interviewers usually can’t even identify the latin letters.
Options of categorical questions are translated into other languages just like any other text (question text, instructions, error messages…).
When the set of options is large (combobox items lists), you will find the items to be translated on other sheets of the Excel file. Make sure the translators translate all the sheets, not just the first one.
1 Like
Okay, thanks, so options aren’t a problem (I didn’t know that translation templates can have more than one sheet).
I have another (real) case: I need to use string variables to construct a complex message, and the string constants used in the expression can only be either english or arabic. Including string constants in the translation template is probably not feasible. So here I see knowledge of the current language as the only solution.
Just an idea: If SuSo offers an internal function
string translation(string lang1-text, string lang2-text, …)
which returns the argument corresponding to the selected language, then this solves the problem without giving the qx designer the capability to tailor the interview logic according to the selected language.
But maybe you have an alternative idea?
I see your point, but I am not sympathetic to it. Readability, ability of other people (potentially low skills) to maintain the instrument, problems with PDF output, spending time on something that makes only marginal impact - constructing complicated messages - rather than on something more useful (interviewer training), complication of UI, etc. Programmers like to program…
Hello. I was wondering if this issue could be re-addressed, as the issue of readability does not seem resolved. Consider a multi-language questionnaire in French, Arabic, and English. If one needs to randomize response options in a macro, then the various options will need to be programmed as if/then statements in the macro directly and rely on an input other than the in-built language button (like a variable or Language question). Doesn’t this raise the possibility that a user or enumerator could incorrectly specify Arabic in the language button but French in Language? Wouldn’t that be more of a compromise to data collection?