ugettext, ugettext_lazy or _ in model field

[vaneck.marcel@…]

As soon as someone uses internalization tools for Django. They may use ugettext, ugettext_lazy or a shortcut (like _).

The model field is defined as below:

foo = models.CharField?(_("Foo"), max_length=100)

This will give problems with South as the field in the migration file is defined as:

db.add_column('people_people', 'foo', models.CharField?(_("Foo"), max_length=100))

The function '_' is not defined for this field. In this particular situation it is easily fixed by added the proper include to the migration program (i.e. "from django.utils.translation import ugettext_lazy as _").

As the translation of the field description is irrelevant for South, I imagine two fixes for this issue:

1. Strip out any functions surrounding the field description (is the field description necessary for the build anyways?).
2. Auto include all the imports for the corresponding model file (seems like a nasty hack).

[vaneck.marcel@…]

I tried removing the field description in the migration program and that seems to work alright.

db.add_column('people_people', 'foo', models.CharField?(_("Foo"), max_length=100))

becomes:

db.add_column('people_people', 'foo', models.CharField?(max_length=100))

and there is no need for importing the ugettext_lazy as _ for South to work correctly.

[andrew]

The problem here is that we can't just remove the first positional argument willy-nilly, since we have custom fields to deal with. The cleaner solution is to strip out '_()' in the models parser (where we can see the tree) - I'll have a go at that at some point.

[esau@…]

Same issue if you use the named argument verbose_name.

I think the best way to fix this would be to use a convention, for instance import ugettext, ugettext_laxy and _ (from django.utils.translation import ugettext_lazy as _) for every migration if USE_I18N = True in settings.

[andrew]

Perhaps, although that's rather ugly (in fact, all that needs to be imported is _, since the others would come in with the "from foo.models imoport *" - _ is the only name that cannot come in via this method, as it is special.

I might try and see if I can inject it into the module's namespace in code - that would remove the need for an extra line.

[andrew]

Well, that was a sudden brainwave! +1 for Python letting you modify module contents willy-nilly, and it's fixed in [192].