Wish: be able to redefine existing fields as translatable

[vdboor]

Based on the reports #38 and #39.

It's not possible to redefine fields as translatable if they also exist on the shared model.

• The official procedure is adding the translatable fields, and then removing the fields from the shared model.
• When overriding third-party models currently requires using different names for those fields (e.g. django-oscar, see https://gist.github.com/vdboor/46348490c7cd1a5b08f4).

The following could be improved:

• Add detection that a field is being overwritten. Requires refactoring the metaclass, see "Adding translated fields to an existing model" in docs needs clarification #38 (comment)
• Remove an existing field from the model Meta, implement an inverse of django.db.model.Options.add_field().
• It makes sense to make the overriding explicit, e.g. title = TranslatedField(redefine_field=True)

[skirsdeda]

Any news on this?
Currently I am searching for a solution how to translate django-filer fields (reusing existing fields) and I have 2 options:
a) use a metaclass hack in #38 and create custom models for all models I need, then override a bunch of admin stuff, etc.
b) fork django-filer, make everything translatable by default and hope that I end up with something pull-request worthy :)
What would be your recommendations in this case?

[vdboor]

Nope, I haven't looked deeper into this. It's a very hard topic, because removing a fields is not supported by Django at all. For third party apps, this would also break any ORM .filter(..) call on those removed fields.

Currently there is a discussion about overriding abstract-model fields on the django-developers mailinglist, which also raises interesting points.

As for recommendations, you can go either way. My personal favorite would be persuading the django-filer author if he has interest in receiving multilingual support for his application. Since you're willing to do the work, this has a higher chance of getting accepted.