lookit / lookit/lookit-api

SCOPING: Support studies in languages other than English, and with multiple language options

Open
#181 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Discussion MB-AtHome Medium Scoping
Dominant language
Python
Stars
12
Forks
21
Avg merge
5d 19h
Merged PRs (30d)
5

Description

*Pain point*: Researchers would like to be able to test families in multiple languages, using translated materials. Right now that would require making multiple versions of the same study, and there is no way for parents to simply see the appropriate version.

Notes from an email to a researcher interested in this functionality, regarding scoping needed:
The reason that more general multiple-language support, while planned, has not been planned immediately is that pretty quickly it affects a lot of UI decisions for both participants and researchers.
* Should researchers specify for each study which languages it is available in, from a list of potential languages? How should we treat slightly-different dialects that might matter for language studies but not others (e.g., providing British-accented and American-accented versions of voiceover stimuli)? Do we need to know whether the parent needs to understand a spoken vs. written language to participate? How should researchers specify which languages the parent needs to speak vs. which languages the child needs to be learning? This is probably also the time to integrate information about whether the parent and/or child to be able to hear and/or see to participate, and to provide alternate versions of stimuli where possible for blind and/or DHH kids and parents.
* How should different-language versions of study stimuli actually be specified by the researcher - e.g., as described above, versus a more general standard way across all frames of specifying that stimuli should come from different locations based on the language selected? (The latter is very doable and probably fits in with some ways we've been specifying parameters when randomizing, but I'd want a bit more time to plan and test such a setup. It would be nice to integrate some "automatic" translation in addition for common elements researchers aren't currently required to provide text for, like "next" buttons or troubleshooting text.)
* How should families indicate what languages they & their children speak and to what degree? Do we want a list of languages in preference order or just a list of languages? Should this directly affect what studies children are "eligible" for? (And should it apply separately to parents' / children's capabilities? - e.g., the parent needs to speak English / Spanish / Mandarin in order to do the consent form and/or understand instructions for study A, but it doesn't matter that the child is being raised hearing almost exclusively Cantonese because the stimuli are just pictures and music - but for study B, the child also needs to be speaking one of the listed languages?)
* How should that eligibility actually be shown to parents - e.g., should they be able to browse studies by their children's eligibility but also see all other studies? Should study information automatically be translated when possible based on their preferences, so that even titles etc. appear in the appropriate language? If a parent speaks languages A (natively) and B (proficiently) and we have a translation into language A for some studies and language B but not A for others and for neither A nor B for the rest, should we translate everything as well as possible into a usable language, or leave it to the parent to select a language for the whole page and translate whatever they can? Should there be little flags indicating e.g. "available in language A" when a non-preferred language is being used?
* How should we handle translation of site-wide content in conjunction with researcher-provided content? If we provide child forms and demographic forms in a variety of languages, should the language in which the parent filled the form out be stored and provided to researchers? What adaptations will we need to make when some languages don't have an equivalent term for a particular disorder, etc.?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files, tests, or implementation entry points are identified. Start by turning the listed questions about language availability, participant preferences, eligibility, translations, and accessibility into an agreed requirements and design document; done means the scope and decisions are recorded well enough to plan implementation.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
full-stack, internationalization
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.