Hi,
I had some time to work on the library today. Man, am I learning
about Django :)
So far everything seems to be working out nicely. Changes made since
the previous version:
Translations are cached now and only saved when the master object is.
This makes them behave more like real fields now.
All the data for an object with translatable fields is being read in a
single row using left joins, as Aidas suggested, so ordering and
filtering should not be that difficult after all. There is a problem
with admin views, as they only allow sorting by fields. I am not sure
yet, but perhaps 'proxy fields' for the translatable content would be
a good idea here. They would behave much like normal fields but use
the objects in translation cache to store and retrieve values. This
would also make it easier to use the automatic change views.
The library installs a custom manager in the master model, so you can
not set your own manager now. I think it would be a better idea to
use a wrapper around the manager provided by the developer (or
django.db.models.Manager by default).
The more I work on this the more I doubt that the 'different columns'
backend will be necessary. It would potentially mean a bit faster
read and much faster save operations, but in practice the vast
majority of operations are reads. It would be cool to check the
actual speed difference in reads, but I will have no time to measure
it before getting the library to work with the current backend. And
finishing the service I need the library for now.
There is still a lot to do:
a) make ordering and filtering work in QuerySet methods (probably by
creating a new QuerySet subclass in MultilingualModelManager), so
that order_by('name') works like order_by('name_en') or
order_by('name_pl') depending on the default language; same goes
for filter(name__like='asd') and similar operations,
b) make ordering and filtering work in admin (if done properly,
perhaps with the proxy fields, it might make fix the previous issue
as well),
c) make it possible to request a QuerySet yielding objects with a
specified default language,
d) make admin change views work (they work reliably only for objects
created via the admin interface),
e) make it possible to use custom managers in translatable models
again by using a manager wrapper,
f) clean up: move the language list to settings and move most of the
code out of multilanguage.models. Actually the only reason to use
this file is the very last line, that overrides ModelBase.__new__
when Django loads the multilingual application. I would gladly get
rid of this hack, but it will require changing Django to send a
pre_new signal just before ModelBase creates the new class. I will
submit a ticket for it as soon as I have a working patch, but it
has lower priority than the rest.
...and probably more. I could use some help, testing, comments and
ideas now :) The code is at
http://code.google.com/p/django-multilingual/
-mk
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
