Why doesn't the framework provide support for translated database content?

[Bernhard Posselt]

Hi guys,

I'm running a "hobby" website with translations for roughly 83 languages
and I've taken a thorough look at the available options (as in: Django
apps):

* django-modeltranslation: probably a bad idea to create 83 columns for
each translated string

* django-hvad: never got this to work

* django-parler: basically dead, the test suite does not pass on 1.10
and 1.11 and the dev mentioned that he has no time to fix it

I've settled on django-parler at the time because it worked pretty well.
I know you want to outsource as many features as possible (so do I for
my personal projects) but the downside of that is that 3rdparty apps
that you rely on can die off pretty quickly and then you're stuck.

In this specific case I'm kinda wondering why translation is built into
Django with the exception of models. Other frameworks ship this stuff
out of the box. I know that there are different ways to implement but I
can only think of 2:

* put everything into one table

* put everything into a translations table and join the required language

So why is there no (configurable), built in support for this seemingly
basic feature?

[James Bennett]

Because even if you collapse the number of approaches to just two general options, there's still enough variability in the specifics of how to implement those options that there's no clear "one size fits all" solution at the moment. If there ever is one, it can be considered for inclusion in Django, but right now there just isn't.

[Bernhard Posselt]

Why not build in the most common approach while still allowing people to
override it like they do know? They could simply swap out the default
manager right?

[James Bennett]

Generally, I'd like to see something satisfying the needs of around 80% of use cases out of the box before including it directly in Django. No database-translation tool I'm aware of is even close to that level.

[Bernhard Posselt]

The question is how we guess that it fits 80% of all use cases :) IMHO
80% are covered with the two approaches that I listed in the first mail.

I mean you reach the limits of the ORM pretty quickly as well but you
can always drop down to raw Sql and circumvent the built in API restrictions

[James Bennett]

80% covered by two approaches that aren't really compatible with each other doesn't get there :)

Again: to get into Django, something really needs to be as close as possible to "one size fits all", not "one size fits some, another size fits some more".

[Raphael Michel]

Hi Bernhard,

fyi: a similar topic was recently discussed here[0].

My point of view:

I recently counted 19 packages for this purpose, six of them being
actively maintained. You already mentioned that there are two ways that
you can design the database layout (I argue there are three, but thats
nitpicky), but there are also multiple ways to design the Python-side
API.

And here's the point: For each and every of the available options,
there are really big disadvantages.

The JOIN approach is the cleanest database-wise but has its own
problems, for example it gets really messy when you want to deal with
multiple languages at the same time. Also, no implementation managed to
implement that without massively limiting the overall power of the ORM.

The "many columns" approach is bad, because it requires migrations
every time you want to change the supported languages and because it
might lead to very large data sets returned by the database -- but its
easier to work with multiple languages at the same time.

There are also two implementations (django-nece and django-i18nfield)
using a JSON-based approach which mixes some of the problems and
features of the other two approaches, but you give up some lookup or
filterting functionality.

There is absolutely no one-size-fits-all solution here in sight, not
even a works-for-90%-of-people soltion. That makes it really hard to
argue for one of them to be included in Django.

On DjangoCon Europe this year, I gave a talk comparing the six
maintained packages [1]. In an email earlier on this list [2] you can
find a very short summary of that. Unfortunately, the videos of
this conferences are not yet online. You can find my slides at [3],
although the Slides mostly contain the mere facts, and not the opinions
expressed in the talk ;)

Cheers
Raphael

[0]
https://groups.google.com/d/msg/django-developers/6a5Bwf5KMNA/HBj-S8ypBgAJ
[1]
https://2017.djangocon.eu/schedule/data-internationalization-in-django/
[2]
https://groups.google.com/d/msg/django-developers/6a5Bwf5KMNA/4q7HNXysBgAJ
[3] https://speakerdeck.com/raphaelm/data-internationalization-in-django