Changing locale causes migrations autodetector to make unnecesary changes

[foonicorn]

A migration is created after fields like help_text changed, although this is not relevant for the database. This also occurs when i18n is used and the translation changes.

[loic84]

FWIW I don't think it's a good idea to start blacklisting / whitelisting parameters, especially with custom fields in mind.

[Markus Holtermann]

I'm going to implement it in a way that fields can define their own non-db-relevant arguments.

[Andrew Godwin]

I'd rather we included every single field - white/blacklisting fields is dangerous. What if a field subclass redefines help_text? What if it uses it to help populate ORM objects? I'd like to mark this WONTFIX.

[loic84]

+1, I'm particularly concerned by the fate of validators which were blacklisted in the tentative patch presented on IRC.

Also with the upcoming VirtualField we will be blurring the lines more and more between the ORM and the underlying schema.

However there seems to be an valid issue here, i18n locale shouldn't trip the autodetector, I haven't had time to look into it but I suspect this is due to the fix for #21008.

[Markus Holtermann]

I think we should find a solution for this: imaging your translators change the translation for a help text. All the time they do one developer will end up with such a new migration.

The way I implemented it allows fields to redefine their attributes. It's a prove of concept: ​https://github.com/Markush2010/django/tree/ticket21498

[Andrew Godwin]

I agree that the locale shouldn't trip the autodetector, but changing help_text unfortunately has to (we just can't guarantee it's not useful at database or field runtime).

Perhaps we should force a certain locale while running the autodetector?

[loic84]

To solve this we may need a better way to handle Promises, maybe we could make them "deconstructible"?

[Andrew Godwin]

Well, the serializer currently runs any Promise through force_text before saving it, but the autodetector doesn't serialize anything before it compares. To be honest, if we could make Promises comparable (and make them evaluate on eq) that would solve it.

[Andrew Godwin]

Claiming this to fix it tonight, as it just got way worse now we have migrations for contrib apps (upping to release blocker due to that)

[Andrew Godwin <andrew@…>]

In d359647715bccffd7cfc5eb8bcf5edb5c714fb00:

Fixed #21498: Don't use a fallback language if you're en-us.

[Andrew Godwin]

Oddly, no fix was needed on the stable/1.7.x branch, as it did not show the symptom in my tests; this appears to have been fixed by a the new autodetector code and then broken by ​https://github.com/django/django/commit/a5f6cbce07b5f3ab48d931e3fd1883c757fb9b45.

If someone can get the problem on the stable/1.7.x branch please reopen.

[Simon Charette]

@ChillarAnand, please don't re-open without providing a valid reason.

Did you manage to reproduce the issue on the stable/1.7.x branch?

[Tomáš KOSTRHUN]

I can reproduce it on 1.7.2.

Started the project with

LANGUAGE_CODE = 'cs'
LANGUAGES = ( ('cs', 'Czech'), ('en', 'English'), )
USE_I18N = True

all model fields with verbose_name in Czech like

from django.db import models
from django.utils.translation import ugettext_lazy as _

class Book(models.Model):
    name = models.CharField(_(u'Název'), max_length=255)

initial migration

('name', models.CharField(max_length=255, verbose_name='N\xe1zev')),

after I've added en locale and translated "Název" as "Title" makemigrations shows

migrations.AlterField(
    model_name='book',
    name='name',
    field=models.CharField(max_length=255, verbose_name='Title'),
    preserve_default=True,
),

when I import _ in models.py just as ugettext (not ugettext_lazy) problem disappears.

[Tim Graham]

Hi Tomas, can you test with Django's master branch? I believe that issue might be related to/fixed by f7c287fca9c9e6370cc88d1457d3ed9466703687.

[Markus Holtermann]

Replying to timgraham:

Hi Tomas, can you test with Django's master branch? I believe that issue might be related to/fixed by f7c287fca9c9e6370cc88d1457d3ed9466703687.

It's exactly the case I constructed in ​https://github.com/django/django/pull/3838#issuecomment-68784330

[Claude Paroz]

In Django 1.8, you *might* obtain a new migration just after having upgraded from 1.7 (if the existing migration uses a translated string), but then the translations won't affect migrations any longer.

[Tomáš KOSTRHUN]

Replying to timgraham:

Hi Tomas, can you test with Django's master branch? I believe that issue might be related to/fixed by f7c287fca9c9e6370cc88d1457d3ed9466703687.

Hello Tim, yes, django trunk shows "No changes detected" so it's OK.

[Hedde van der Heide]

This issue re-occurs on 1.9.2, I managed to overcome it by overwriting the makemigrations command then forcing a default locale.. perhaps this should be a django setting anyway, optionally adding the falg through cli?

[Claude Paroz]

I was not able to reproduce it with Django 1.9.2. You might have to create a sample project where this can be reproduced to convince us.

[Martin Bächtold]

Replying to Claude Paroz:

I was not able to reproduce it with Django 1.9.2. You might have to create a sample project where this can be reproduced to convince us.

I have created a sample project available at ​https://github.com/mbaechtold/django-ticket-21498-demo

Hope this helps to convince you this is still an issue.

[Claude Paroz]

Martin, many thanks for the sample project. Could you please try to reproduce the issue by replacing ugettext by ugettext_lazy in the polls/models.py file?

[cryptogun]

Same problem here. makemigrations executed from production server and local server would always generate new migration files. Not good for Git control.
App: ​django-avatar

diff ./avatar/migrations/0006_auto_20170329_0405.py ./avatar/migrations/0007_auto_20170329_0455.py 
2c2
< # Generated by Django 1.10.5 on 2017-03-28 20:05
---
> # Generated by Django 1.10.5 on 2017-03-28 20:55
14c14
<         ('avatar', '0005_auto_20170306_1939'),
---
>         ('avatar', '0006_auto_20170329_0405'),
20c20
<             options={'ordering': ['-pk'], 'verbose_name': 'avatar', 'verbose_name_plural': 'avatars'},
---
>             options={'ordering': ['-pk'], 'verbose_name': '头像', 'verbose_name_plural': '头像'},
25c25

...

[Tim Graham]

It's a bug in django-avatar -- it uses from django.utils.translation import ugettext as _ rather than ugettext_lazy as Claude mentioned.

[Martin Bächtold]

Replying to Claude Paroz:

Martin, many thanks for the sample project. Could you please try to reproduce the issue by replacing ugettext by ugettext_lazy in the polls/models.py file?

Claude, sorry for the delay, I did not get a notification about your comment.

Replacing ugettext by ugettext_lazy in the polls/models.py file did not solve the problem. New migration files are generated anyway when changing settings.LANGUAGE_CODE.

[Claude Paroz]

Martin, could you then update your sample project to use ugettext_lazy?

[Martin Bächtold]

Claude, I was somewhat rash with my previous statement. I created the demo project from scratch (locally only, not pushed to GitHub) using ugettext_lazy and I could not reproduce the error. I assume this ticket can be closed. Thanks for your help!