Adding texts to experiments outside Python

[BeritJanssen]

Currently, if somebody designs an experiment, they need to add instructions, feedback etc. to the user in a Python script. This may put the threshold for using Amsterdam Music Lab too high.

[BeritJanssen]

I assumed it wasn't possible to translate database values easily. However, an Utrecht colleague pointed me towards this Django plugin which makes it possible to do just that. Will have to see it in action - but this addition would mean that users can add questions and translate them, all from the admin interface. It would mean a lot of work, and idem migrations to set this up, but it may be less awkward than having to go to Python for adding questions, then importing them in the right place, etc.

[drikusroor]

Why would it take many migrations? Isn't there only one translations table and can't the experiment questions just point to specific translations in that table by id or namespaced slug, e.g. gmsi.question1? It doesn't have to be a hard foreign key. I'm not (yet) fully up to speed with the current db structure and how experiments are set up so I might overlook a lot of things, but in general, it shouldn't be very hard to add translations. We could even think about supplying the complete list of translations related to an experiment as a json file client-side and use some React library for displaying the correct translation in the correct language based on the user's locale or preference.

As for the amount of work of translating words & sentences: We could also look into crowdsourced translations, making the translations public and allowing users to suggest translations. Or even use GPT's API service for that.

[BeritJanssen]

Translations are now added as needed. We would need to add models for any text we want to add via the admin & translate, and the Django plugin adds fields for every language, so that's why we'd need migrations. I've also thought about json/yaml files to use for this.

In general, it's a good idea to use ForeignKey over some reference to ids - faster retrieval, and control over situations in which one part of the database points to information that is gone in another.

[drikusroor]

Bump! Let's talk about this again 😸 I'm starting to like that django-modeltranslation you shared earlier. Alternatively, django-parler could also be an option. I've asked my friend Claude to make an overview of the differences and pros & cons:

django-modeltranslate

Here's how it works:

1. Install django-modeltranslation: pip install django-modeltranslation
2. Add 'modeltranslation' to INSTALLED_APPS in settings.py
3. Define your models normally
4. Create a translation.py file to register which fields should be translated
5. Run migrations to create new fields for each language

Advantages:

• Seamless integration with Django's admin interface
• Works well with existing Django querysets
• No need to change your existing models

Drawbacks:

• Can lead to a large number of database fields for models with many translated fields

django-parler

How it works:

1. Install django-parler: pip install django-parler
2. Add 'parler' to INSTALLED_APPS
3. Define your models using TranslatableModel and TranslatedFields
4. Configure PARLER_LANGUAGES in settings.py
5. Run migrations

Advantages:

• Cleaner database schema (uses a separate translations table)
• Good performance
• Flexible API

Drawbacks:

• Requires more changes to existing models
• Queries can be slightly more complex