Add translation fields to base class when multi-table inheritance is used about django-modeltranslation HOT 10 CLOSED

From eschler on October 01, 2010 08:41:15
Inherited classes are supported by modeltranslation and in fact we make heavy use of them.

As you haven't included your model definition and your modeltranslation related settings, i can only guess that you have registered B.title for translation after your initial run of syncdb. In this case you have to add title_is (and title_en) manually to your database. Or in case the tables don't hold any data, you can also just drop them and run syncdb again.

from django-modeltranslation.

From [email protected] on October 01, 2010 11:57:31
Hi, thanks for the quick reply.
Sorry, I had registered the base class and not the sub class.

What is wrong with it though (conceptually) is that the translated fields title_is and title_en are created in the database table for the subclass but not in the base class table. This means that if I want to make a function in the base class that queries those fields, I can't and have to make the function in all the subclasses slightly different.

This bit me now when I had a field called tags in the base class, with field type TagField (provided by the django-tagging application, basically just a CharField).

I wanted to make a function to retrieve the original string as input by the user, since the TagField returns an ordered, comma-less version of the users input.

So I'd like to do it like this:
from django.utils.translation import get_language
def get_tags(self):
retval = u""
try:
from django.db import connection, transaction
cursor = connection.cursor()
cursor.execute("SELECT tags_%s FROM A WHERE id = %d" % (get_language(), self.pk))
row = cursor.fetchone()
retval = row[0]
except Exception, inst:
pass
finally:
return retval.rstrip(u" ,")

But that won't work because the translated field is in the sub class even if the original field is in the base class.
As a result I have to make slightly different versions of this function in all of the sub classes.

Is this something you're willing to change? As it is now it seems conceptually wrong.

from django-modeltranslation.

From [email protected] on October 01, 2010 12:17:37
By the way, I found a workaround for this particular problem:
def get_efnisord(self):
retval = u""
try:
from django.db import connection, transaction
cursor = connection.cursor()
cursor.execute("SELECT tags_%s FROM %s WHERE A_ptr_id = %d" % (get_language(), self._meta.db_table, self.pk))
row = cursor.fetchone()
retval = row[0]
except Exception, inst:
pass
finally:
return retval.rstrip(u" ,")

But this does feel a bit hackish and I still think that conceptually the translated fields should be stored in the table of the model they belong to.

from django-modeltranslation.

From eschler on October 01, 2010 12:39:06
Thanks for the clarification. I get your point now and it's a valid one. Most of the inherited models i had used with modeltranslation were abstract ones so i've never run into this problem.

The problem you describe occurs with multi-table inheritance and has indeed to be fixed. In the essence modeltranslation has to distinct between abstract and multi-table inheritance.

from django-modeltranslation.

From [email protected] on June 01, 2011 14:09:36
Hi,
I came up with a patch you'll find on github: hyperweek/django-modeltranslation@08b5603
Feel free to test/merge it.

from django-modeltranslation.

From eschler on June 01, 2011 15:05:38
Very nice. The patch looks good to me. Tests run fine. I'd be glad to include it in the 0.3 release. Thanks alot for your help!

from django-modeltranslation.

From eschler on June 01, 2011 15:27:41
Resolved in r111.

from django-modeltranslation.

From eschler on June 16, 2011 13:56:03
@sebastian
I found a problem with the admin integration. When you have localized fields in both, the parent class and the subclass and both are registered for translation, only the subclass is handled properly. The original field of the parent class isn't hidden and the modeltranslation specific css classes aren't applied, so jquery-ui-tabs don't work either. Do you see a good way of keeping track of the related fieldnames in translation options? We can't rely on the KeyError in this case, as both models are registered.

from django-modeltranslation.

From eschler on December 07, 2011 12:16:20
Reopened due to problems mentioned in comment 10.

from django-modeltranslation.

Resolved by pull request #137.

from django-modeltranslation.