Allow English and German Titles for Events

[roggnroll]

For events it is currently only possible to have separate German and English Descriptions but not separate Event titles in English and German

[roggnroll]

@renatobellotti @gitsimon What would be the best way to solve this database wise? Create an english name column in the event_event table or create a new table where the German and English title are stored alike, similar to the event description in table events_event_translation? (The last approach is certainly better if we ever plan on adding more languages)

[renatobellotti]

I think the main issue here is the migration of existing events, regardless of the structure we choose. I'd prefer the approach with a separate table because it'd make it easier to add support for other languages in the future. I don't know much about Django CMS, but I assume the back end structure will be hidden for users? If not, we should pick the solution that changes as little as possible to the GUI compared to now.

[roggnroll]

Migration shouldn't be a problem at the moment as we have very few new events planned. I don't quite know what you mean with back end structure, but no the users cannot see the structure of the database. Changes to the GUI should be minimal.

[roggnroll]

We could also leave the old name column intact for backward-compatibility

[gitsimon]

Django comes with a very advanced translation system for static strings, but not for database fields. Luckily there is an amazing plugin that we are already using called django-parler

If you have a look at the models.py in the event app, you find in the Event class

translations = TranslatedFields(
        description=HTMLField(verbose_name='[TR] Description', blank=True, null=True)
    )

As you can read in the django-parler documentation, the fields listed inside are automatically represented in separate table (to support arbitrary more languages without changing all database table schemas).

Note: you are never manipulating the database directly! This is handled by Django's automatically created migrations quiet well.

The case of moving an untranslated one to a translated one, is a little involved: you either

• add translated field (different name should not be necessary) in migration a
• copy current content to german (or english) translation manually
• add another migration b, that removes the old untranslated field

Luckily, this problem appeared before, and you could also perform this steps in a single migration without any manual copying of fields! Have a look at this migration.

This seems complicated, but most of the migration is auto-generated by Django. So the approach is as follows:

• Add translated field (keep old field untouched)
• Let Django create default migration python3 manage.py makemigrations (inside docker container or use script)
• edit the created migration and add the method migrate_untranslated, adapt it and call it at the correct place in operations, so after creating the translated field and before deleting the old field, with migrations.RunPython(...).
• Finally you can run your modified migration with python3 manage.py migrate (inside docker container or use script). Test this first locally!