Make a clear statement regarding South

[deschler]

Modeltranslation has to make a clear statement regarding South, which can be considered the de-facto standard for database migrations in the Django world nowadays.

While modeltranslation includes a little helper, namely the south_field_triple in fields.TranslationField, this obviously isn't enough to cover all use cases. It seems to satisfy the basic needs, but especially 3rd-party-apps have additional requirements (e.g. i've stumbled across a ticket in django-fiber, the comments are somewhat contrary, but there obviously is a problem).

The included management commands update_translation_fields and sync_translation_fields help with most modeltranslation related migrations, but reinvent solutions that might probably better be addressed through South.

This ticket tries to gather the facts and evaluate what we can do (if at all) to improve the current situation, even if this only means to take a clear stand in the documentation.

That said, i am not a good candidate to make modeltranslation more South-friendly as my knowledge about it is basic at best.

Ideas and suggestions are highly appreciated.

[deschler]

Forgot to mention that South itself happens to use modeltranslation as an example in its documentation about custom fields.

So my impression is that the only problem other apps have with modeltranslation is the fact, that existing projects have to run update_translation_fields to move the existing values from the original field to the default translation field.

[jaap3]

I think the other problem is that south does not expect schemamigrations to be happening from anywhere but the app. So let's say you translate the app foo, then create a schemamigration for it. It will be called something like 0002_translate_foo (it comes after 0001_initial).

Then you update the app foo, and it comes with it's own migration to add new fields, this migration is called 0002_add_fields. South will now get confused, the new migration won't list the translated fields, but a previous migration (the one created for modeltranslations) did.

I'm not sure if I'm explaining it well. But the general point is that modeltranslations creates migrations that are not really application migration and things will get confusing after a while, especially when a application starts shipping new migrations. Things get more confusing if you start adding new translation migrations to translate these new fields in the application.

It would be helpful for you to talk to @andrewgodwin, as he's the autor of South and is also working on getting schemamigrations in django.contrib. Or talk to the people in #django-south on freenode.

[ljean]

I agree that it has to be clarified. I don't know what is the right way because there are certainly several use cases and I don't have a deep knowledge on both apps.
I am facing the following issue with a reusable app : http://stackoverflow.com/q/4840102/117092
I hope it helps
luc

[zlorf]

I've made some research and wrote down my final thoughs in the docs. Summary here:

• South is super and sufficient if you are starting a new app with translations or adding translation fields to your own app.
• When trying to add translation fields to third-party app that is using south, there arise difficulties that @jaap3 mentioned. The goal was to alter the app and allow it to be upgraded in the future (with new migrations shipped). I was able to provide a migration in project directory, but it required toggling SOUTH_MIGRATION_MODULES setting and passing --delete-ghost-migrations on first ./manage.py migrate following app update. That is not user friendly. However, sync_translation_fields command is handy here: it can patch the database, adding translation fields, and new app migrations can be run afterwards. No migration history tweaking needed.

The only thing I'm not quite sure about are "migration freezes" (the dump of model fields included in every migration file). They will always lack the translation files, but it seems it doesn't matter and app migrate successfully anyway, without any warning.

[ljean]

I may be wrong but I am wondering if the right way to manage it would be:

• Give the possibility to exclude translated fields from the south migrations. If I have a translated field title in the Article model of my_app. Running python manage.py schemamigration --auto should only take the title field. The title_en, title_fr (...) shouldn't be manage by south.
• Then you can create the translated fields (title_en, title_fr...) by calling the sync_translation_fields command.

Currently I have a workaround for this : I don't add model translation to the INSTALLED_APPS if schematranslation is in sys.argv. It seems ok.

What do you think about this approach?

[zlorf]

As long as you handle migrations for your own app (non-reusable), you can freely and safely use south.
But your method also sounds good and seems to be valid (especially when your app is reusable one and you need to keep translation fields out of migrations).
However, I trust south more than I trust sync_translation_fields. :) So I prefer to use south whether applicable.