Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

django-modelstranslation fallback original field value

I have a big Django application that is actively used by internet users. I am trying to add django-modeltranslation to one of my apps. In development everything works alright with the following procedure:

  1. Install django-modeltranslation and do the proper model changes.
  2. Create the South migration for it python manage.py schemamigration myapp --auto
  3. Apply the migration python manage.py migrate myapp
  4. Run django-modeltranslation management command to populate default language from original field python manage.py update_translation_fields

The problem I have is between item 3 and 4. If I run the migration on production, then the translated model would show no content to the user (I can't have a downtime) until I run number 4, which could take some time to finish.

I would like to know if there is a way to fallback a translation to the original content of the field without translation. This fallbacks to another translation fallback and this access the original field original. But I need the model field to default to the original field value if the translation is not present.

Thank you

like image 675
PepperoniPizza Avatar asked Feb 13 '26 01:02

PepperoniPizza


2 Answers

I was able to solve this without the need to clone the databases. What I did was:

  1. Deploy a version with the migration but without the actual django-modeltranslation changes.
  2. Run the migration. This will add several fields to the translated model but the code will still point to the original field.
  3. run the management command python manage.py update_translation_fields. This will clone the original field values to the default language field.
  4. Deploy a newer version of the code with the django-modeltranslation changes.
like image 172
PepperoniPizza Avatar answered Feb 15 '26 13:02

PepperoniPizza


  1. Clone the production database to a staging environment.
  2. Apply the migration in staging.
  3. Verify everything works in staging.

  4. Then either:

    a. Point the network configuration to staging, configure production at your leisure and reconfigure the network back (0 downtime).

    b. Update the production environment on live with the required packages and copy the database from staging environment into production (minimal downtime).