@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.
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.
legostormtroopr|4 years ago
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.
Grollicus|4 years ago
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.
andrewingram|4 years ago