Domanda

I have a reusable application. In this app, some models need to be localized and I am using the django-modeltranslation app for it.

Using django-modeltranslation cause the south migrations to include the localized field in the model defintion.

For example, I i have the following model:

class MyModel(models.Model):
    name = models.CharField(...)

And the following translation.py file

class MyModelOptions(TranslationOptions):
   fields = ('name',)

translator.register(MyModel, MyModelOptions)

and two languages, fr and en, defined in my settings.py

If I run a south schemamigration on this app, south will add the name_fr and name_en field to the model definition of the migration

class Migration(SchemaMigration):

    def forwards(self, orm):
         #Here the columns are created depending but It can be managed for all languages in settings.LANGUAGES
         for (lang, _x) in settings.LANGUAGES:
             #create the column for the language


def backwards(self, orm):
         #Simimar workaround than forwards can be implemented

models = {
    'myapp.mymodel': {
        'Meta': {'object_name': 'MyModel'},
        'id': ('django.db.models.fields.AutoField', [], {'primary_key': 'True'}),
        'name': ('django.db.models.fields.CharField', [], {'max_length': '100'}),

        #The following items are the model definition and can not be generated from settings.LANGUAGES
        'name_en': ('django.db.models.fields.CharField', [], {'max_length': '100', 'null': 'True', 'blank': 'True'}),
        'name_fr': ('django.db.models.fields.CharField', [], {'max_length': '100', 'null': 'True', 'blank': 'True'}),
    }

As far as I know, this model definition is generated by south in a hard coded way.

As a consequence, it is difficult to maintain the south migrations for a reusable app using django-modeltranslation because there is no way to know in advance what are the languages defined in the settings.py of the project.

What would you recommend to manage this issue?

È stato utile?

Soluzione 2

The option I choosed is to disable (remove from INSTALLED_APPS ) models translation when making a schemamigration and let sync_translation_fields manage the creation of missing translation fields.

It seems an acceptable method : https://github.com/deschler/django-modeltranslation/issues/106#issuecomment-33875679

Altri suggerimenti

To be honest I wouldn't add those migrations to the package at all, one shouldn't force fixtures upon a 3rd party user. A nice way could be to create a demo project within the package and add proper documentation, e.g. (django 1.4+)

repository_root/
    example/
        example/
            __init__.py
            urls.py
            settings.py
            static/
                js/
            fixtures/
                data.json
            migrations/
                reusable_app/
                    __init__.py
                    0001_initial.py
        manage.py
    reusable_app/
        models.py
        urls.py
        views.py
        admin.py

Add a few settings to settings.py to keep things clean

def rel(*x):
    return os.path.join(os.path.abspath(os.path.dirname(__file__)), *x)

FIXTURE_DIRS = (
    rel('fixtures'),
)

SOUTH_MIGRATION_MODULES = {
    'reusable_app': 'example.migrations.reusable_app',
}

Make sure you add the following line after your import statements in manage.py to make sure you're working on the local reusable_app not the (installed) one in site-packages

sys.path.insert(0, os.path.dirname(os.path.dirname(os.path.abspath(__file__))))
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top