ProductAttributeValue translation

[BugSpencer]

I'm trying to build a multilingual shop, and so far everything was quite straightforward using django-modeltranslation:

• fork oscar app if not already forked
• register translation options in translation.py
• migrate
• get translated values depending on selected locale, forms with correct additional fields even in dashboard

The only problem I'm facing now is trying to translate product attribute values.

I've added translation option for "text" and "richtext" fields, so i have "text", "text_en", "text_it"...

Everything works ok in /admin/, but not in dashboard.

ProductAttribute fields are "manually" added in ProductForm, but forking dashboard and subclassing that form I managed to show additional fields for text and richtext product attributes.

The problem is in saving and retrieving them, since this is done using "value", which is a single field from DB (*which* field depends on the *type* of the attribute).

What I need to do is passing a list of values for "save()" and then retrieve the same list for initial form data, not a single value.

This approach seems to lead to a rework of product-attribute interface down to model level, which is not something I'd like to do if that's not the only way.

The deeper I delve, the more I'm sure I'm doing this the wrong way...

If I'm not mistaken you guys said that at Tangent you used modeltranslation with oscar, how did you overcome this problem, if you did at all?

Thank you in advance

[David Winterbottom]

​That is true but I don't think we needed to translate the attributes in that project so I can't help much.

It sounds like quite a thorny issue. Would it be easier to use a ​alternative model for your translatable attributes?

 

Thank you in advance

--
https://github.com/tangentlabs/django-oscar
http://django-oscar.readthedocs.org/en/latest/
https://twitter.com/django_oscar
---
You received this message because you are subscribed to the Google Groups "django-oscar" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-oscar...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-oscar.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-oscar/e4c14b9f-f00d-4472-af83-a23be262d8db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

David Winterbottom
Technical Director

Tangent Snowball
84-86 Great Portland Street
London W1W 7NR
England, UK

[Maik Hoepfel]

Hi,

> The problem is in saving and retrieving them, since this is done
> using "value", which is a single field from DB (*which* field
> depends on the *type* of the attribute).
> What I need to do is passing a list of values for "save()" and then
> retrieve the same list for initial form data, not a single value.
>
> This approach seems to lead to a rework of product-attribute
> interface down to model level, which is not something I'd like to do
> if that's not the only way.
>
> The deeper I delve, the more I'm sure I'm doing this the wrong way...
> If I'm not mistaken you guys said that at Tangent you used
> modeltranslation with oscar, how did you overcome this problem, if
> you did at all?
>
>
> ​That is true but I don't think we needed to translate the attributes in
> that project so I can't help much.
>
> It sounds like quite a thorny issue. Would it be easier to use a ​
> alternative model for your translatable attributes?

Yeah, I'm not aware of any project that had to translate product
attributes yet. Could one overwrite the "value" getter and setters on
ProductAttributeValue accordingly? value is just a property that returns
the value of whatever field is specified as type.

Another (non-ideal) option would be to turn your product attributes into
custom fields on your products.

Please report back with whatever you find. We have an interest in making
model translation work well.

Cheers,

Maik

[BugSpencer]

First of all, thanks for replies ;)

Bad news: I didn't find a good solution to the problem so far

Good news: there's a "nice" workaround directly from django-modeltranslation

My initial goal was to have every translation field for every language available in dashboard at the same time,

and then use tabs/panes to switch between widgets (if not the page would grow too much with many languages).

If you are ok with leaving this behind, and don't find switching language many times too much frustrating,

everything works "out of the box": if you keep only one translation field at a time (the one that's tied to session language)

and subclass your modelforms using TranslationModelForm everything just works, and saving a product attribute while

under IT locale, will save it in italian, while saving it under EN locale will save it in the other field.

This is definitely NOT the best solution, but requires very little effort and works, even with product attributes.

Some bits of code:

myapp.catalogue.translation.py:

from modeltranslation.translator import translator, TranslationOptions

from .models import Product, Category, ProductAttribute, ProductAttributeValue

 

class ProductTranslationOptions(TranslationOptions):

    fields = ('description',)

 

class CategoryTranslationOptions(TranslationOptions):

    fields = ('description',)

 

class ProductAttributeTranslationOptions(TranslationOptions):

    fields = ('name',)

 

class ProductAttributeValueTranslationOptions(TranslationOptions):

    fields = ('value_text', 'value_richtext')

 

translator.register(Product, ProductTranslationOptions)

translator.register(Category, CategoryTranslationOptions)

translator.register(ProductAttribute, ProductAttributeTranslationOptions)

translator.register(ProductAttributeValue, ProductAttributeValueTranslationOptions)

myapp.dashboard.catalogue.forms.py:

from modeltranslation.forms import TranslationModelForm

from oscar.apps.dashboard.catalogue.forms import *

class ProductForm(TranslationModelForm, ProductForm):

    pass

This is all it takes to have some catalogue fields translatable (both in admin and in dashboard).

If you don't subclass ProductForm everything  is translated except product attributes

(and possibly whatever model has a custom "save()" ), but you have additional fields for every language defined.

Again, this solution is far from optimal, but at least it works and it's very easy.

As soon as I will have some spare time I'll try to get simultaneous translation to work for attributes.

PS: with this approach, a language selector in dashboard is mandatory, or you'll go crazy quite soon ;-)