A study that runs the same paradigm in several language groups raises a structural question before it raises a scientific one. Should there be one study per language, each with its own participant link and its own copy of the task, or one study that adapts to whoever opens it?
On Open Lab the answer is the second one, and the reason is worth understanding, because it shapes how the rest of the work is organised. Translations are a property of the Task — the lab.js experiment itself — and not of the Study that deploys it. A Study has no language setting. One task carries all its language versions, one study collects from everyone, and the version a given participant sees is resolved when they start.
Translations attach to the task, not the study
Three fields on a Task hold this. A switch turns localization on, which is off by default; a list records which languages the task has been prepared for; and a table maps each translatable parameter to its text in each of those languages.
The practical consequence is that adding a language is an edit to one task, not the creation of a parallel study. Data from every language group lands in the same study, in one dataset, without a merge step later. It also means the languages travel with the task: reusing that task in a second study carries the translations along.
Only parameterised text can be translated
This is the constraint that determines whether the approach works for a given task, and it is worth checking before planning around it.
A lab.js screen can hold its text in two ways. The text can be written directly into the screen's content, or it can be stored as a task parameter and referenced from the screen. Only the second kind can be translated on Open Lab, because only the second kind is a named value that a translation can be attached to. A task whose instructions are typed straight into the screen has nothing for the translation table to point at, and adding a language means opening the lab.js builder and editing the task itself.
Paradigms taken from the Open Lab Experiment Library are built to this rule deliberately. Every participant-facing string is a parameter: titles, instructions, transitions, on-screen prompts, completion text. The response-key mapping is included, which is easy to overlook — a sentence like "press the left arrow when the square appears on the left" is instructional text, and a German or Japanese participant needs it in their language just as much as the consent screen. A task exported from your own lab.js project may or may not follow this pattern, and if it does not, converting it is a one-time edit in the builder rather than a per-language cost.
Timing and design values are kept separate from translatable text. Trial counts, stimulus durations, and foreperiod ranges are parameters too, but they are not language-dependent, and keeping the two groups distinct is what allows a translator to be given the text without being handed the design.
How a participant's language is chosen
When someone starts a study, Open Lab reads their browser's language setting and records it with their participant entry. That value selects the translation. If it is absent, the language of the participant application falls in behind it, and English is the final fallback.
Nothing here is assigned by the researcher. There is no step where participants are routed to a language, because the routing is the browser's answer to a question it has already been asked. A Portuguese-speaking participant and a German-speaking participant can open the same link and each receive their own version.
Language codes are matched with a regional fallback. A browser reporting pt-BR will use a
Brazilian Portuguese translation when the task has one, and fall back to a general pt translation
when it does not. This distinction is not academic: Gaspar and colleagues validated an online
Portuguese working memory battery across both Portuguese and Brazilian samples, precisely because
the two are close enough to share materials and different enough to be worth testing separately
(Gaspar et al., 2026, Journal of Cognition, 10.5334/joc.489).
The fallback lets a study start with one Portuguese translation and add a regional variant later,
without invalidating the participants already collected under the general one.
One ordering detail matters when a study overrides task parameters. Values are resolved in three passes: the task's defaults first, then the translation for the participant's language, then any parameter set on that task within the specific study. The study-level value is applied last and wins. This is usually what you want, since a study-specific override is a deliberate act, but it does mean that overriding a translatable parameter at the study level pins that text for every participant regardless of their language.
A missing translation is silent
If a parameter has no translation for a participant's language, it keeps its default value. The session does not stop and no warning is raised; the participant simply sees that one string in the task's original language.
This is the right behaviour for a running study, since a half-translated instruction screen is better than a failed session. It also means that partially translated tasks fail quietly, and the failure is only visible to the participant. A task with forty translatable parameters and thirty-eight translated will run without complaint and show two English strings to every German participant. Checking the translation table for gaps is more reliable than checking whether the task runs, because it will run either way. The Preview facility is worth using here with the browser language actually switched, rather than assumed.
The participant interface is translated separately from your task
Two layers of text reach a participant, and only one of them is yours.
The participant application — the pages around the task, covering sign-up, consent presentation, study listings, and completion — ships translated in twelve languages: Arabic, Chinese, English, French, German, Hindi, Japanese, Korean, Portuguese, Russian, Spanish, and Swahili. That layer needs nothing from you.
The task text is entirely yours, and the translation table accepts a much wider set of languages than the interface itself covers. A study can therefore run its task in a language the surrounding interface does not yet provide, and participants would meet a translated experiment inside an English-language application. Whether that is acceptable depends on the sample.
Working with translators
Translations can be typed directly into the task's localization page, which is workable for a short task and tedious for a long one. The alternative is a CSV round-trip: the full parameter set downloads as a spreadsheet with one column per language, which can be sent to a translator, filled in outside the platform, and uploaded back.
This matters for provenance as much as convenience. A translator generally should not be given access to a live study, and the spreadsheet is a clean boundary — it contains the text and nothing else. It is also a record of what was sent and what came back, which is the kind of thing a reviewer may ask about.
Open Lab does not machine-translate the text. Every string in the table is one a person put there. For instructional material this is the correct default, since a mistranslated response-key mapping is not a cosmetic problem but a source of systematic error in one group's data.
What the platform does not decide for you
The mechanics above move text into place. They do not address the question of whether two language versions of a task measure the same thing, which is where the actual difficulty lies.
Stimulus equivalence is the clearest case. Translating an instruction screen is a matter of meaning; translating a stimulus set is a matter of matched properties. Word frequency, length, concreteness, and neighbourhood density do not survive translation, and a word list matched on those dimensions in English will not be matched in Japanese. Buchanan and colleagues' multi-language measurement of the semantic priming effect is instructive on the scale of that work, and on how much of it sits upstream of any platform (Buchanan et al., 2025, Nature Human Behaviour, 10.1038/s41562-025-02254-x). Paradigms whose stimuli are non-verbal — shapes, positions, colours, arrows — largely avoid this problem, which is one reason simple reaction time, flanker, and go/no-go tasks travel across languages more easily than lexical decision or verbal working memory.
Translation verification is likewise yours. Back-translation, or review by a second speaker, is standard practice and the platform has no view on whether it happened.
Language-group analysis is the third piece. The browser language recorded for each participant is stored with their entry and is visible in the enrolment view, so the grouping variable exists in the data. It reflects a browser setting rather than a self-reported first language, which are not the same thing — a Portuguese speaker working on a machine configured in English will be recorded as English and, unless the study asks, will also have seen the English task. If first language is a variable in the analysis rather than an incidental feature of the sample, ask for it directly and treat the browser value as what it is: a record of the version that participant was shown.
In short
Running one paradigm across language groups on Open Lab means one task carrying its translations, one study collecting from everyone, and each participant's browser selecting their version. The platform handles the routing, the fallback behaviour, and the delivery. Deciding what counts as an equivalent stimulus, verifying that a translation says what the original said, and knowing which language each participant actually speaks remain the researcher's work, and none of them become easier by being deferred.
