> 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-multilingual and 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 -~----------~----~----~----~------~----~------~--~---
