Hi Claude, I spent some time looking at the implementations out there and in one of my projects I'm running a custom one, that uses yet another approach (that I plan to release as a library some day).
It is not only that we are not yet ready to bless one of them, I have a feeling that we never will, as they are incredibly different from each other. django-parler, django-hvad and django-model-i18n use seperate tables to store the data, which is cleaner from a database point of view but requires more JOINs. The former two use custom model base classes, the latter uses a registration-based approach. django-model-translation uses seperate columns for the different languages, thus working with a "static" set of languages and requiring a migration if you add translation capabilities or change the set of languages. On the other hand, it saves you a lot of JOIN queries. It uses a registration-based approach to register models with the system. My project uses only a custom field type that stores the translated contents in a JSONField-type thing. This has some downsides with regards to indexing and searching (at least on non-Postgres) and is less clean from the DB side but requires neither migrations for new langages nor any additional JOINs. (And I believe it is very clean on the Django-side as it just requires you to replace a CharField with an I18nCharField, no custom base classes, no registration, etc.). Each of those approaches has severe advantages and disadvantages and more importantly, they are fundamentally different. I don't believe a new meta option would help you in any way, as for some of them you'd probably *still* need a custom model base class. It also would not allow you to easily switch between them or have a reusable app to be compatible with multiple of them because it would still be very undefined how you get to the translated versions in the different systems, how you store the data into the field, etc. Cheers Raphael -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20170214145327.6c16263d%40arlen. For more options, visit https://groups.google.com/d/optout.
pgpnFbYwH1Kt8.pgp
Description: Digitale Signatur von OpenPGP
