@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.