We built Django-Garnett at Aristotle Metadata because we had a monolithic Django app and wanted to backport multilingual support for our clients in, without having to change references to fields in our templates and code in potentially thousands of places.
It allows clients to add and remove languages on-the-fly and means app developers only have to add a middleware and don’t have to change their Django ORM code very much at all.
We’re going to do a big engineering post on it, but in a huge code base, apart from the effort of building this library, and some UX design for the language switcher, it was a relatively painless process converting a monolingual app into a multilingual one.
They seem to store all translated strings in a single jsonfield instead of using a separate column for each language.
That means there's a bit more overhead while loading (and you can't exclude unneeded language fields), but it allows dynamically changing languages during runtime without needing a migration.
With Django's ORM and PostgreSQL, it is possible to map specific keys of a JSONField to an annotation. But I don't know if the overhead of doing this would undo the gains from not sending data for every language in the query result.
@Grollicus covered most of the major points (which means the documentation must be part good). For this library is was that we didn't want to have to add additional columns and change table structure if a user wanted needed to add more languages on in future. Also because we provide our software as separate managed instances, this would have also meant that every system would have had a different database schema - which would have been a nightmare for maintainance.
Other libraries had other similar contraints - such as languages stored in external tables, or needing special querysets to access languages.
Garnett was designed to be an (almost) seemless drop-in that fit into the Django ORM without altering code or data too much.
I am currently in the same boat as you were and this looks fascinating. I was dreading having to migrate all of my CharFields to JSONField to support languages. I look forward to integrating this with i18next handling the frontend.
Without testing, I'd say yes. Anything that can be safely stored in a JSONField can be stored in a string in garnett. But I can test and add some examples.
10 comments
[ 2.9 ms ] story [ 39.3 ms ] threadIt allows clients to add and remove languages on-the-fly and means app developers only have to add a middleware and don’t have to change their Django ORM code very much at all.
We’re going to do a big engineering post on it, but in a huge code base, apart from the effort of building this library, and some UX design for the language switcher, it was a relatively painless process converting a monolingual app into a multilingual one.
We have a fun demo site that shows it in action here: https://django-garnett.herokuapp.com/
That means there's a bit more overhead while loading (and you can't exclude unneeded language fields), but it allows dynamically changing languages during runtime without needing a migration.
Other libraries had other similar contraints - such as languages stored in external tables, or needing special querysets to access languages.
Garnett was designed to be an (almost) seemless drop-in that fit into the Django ORM without altering code or data too much.