Migrations in Django 1.9: verbose_name and verbose_name_plural

[Marco Badan]

Hello, 

I've upgraded a project to Django 1.9.

I've:

LANGUAGE_CODE = 'it'

LANGUAGES = (('it', 'Italian'),)

With Django 1.8 after running makemigrations I got the no changes detected message.

On 1.9 makemigrations creates migrations for all of my apps and all third party apps.

I had a look at the new migration files and I've a lot of AlterModelOptions and AlterField.

The relevant changes are on verbose_name and verbose_name_plural:

With 1.8 I had untranslated strings (English), with 1.9 I've the translated strings in Italian.

    (...)

    

    operations = [

        migrations.AlterModelOptions(

            name='category',

            options={'verbose_name': 'categoria', 'verbose_name_plural': 'categorie'},

        ),

        migrations.AlterField(

            model_name='category',

            name='description',

            field=models.TextField(verbose_name='descrizione'),

        ),

    (...)

    

    ]

How can I avoid this behaviour?

[Tim Graham]

The only thing that comes to mind is a paragraph in the 1.8 release notes, "When the leave_locale_alone attribute is False, translations are now deactivated instead of forcing the “en-us” locale. In the case your models contained non-English strings and you counted on English translations to be activated in management commands, this will not happen any longer. It might be that new database migrations are generated (once) after migrating to 1.8." but you said you upgraded from 1.8 to 1.9, so I guess it isn't relevant.

If you could bisect Django's commit history to find where the behavior changed, that might yield some insight.

[Marco Badan]

Hi Tim,

my models (and all my project files) contain only english strings. Italian is only on *.po files.

I used git bisect and this is the first commit that triggers the migrations:

https://github.com/django/django/commit/fe3fc5210f0bb334a679ed420152af1c862c0239

And ....it's about urls, not migrations.

I've a few RemovedInDjango110Warnings related to urls due to 3rd parties packages (django.conf.urls.patterns() is deprecated, Support for string view arguments to url() is deprecated)

[Tim Graham]

Hm, see if you can isolate which URL pattern is causing the issue. Seems like there might be a module level translation activation that's triggered when the urlpatterns are processed.

[Marco Badan]

ok,

I was able to isolate the url: it's from django cms 3.2.1.

The django cms devs have already fixed the warning (django.conf.urls.patterns() is deprecated and will be removed in Django 1.10) in develop branch.

I get the unwanted behaviour if I put back the warning using django.conf.urls.patterns

For reference:

the url is here and the related view is WizardCreateView.

Cheers

Marco

[Marco Badan]

oh, it was you that fixed the warning in django-cms so... thanks again

[Tim Graham]

Interesting.... I have no idea how that's related but I'm glad it's solved for you.