Model translations (was: Improve category handling: request for feedback)

[Maik Hoepfel]

Hey BugSpencer,

why do you think django-parler would require more forking than modeltranslation? 

I'm interested, because we like it's approach and have been considering recommending it as the go-to solution. But haven't had a project to try it out in person yet.

Regards,

Maik

On Mon, Feb 23, 2015 at 9:27 AM, BugSpencer <luca...@gmail.com> wrote:

Il giorno sabato 21 febbraio 2015 03:26:01 UTC+1, Valery Sorokin ha scritto:

 

# Translations

The easiest way to manage translations seems to install
modeltranslation app. Drawback - no control of how to display
translatable fields. It's not possible to display all localized fields
at the same time.

Just a note here: it is definitely possible to display multiple translation fields automatically in forms
with django-modeltranslation: you have to make apps.dashboard.catalogue.forms.BaseCategoryForm
subclass one of their mixins, or maybe just manually add "name_en", "name_de", "name_<whatever>"
to Meta.fields.

Anyway, I agree on modeltranslation being the easiest package to integrate translation into Oscar,
since hvad/parler-like approach will require to fork more and more parts of Oscar to make it work.

[That said I like the translations-in-a-separate-table approach more, and it would be great to have
it directly in Oscar core, but I think it will never happen, since at least having translations or not is
domain-specific, and this is not the right place to discuss about it]

--
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/d6f6d75b-508b-487f-af6f-648e7ae8799c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Paul Walsh]

I've used modeltranslation and hvad before.

 

At one point, I even tried out moving off modeltranslation to hvad, because of the whole thing with the data being denormalized and potentially having big rows of data if there are many translations.

However, I moved back to modeltranslation in that case **due** to the ease of use (for development and for users in admin) and the efficiency of not doing joins for translated data. 

[Maik Hoepfel]

Paul,

thanks for taking the time to explain. I really need to have a proper look at it again. I wonder what kind of real-world performance hit one would see.

Regards,

Maik

To view this discussion on the web, visit https://groups.google.com/d/msgid/django-oscar/69532e5c-db98-40c4-b623-2946e000a13f%40googlegroups.com.

[Valery Sorokin]

I have compared single-table approach with hvad-like (ca 100000
product, ca 1000 categories, MySQL db) some time ago. I've got no
metrics but single-table was faster.

I agree with Paul that hvad will bring extra level of complexity.

I suggest to consider also a simple MultilingualCharField
implementation that adds language specific fields to model based on
the LANGUAGES setting.

https://gist.github.com/valsor/0a722b422a08727794ce

This aproach is very simple, lightweight, fast (join free), flexible
and brings no extra dependency.

> https://groups.google.com/d/msgid/django-oscar/CALA313_daC%3DhS7yAULDDwnpD3g%3D8OF2YREq8EQOddFY1h4i_fg%40mail.gmail.com.

[Paul Walsh]

Valery, good to hear that you’ve seen similar issues that I have.

Your multilingual char field, in essence is pretty much how modeltranslation works.

I think modeltranslation’s approach of registering translations is a nicer way to do it: all translation code is explicitly declared in a translations module per app, so developer/users just write models as normal.

I’ll emphasise again it is not just an issue of performance. I found the following wins with modeltranslation's each to be critical:

* query performance

* ease of development (writing code without having to be aware of multilingual query managers etc.)

* ease of use in admin

On all of these modeltranslations wins hands down IMHO. The only issue I encountered was resistance (in *myself*, initially, and in others) to the fact that the approach is not “SQL like”, meaning, our own internal bias to do this relationally because we are using a relation database.

You received this message because you are subscribed to a topic in the Google Groups "django-oscar" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-oscar/8F7FSLvomHQ/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAP0Q62mFeBAHh849z4EKHGdQBqCg3wFO7PGvMPJQwzEGdHfkLg%40mail.gmail.com.

[BugSpencer]

Hi, sorry for getting late to this discussion.

Il giorno venerdì 27 febbraio 2015 13:57:23 UTC+1, Paul Walsh ha scritto:

Hey BugSpencer,

why do you think django-parler would require more forking than
modeltranslation?

I'm interested, because we like it's approach and have been considering
recommending it as the go-to solution. But haven't had a project to try it

out in person yet.

I'm not an expert here, but I've been using modeltranslations lately, and it's very easy to use

(at least considering basic usage): just register the model in translation.py and you get

translated fields without editing models.

The bad thing is that now you need migrations, and that's why I would like to use hvad/parler:

avoid a migration for every change to LANGUAGES.

Due to this "problem" I tried switching my project to both hvad and parler, but they require

you to define translated fields directly in models, so if you want to translate product title,

you have to override "title" attribute in Product class but you cannot do this using

AbstractProduct, so you are forced to copy whole Product model over to your project,

and do this for all models that need to be translated.

This is quite annoying as a "standard" way to add a translation.

Moreover, since most of oscar codebase is not translation-aware, and hvad/parler don't load

translations by default in querysets, you can either:

- fork/override each line of code that references translated field and ensure translations

  have been loaded (this is the main "more and more" i was talking about)

- override at least default manager for every translated model (less tedious, but a potentially

  huge performance hit)

To be honest I'm not 100% sure about what I wrote, maybe there's a way to make a field

translatable with hvad/parler with same name of regular field, and I just didn't find it before

getting tired, since modeltranslation was already working for me, and I had other topics to

address before going any further.

Dealing with forms/admin is quite similar for both approaches , some hassle is required,

but definitely quite easy for both (at least for basic operations, attribute values is not one

of them).

In the end if you plan to include some multilingual support in Oscar, I think using hvad/parler

is better along with putting some translation-loading logic into oscar core for basic performance

management. On the other hand if you only want to give some advice on translating a project

based on oscar, i think modeltranslation is easier to use (manage.py oscar_fork_app, write

translations.py).

Hope it helps.

[BugSpencer]

Il giorno domenica 1 marzo 2015 23:43:30 UTC+1, BugSpencer ha scritto:

To be honest I'm not 100% sure about what I wrote, maybe there's a way to make a field

translatable with hvad/parler with same name of regular field, and I just didn't find it before

getting tired, since modeltranslation was already working for me, and I had other topics to

address before going any further.

I forgot to mention that django-parler documentation is quite clear about making an existing
field translatable: you cannot do that "easily" (http://django-parler.readthedocs.org/en/latest/advanced/existing.html#overwriting-existing-untranslated-fields)
and the recommended way to do that involves 3 migrations for each field
- add translated field with same name (browsing site now results in runtime errors)
- write a data migration to port "legacy" data into new translation table
- remove old untraslated field
as documented here: http://django-parler.readthedocs.org/en/latest/advanced/migrating.html