Re: High Level Discussion about the Future of Django
Thanks for opening this discussion. Am I only one who see the django improvement process too slow? I mean refactoring, decoupling and making code more reusable in the time when we realize that previous design has too much constraints and there should be better design now. I know there's django deprecation policy nicely documented http://docs.djangoproject.com/en/1.1/internals/release-process/#internal-release-deprecation-policy But what I don't know is how you discover it. Is it described somewhere in the text or the video from conference? What were the reasons to have this deprecation policy? Was there any user research? Research of when the django users upgrade, what are the main problems of upgrades and how they imagine upgrading should work? I saw in the discussion in this thread http://groups.google.cz/group/django-developers/browse_thread/thread/a89935f2f9f9102b that Russell wrote: "Put it this way - If part of your migration plan involves every one user of Django carefully reading the and following the upgrade instructions, then I want your home phone number so I can give it to everyone that contacts me personally complaining about their broken Django installs. And be warned -- I'm in a timezone that guarantees you will be called at three in the morning. :-)" I think this problem could be solved by other ways than setting the strong deprecation policy. (Eg. more visible of release changes, not providing support for free or get out the "unaware" users out of the community just by the "faster" upgrade policy). What I try to say is that I'm little bit afraid that it seems like improvements of django will take years instead of months. In the time when Rails 3 is coming it looks like the next killer framework in terms of easy-to-use and also power and extendability. The django core devs are doing great job but it's sure there's and still will be a lot of new use cases for django in the various web applications discovered by community. I think this could lead to fork the django by some devs and rapid development of this fork. Maybe then in one moment there would rise the discussion about merging these two and it will take year (as in Merb & Rails case). Is this the best way of development OS? Vaclav On 5 dub, 05:02, orokusaki wrote: > This is a bit abstract, but I'd like to bring up this idea, and > firstly let me say that I don't intend to waste the time of the major > contributors (unless you want to join in of course). I mostly want to > get an idea of what some of the contributors/feature proposers out > there are thinking of, in a sort of fly by the seat of your pants way. > > Through reading some of the ideas/problems on this group (including my > own) I've noticed that some tend to be A) too far in the future, B) > too abstract, C) (very important) Backwards incompatible, D) (very > important) Too much architecture changes. The discussions tend to turn > from macro to micro very quickly because of some of the existing > constraints. > > 2 thoughts came to mind: > > 1) What if every major element could be re-factored for better > extensibility (and perhaps speed as well) without regard for the > backwards compatibility. > 2) Imagine the progress that could be made if the existing code base > was able to be re-factored in one week (impossible of course, but > hypothetically speaking), knowing everything that the developers know > now. > > I know neither of those is possible at the moment, but take those two > ideas (rules) in mind, and talk about what you'd add / change / make > better / etc. > > Perhaps this is way more 2.0 than even 1.3, but I wanted to get a very > early look through foggy goggles into the future so that I can come up > with ideas. I've been bombarding Russell K M with questions, thoughts, > etc that are just very poorly timed with 1.2 Beta and all, and I want > to step back and really prepare for next time. > > 2 related questions for anyone who cares to answer: > > 1) Is anything allowed to become non-backwards compatible during a .x > release? (ie, from 1.2 to 1.3 or 1.4) > 2) When will 2.0 development begin? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Suggestion: DictionaryField
Hi, I must correct my post. When I used "default" option I mean "choices" option. On 18 led, 22:23, Михаил Лукин wrote: > There is no need in ENUM functionality since 'choices=' option exists. I must disagree with you. It looks like choices emulate ENUM but it's not true. What's not supported: - model validating: no other values except that in choices are valid - support for binary representation of values and binary matching in ORM queries For SETs there's another condition: - unique values in SETs Vaclav > Representing ENUM and SET as input fields even with autocompletion may be > confusing in multi-language applications. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Suggestion: DictionaryField
Hi, for me it has a big WTF factor. Automatically created tables according to field. As DirectoryField I would suppose behaviour like SET or ENUM fields in MySQL. I hope there are equivalents in other DB storages. Implementation of this types I would appreciate in Django ORM. This doesn't need to be even new field. It will be sufficient to have implemented those use cases for present field types which gets default values as dictionary or tuple of tuples. - validating: no other values except set in defaults are valid - unique values in SETs - support for binary representation of values and binary matching in ORM queries Vaclav On 17 led, 00:02, Mihail Lukin wrote: > Hi, Community > > Sometimes an application model include a lot of fields which are just > dictionary values. Example: > > class HDD(models.Model): > form_factor = models.ForeignKey(HDDFF) > capacity = models.ForeignKey(HDDCap) > interface = models.ForeignKey(HDDIntf) > ... > > and so on, where HDDFF, HDDCap and HDDIntf are similar classes. > Abstract class with only one field "name" may be used, so that this > classes could be defined like this: > > class HDDFF(DictModel): pass > > but it is not as good as something like this: > > class HDD(models.Model): > form_factor = models.DictionaryField() > capacity = models.DictionaryField() > interface = models.DictionaryField() > > Database tables "hdd_form_factor_dict", "hdd_capacity_dict" and so on > could be created automatically, just like it is done by > ManyToManyField. > > What do you think about that? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Add querystring helper methods to Page class
Hi,
I need similar functionality so I develop custom tag "qs" wich is not
tight to paginator (I don't know if it is better or not)
Used that way:
params ... dictionary with query string parameters which was prepared
in view
p ... any amount of other query string parameters as key=value you
want to set directly in template
For filtering query string parameters in views for using them as
parameters in ORM, redirects etc I use function "dict_pass()" with
this pattern:
search_params = ('a_day', 'a_month', 'd_day', 'd_month',
'guest_count', 'bedrooms', 'p', 'o', 'ot', 'short') #allowed params
params = dict_pass(request.GET, search_params, updated_params)
It returns dictionary of parameters of "request.GET" updated from
"updated_params" and filtered to have only allowed params here as
"search_params".
I think Django as a web framework could have an object oriented
representation of URI in core to simplify the work with url. It should
be easy to set, update and get the whole url as a string and also url
parts (host, port, path, etc.) and query string parameters in some
clever way without bunch of conditions in application code needed. And
also maybe help with proper escaping of urls with not ascii chars to
render them in templates.
Some inspiration from other web frameworks:
http://api.nettephp.com/0.9/Nette-Web/Uri.html
http://corelib.rubyonrails.org/classes/URI/Generic.html
http://framework.zend.com/manual/en/zend.uri.html
I think also get_absolute_url proposal and future url routing
enhancements could benefit from it.
Cheers,
Vaclav
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: why last_login in django.contrib.auth.models.User cannot be null?
I already created ticket for this http://code.djangoproject.com/ticket/7220 veena On 14 pro, 23:59, Sergiy Kuzmenko wrote: > I wonder if there is a particular reason why last_login field of is not > defined as "null=True"? It makes sense to me to have it as null which would > mean that the user never logged in. Could there be any dependencies relying > on this field not being null? > > Thanks > Sergiy -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: 1.2 Feature Suggestion
Does the commentators have experience with maintaining the i18n django project? I do and completely agree with Jonas. "Gettext like+Rosetta like" but database driven translation app in Django adminwithout translation-makemessages-compilemessages-restart apache would be helpful. Import from the gettext file (managed by your standard tool) to db could be also provided. Vaclav On Oct 23, 6:13 pm, Simon Willison wrote: > On Oct 23, 3:30 pm, Jonas Obrist wrote: > > > Oh... Well than consider this a 1.X suggestion. I've tried Rosetta > > however it just doesn't seem to work Also I don't really like to use > > 3rd Party apps for what I'd consider core functionality. I mean django > > boasts with having excellent i18n capabilities, but when it comes to > > actually translating stuff it just refers to a 3rd party app > > My understanding is that translation tools are actually quite a > controversial issue within the translation community. Most translators > work on more than just one piece of software - they might help out > translating Django, Firefox, Emacs and a bunch of other stuff. As > such, they generally have their own standard tool that they work > within for managing all of their translation activity. A Django- > specific tool wouldn't actually help them at all, since they wouldn't > be able to use it for the other translation work that they do. > > As such, I don't think a single translation management tool should > ever be shipped as part of Django. It's too sticky a problem, and > hence is definitely best addressed by third party modules such as > Rosetta. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
Today I was on very bad wifi connection. Constantly dropped. 20 seconds to load a page. I save in admin in two tabs and got a notice in one tab from the other tab. But I agree, I defer this "bug" for the first release od django messaging. I think django isn't now in right mood to add there some functionality like adding of query parameters to response object by some application. Maybe in future. Vaclav On Sep 23, 4:49 am, Tobias McNulty wrote: > On Tue, Sep 22, 2009 at 9:51 PM, Russell Keith-Magee > > wrote: > > In reality, I get a ping time closer to 300 ms. And that's to a > > high-end data center under ideal conditions - it can be much larger if > > I'm dealing with low end providers. > > What?? 200 ms is the average quoted by Mr. Sproutcore himself! > > No, in all seriousness, my apologies for making such a broad generalization > about packet latency. I could/should have said 500 ms or even a second; the > argument and corresponding solution, if needed, remain the same. > > Anyways..we digress. I am marking this a non-issue in my own head - please > pipe up if there's a case to be made. > > Tobias --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Better HTML4 support
Hi all,
my bits to discussion about supporting various (X)HTML versions.
1) Problem with (X)HTML in python code (in applications)
I discovered this python package http://pypi.python.org/pypi/html/1.6
It allows you to write "python like HTML syntax" and generates HTML or
XHTML.
2) Problem with (X)HTML in templates
I think there should be parser, which parse template just before
caching templates. Code could be messy HTML or (XHTML) or invalid HTML
(like undisclosed tags, attributes without quotations marks etc.) and
from this make pretty HTML or XHTML according to html coder settings
by {% doctype %}
The template post processing also enables to make code nicer indented
or flatten. Or even use as templating language something like REST,
textile etc.
The python packages that could be involved in parsing messy (X)HTML
and I know about them:
http://pypi.python.org/pypi/BeautifulSoup/3.0.7a
http://pypi.python.org/pypi/html5lib/0.10
Best,
Vaclav
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
Hi Tobias, good idea with start a wiki page. I'm not sure if we don't forget one issue. How about same session (or same cookie sent by browser) with simultaneously opened windows of one browser? Then message could appear in different window not the right one where we invoke the event. Is it a problem? Is only possibility to get of this issue that flash app should add a query parameter into redirected url which would identify the right window? Vaclav On Sep 22, 3:08 am, Tobias McNulty wrote: > On Sun, Sep 20, 2009 at 10:24 AM, Russell Keith-Magee < > > freakboy3...@gmail.com> wrote: > > > You also mention that there are a number of other implementations, but > > you haven't really given a compelling survey or analysis of the > > alternatives - you've just blessed one in particular. Why? > > I started a wiki page comparing some of the different options out > there:http://code.djangoproject.com/wiki/SessionMessages > > Feel free to update with (your messaging backend here). > > Tobias --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Looking for a project
Hello, I propose the "universal" Task Queue app similiar to one at Google App Engine http://code.google.com/appengine/docs/python/taskqueue/ Universal means to be able to run it on any hosted server where cron is available. Vaclav --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: I need a pony: Model translations (aka "my proposal")
I think if it'd be possible to have only this syntax:
from django.contrib.translations import translation
translation.register(SomeObj, ['foo'])
Veena
On Aug 4, 9:45 pm, veena wrote:
> Hi David,
> I read your first post now. Then I think it could be great solution if
> it's possible to be implemented.
>
> Perhaps I appreciate less lines in every translation model. If you
> look at:
>
> class SomeObjTranslation(models.Model):
> language = models.CharField(max_length=5, \
> choices=settings.LANGUAGES, \
> default=settings.LANGUAGE_CODE)
> object = models.ForeignKey(SomeObj,
> related_name='translations')
> foo = models.CharField(...)
> class Meta:
> # only one translation per language and object
> unique_together = (('language', 'object'),)
>
> Generaly the only required things you need to set up in each
> translation model are translatable fields and name of model your
> translation is for. The rest is always the same. But even if this
> would be only one disadvantage it's worth to have this implementation
> because of other advantages.
>
> I must say great thinking out of the box and good work anyway!
>
> Veena
>
> On 2 srp, 18:49, David Danier wrote:
>
>
>
> > > I don't research your idea deeply but for first look it seems very
> > > similar or same to django-multilingual.
> > >http://code.google.com/p/django-multilingual/
>
> > From the database perspective it is similar, meaning it uses the same
> > database structure. What I tried to write down was mostly some usage and
> > API ideas to solve some things which pop up when using
> > django-multilingualand others:
> > * Make it possible to use third party apps in i18n environments even if
> > the app was not designed to do this (This idea was stolen from
> > pluggable-model-i18n.)
> > * Don't add to much overhead for db performance and others (One JOIN,
> > nothing more, this JOIN should be transparent to the user. This idea was
> > stolen from model inheritance.)
> > * Support getting results if no translation is available (sometimes you
> > don't need to have a translation, for example if all fields are
> > optional. This is possible in most model translation projects, even if
> > it involves hammering the database with extra queries for each
> > translation there. Conditional JOIN solves this in my proposal.)
>
> > In conclusion I try to use the database structure django-multilingual
> > proposes (which should be the best for the job anyway), keep usage as
> > simple as using model inheritance (keep working with translations as
> > simple as possible) while using a register approach to keep this
> > application independent (thats some kind of killer feature).
>
> > Hope this helps to see the differences here. Perhaps the file I attached
> > helps to see some usage examples.
>
> > One big advantage of my proposal over any existing solution is the
> > possibility to use third party apps without changing their code. I still
> > think this is very important as developers should not need to worry
> > about internationalization when writing third party apps, because you
> > should not need to use some complex database layout if you don't need
> > translations.
>
> > pluggable-model-i18n solves this, too, but it has some
> > limitations/flaws. Using the pluggable-model-i18n you cannot optimize
> > the SQL query when using translations and you run into many choices
> > where to find a value, which are most significant if you want to query
> > your database by some translated field (slug is translated:
> > Book.objects.get(slug=...) vs. Book.objects.get(translation__slug=...,
> > translation__language=...)). This are the two most significant
> > disadvantages, others might appear when using pluggable-model-i18n in a
> > productive environment.
>
> > Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Session namespaces
I think we could think about implementing of session namespaces in similar way as url namespaces was added in Django 1.1 http://docs.djangoproject.com/en/dev/topics/http/urls/#url-namespaces The point is to not populate global namespace of sessions by using session variables in various applications and our own code. I believe it could bring more flexibility for django apps and django itself for many use cases in future. Probably the biggest benefit from that could gain session-based messages aka "flash messages" which are in development for Django 1.2. See http://code.djangoproject.com/ticket/4604 As a part of Django it should be one of the best practices for applications to use namespaces for identify flash messages like: myapp:notice "There's nothing to obstruct us to use it right now," you can mention. But the added value is in adding of session_namespace field to Session model. There as unique_together with session_key it could provide us possibility to have different session_data with different expire_date but with same session_key. Then you can think about something like "Visitor" of your web which could be tight and identify by session. Maybe as a proxy model for Session model(?) Then applications could work with visitor and use their session namespaces and different expiration_date. I could imagine apps like surveys, ratings, polls, votings etc. that they want to identify (anonymous) visitor of page. Work with session namespaces would be better standardized way than polute global space of cookies I think. Perhaps it could be also useful for maybe extending of django.auth application in future. Think about use case where you have split "Identity" and "Authorization" like on LinkedIn or Amazon. You are always identified as a user "First Name, Last Name", but if you want to change something or order something, you must authorized first (by sign in). Probably easiest implementation is to have different session expirations for user identity and authorization. Do you think session namespaces would be useful and should be in Django 1.2 development roadmap? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: I need a pony: Model translations (aka "my proposal")
Hi David,
I read your first post now. Then I think it could be great solution if
it's possible to be implemented.
Perhaps I appreciate less lines in every translation model. If you
look at:
class SomeObjTranslation(models.Model):
language = models.CharField(max_length=5, \
choices=settings.LANGUAGES, \
default=settings.LANGUAGE_CODE)
object = models.ForeignKey(SomeObj,
related_name='translations')
foo = models.CharField(...)
class Meta:
# only one translation per language and object
unique_together = (('language', 'object'),)
Generaly the only required things you need to set up in each
translation model are translatable fields and name of model your
translation is for. The rest is always the same. But even if this
would be only one disadvantage it's worth to have this implementation
because of other advantages.
I must say great thinking out of the box and good work anyway!
Veena
On 2 srp, 18:49, David Danier wrote:
> > I don't research your idea deeply but for first look it seems very
> > similar or same to django-multilingual.
> >http://code.google.com/p/django-multilingual/
>
> From the database perspective it is similar, meaning it uses the same
> database structure. What I tried to write down was mostly some usage and
> API ideas to solve some things which pop up when using
> django-multilingualand others:
> * Make it possible to use third party apps in i18n environments even if
> the app was not designed to do this (This idea was stolen from
> pluggable-model-i18n.)
> * Don't add to much overhead for db performance and others (One JOIN,
> nothing more, this JOIN should be transparent to the user. This idea was
> stolen from model inheritance.)
> * Support getting results if no translation is available (sometimes you
> don't need to have a translation, for example if all fields are
> optional. This is possible in most model translation projects, even if
> it involves hammering the database with extra queries for each
> translation there. Conditional JOIN solves this in my proposal.)
>
> In conclusion I try to use the database structure django-multilingual
> proposes (which should be the best for the job anyway), keep usage as
> simple as using model inheritance (keep working with translations as
> simple as possible) while using a register approach to keep this
> application independent (thats some kind of killer feature).
>
> Hope this helps to see the differences here. Perhaps the file I attached
> helps to see some usage examples.
>
> One big advantage of my proposal over any existing solution is the
> possibility to use third party apps without changing their code. I still
> think this is very important as developers should not need to worry
> about internationalization when writing third party apps, because you
> should not need to use some complex database layout if you don't need
> translations.
>
> pluggable-model-i18n solves this, too, but it has some
> limitations/flaws. Using the pluggable-model-i18n you cannot optimize
> the SQL query when using translations and you run into many choices
> where to find a value, which are most significant if you want to query
> your database by some translated field (slug is translated:
> Book.objects.get(slug=...) vs. Book.objects.get(translation__slug=...,
> translation__language=...)). This are the two most significant
> disadvantages, others might appear when using pluggable-model-i18n in a
> productive environment.
>
> Greetings, David Danier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: I need a pony: Model translations (aka "my proposal")
I don't research your idea deeply but for first look it seems very similar or same to django-multilingual. http://code.google.com/p/django-multilingual/ Veena On 11 čnc, 16:51, David Danier wrote: > Hi Marc, hi Gonzalo, hi django-dev, > > I'm writing this email, because I need some kind of future proof model > translation in django in the near future. I tried many solutions and > came up with two of my own (not released anywhere), but nothing seems to > fit all needs translations might impose. > > So I thought about how model translations in django could work, and how > this should be used by the developer. I send this email directly to > Marc, because he is currently working on some i18n-stuff (GSoC). Gonzalo > seems to be interested in an official solution > (http://groups.google.com/group/django-developers/msg/0be7de2c154aa49d...), > so you might be interested in some discussion about this. Perhaps > Malcolm should be asked about how my proposal fits into the django ORM, > as he has (re)written most of the ORM (-> queryset-refactor). > > I know Django 1.1 is on its way and developers might not have the time > to really thnink about this now, but I needed to write it down. If > someone answers and we can start working on this for post-1.1 would be > great, of course. I, personally, don't need to wait. Anyway, according > to the bugtracker theres not much delaying Django > 1.1:http://code.djangoproject.com/query?status=new&status=assigned&status... > > First to summarize the needs. It has to ... > a) be fast, no heavy database-load should be needed > b) work for third-party apps, as third party apps get unusable if you > need i18n and they don't support it (this also means the existing > third-party code must still work for translated models) > c) be transparent for the user, you shouldn't need to think where your > fields come from > d) support missing translations without skipping the whole database-row, > if you for example JOIN two tables (optional) > e) be searchable through the normal ORM, translated fields should not be > hidden in some serialized format > f) be extendable, new fields shouldn't be a big problem > g) convert existing data without a hassle (like sync_transmeta_db) > h) keep context, if I fetch a german model from the database all > relations should fetch german models, too (default-context should come > from request and/or settings) > i) be optional, not every project needs model translations, this is > especially important for third-party-apps, supporting translations > should not mean you have to use it > j) be generic, different people have different needs > k) support translating central fields (like slug), this goes > hand-in-hand with easy searchability of the translated fields > l) support getting all translations for every object in the database > m) integrate well into the admin > > All existing solutions fail at some of these points, my own two > solutions failed many of these points, too. So first, lets take a look > at what exists: > > 1. Put every translation in extra fields inside one big table: > I'm not a fan of this, tends to get messy, especially for big sites > with many translations. Developers need to think where their fields come > from (Book.objects.filter(title_de=...)). Does not support third party apps. > > 2. Put all fields into its own model, use normal ORM for access. > I you look at this from a database perspective this is the best > solution. But the django ORM does not really support you here. Access to > the fields need an extra query, for every object. Even worse: If you use > some translated fields in your query, you have to do this extra query > anyway (Book.objects.filter(translations__slug='foobar', > translations__language='de'), to get the german translation you have to > execute an extra query, although the JOIN was already done). > > 3. Use serialization to save all fields into one big BLOB. > Do I need to say anything here? Not searchable, no way to really work > with the translations on the DB-layer. > > 4. Special case: Create an own model for translations (like 2), but use > the original table for some kind of DEFAULT_LANGUAGE. (pluggable-model-i18n) > I kind of like this, not only because you are able to enhance > third-party-apps. Independent from that I think translations.register() > seems to be a nice idea. But(!) this complicates things to much. You > have to choose whether you want a field out of the DEFAULT_LANGUAGE or > not for every field access/query. > > 5. gettext like approach. > Save a translation for possible string in the database, fallback to > gettext. DB might explode here, as DB-load sho
