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 https://github.com/edoburu/django-parler/issues/38#issuecomment-61479911
• 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.