So if I have an application that is only going to be translated into a
couple of languages, it's still going to create 100 columns in the
database when Django's settings contains 100 locales? That's not very
nice.
This plan also means that every single time we add a new language to,
e.g, Django, or some open source application accepts a new translation,
you need to alter the database. You're basically denormalising the
database here in a very explicit fashion. It's exactly equivalent to
trying to store an array in the database by enumerating all the columns
and these sorts of problems are the reason that isn't a good idea. The
one-many approach used by the current packages at the database level is
a lot more maintainable in this respect.
Regards,
Malcolm
This shouldn't be necessary. You're imposing too high a burden on the
users. Whilst you are obviously comfortable using this for yourself,
it's not an approach that should be incorporated into Django. We like to
use the "relational" part of relational databases.
Your situation immediately runs into problems with any distributed
application. Person A releases Rocket-Powered-App-1.0 and Person B
installs it and wants to use it in their website that supports 5
languages. Now they have to alter some of the models of
Rocket-Powered-App to install four or five extra columns, which
completely cuts across the ability to use unaltered upstream code and
synchronise with the released version from time to time. Databases are
*designed* to store multi-valued content in related tables. Ignoring
that feature is saying you don't want to use a relational database. You
might as well store your content in flat files.
Regards,
Malcolm