Magesh Ravi
Artist | Techie | Entrepreneur
I am currently working on a Django project using Thamizh as the default language. The application has three layers,
Our current work involves adding the English language. In addition to translating the user interface, we have to translate user-submitted values in the database into English through an API or manual work.
After examining the use cases, existing data and translations (both inline and block), we had two options.
Plan A: Two VueJS apps, two Django apps and two databases - one for each language.
Plan B: One VueJS app and one Django app - relying on the route to detect the preferred language. Two databases - one for each language.
After much debate, we leaned towards Plan B. It looks very tempting - requiring less effort and a leaner architecture. Why duplicate everything when Django supports multiple databases with the same models out of the box?
We know. Django did not implement the multiple databases feature for this use case. It's written for a master-slave setup, where the default connection is for the master database.
Yet, our solution (plan B) looks very promising, at least on paper.
We made good progress,
The admin site located at /admin/
displayed records from the existing Thamizh database. The new admin site located at /en-admin/
displayed records from the new English database.
Then, we hit a roadblock when editing an inline model with a one-to-one field. The problem is - Django always used the default database connection when validating unique constraints on the models.
After a few hours of debugging and searching for solutions, we found this to be a bug that has been open for twelve years now.
https://code.djangoproject.com/ticket/15130
So, if you get creative about using Django with multiple databases, be mindful of this issue and its effect on your project.