i'll be testing it tonight :)
On Jan 26, 2:39 am, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> 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 athttp://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
-~----------~----~----~----~------~----~------~--~---
