Modification of the translation templates. The proposal is to have the HTML code in the translation templates appear in different color.
Affected subsystems
Designer.
Users
Survey Managers. When translations are sent to professional translating services, getting the html code right takes a lot of iterations. For example, the template to translate something in blue says , in many cases all three words fontcolor and blue end up getting translated, causing problems with the script when trying to upload the translation files.
Surveys
All surveys that need a foreign language.
Alternatives
Right now is a manual process of trial and error, and checking until the files look right. Ideally the code would not appear in the translation templates, but that may be too complex.
What is the effect of this feature?
This will significantly make the translation process easier, quicker, and less prone to errors.
Applicability
This will apply to any user who needs translations for their questionnaires.
That’s why the color coding would make it easier. The instructions we give to translators is NOT to translate or touch anything in the HTML tags (including anything between % signs). Our new approach which has worked well is to manually color code all the HTML code to avoid this confusion.
@jolevski, while I can’t comment on the feasibility of such feature request (but don’t really see it either), below a recommendation how to move away from “manual” adding html font color code.
Based on my experience, 90% of color coding aims to highlight text substitution (i.e. any strings enclosed in %). And of those, 99% are usually highlighted in the same color.
I therefore usually instruct teams to not do any of this color coding with the Designer itself. Instead, I do add the html-tags AFTER translation using reproducible code, within a dedicated ‘Translation Management System’. Basic workflow:
Take the final/current translation file that contains original text and translation
Identify any text substitution within Translation (or particular survey specific strings that shall be color coded)
Enclose any identified in 2. with <font color=“colorname”>%xxx%</font>
Export as excel and upload to Designer
This way, Designers do not have to worry about color coding and Translators can work with “cleaner” text items, both less error prone.
In case your “Original Text” language used in the Designer shall be used in field as well (or is the only language, i.e. no translation), I do create a “Fake” Translation file that takes the translation template, fills in the translation column with the “original text” in case any text substitution is present in the string, after which I do steps described above.
My Stata package sursol has a command for this exercise. And I am publishing a small R package after the break (if I find time) which will also tackle that issue.
Interested to hear other users approach on translation as well!
Hello @peter_brueck , to the extent that I understand your approach, this always leaves the respondents with 1 language without highlighting (the ‘original’, which could be renamed to something subtle). Is that the case?
It is not a problem for CAPI surveys, but may be an issue for the respondents in CAWI surveys.
Hi Sergiy,
yes indeed, one language would be without highlighting.
You are right, it could be an issue for CAWI scenarios. While it can be minimized if you keep the default text named “Original” and the utility language “English” or the like, it indeed could still cause confusion/issues for web-respondents.
In a nutshell: Carefully consider the implications using my highlighted approach. For CAPI it hasn’t been an issue based on my experience as they selected the “English” version and left the “Original” untouched.