Re: translations - cross post. maybe this is a better place to discuss this :)
* stuff4ash wrote, On 22.01.2007 10:57: > after searching and reading all the posts related to internalization > and multilanguange, my first question is if there is any active > development to integrate or make easy translations in the django core, > and if not, if there are any people who would be interested in a joint > effort. http://trac.studioquattro.biz/djangoutils/wiki/TranslationService or http://trac.studioquattro.biz/djangoutils/wiki/TSRFC [snip] > now i am going to describe how it should/could be for a programmer, > independently of how this could be implemented behind the scenes, in a > DRY way: > class Page(models.Model): > titel = models.CharField(maxlength=200) > text = models.TextField() > class Admin: > pass > class Translation: > pass I'm -1 on this, translation must be done *without* any changes to the model. [snip] > when we would use something like: >>> pages = Page.objects.all() > we would use: >>> pages = _lang(Page.objects.all()) > (and would filter out all other languages than the current one (from > request or cookie or whatever) > _lang can accept a language to force a specific one... >>> pages = _lang(Page.objects.all(),'en') > (get the english ones) >>> pages = _rootlang(Page.objects.all(),) > get root is similar to _lang, except that it returns the list of the > translations that exist for the root languange. > in the example above, we set root to french. _rootlang will search all > the french pages, get the translations for those documents. if you > want, it can return the original root languange version automatically > when no translation for it exists... IMHO, best place to translate content is in the template -- at the point of the display. Most of other i18n solutions works like that. I borrowed idea from Zope PlacelessTranslationService and implemented working draft at http://trac.studioquattro.biz/djangoutils/wiki/TranslationService. Also I started refactoring/improving/etc at http://trac.studioquattro.biz/djangoutils/browser/branches/0.1/translation (currently broken). We can move this discussion to the django-i18n and coordinate efforts with others interested in this, and when we come with some concrete implementation add this to the django contrib. I'm planning to do more serious work on translations in the next week, so stay tuned. -- Nebojša Đorđević - nesh, ICQ#43799892 Studio Quattro - Niš - Serbia http://studioquattro.biz/ | http://trac.studioquattro.biz/djangoutils/ Registered Linux User 282159 [http://counter.li.org] --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: translations - cross post. maybe this is a better place to discuss this :)
thx for the links :) > > passI'm -1 on this, translation must be done *without* any > > changes to the model. the problem with translations is the many different use "cases". and in many cases, avoiding a change to the model is not posible. for example, when u have a site with several languanges, but one object is not directly translated to another, but just two sites with different languanges, you have to at least add a IntegerField, ChoiceField or a foreign key to available languange. the next issue is "where" the translations should be made. many i18n solutions work with separate "languange" files, that . while that is ok when you are translating applications (like the admin interface), it is not ok for translating _content_, even if they are stored in the database. in CMS type applications, you want your users to be able to translate objects or create objects in different languanges. And ideally, from inside the admin interface. and ideally, without having to make custom views just because you have multilanguange content. And like i said in my post, you have to be able to define what fields should be translatable or not. if you are defining inside the model or outside the model is not a big diffence, but i do think it makes sense inside the model (you could argument that the admin class and methods shouldnt go in the model either), because this directly influences how the model is handled in the database, or how the translations are handled in the database. what has to do with choosing languanges in the view... >> pages = _lang(Page.objects.all()) i think you are probably right that all translation logic should be done in one place, and the templates are a good place to do it. but if you are doing more than just translating, lets say, you want to be able to display more than one languange in one page and arranged in a specific way or with counts on objects or something more complicated, the template logic might get a little more complicated than say just looping, which is bad if you also want to keep your templates simple for your html designers. so i think both approaches should be posible: an easy (and recommended) way of using translation template tags, but also implement some easy methods to be able to filter and get by languange. mutlilanguange sites is one of the most difficult things to do, so i doubt that one solution will be the holy grail. so i think it is good if there is more than one solution. but even if two good incompatible solutions come out, the resources for both should be in one place and should not require more from the developer than an import from contrib.il8n.thissolution to be able to implement them. there seems to be already a working implementation of something similar to what i said: http://groups-beta.google.com/group/django-users/browse_thread/thread/6a96426735ffd7f1 cheers, ashley :D > [snip] > > > > > when we would use something like: > >>> pages = Page.objects.all() > > we would use: > >>> pages = _lang(Page.objects.all()) > > (and would filter out all other languages than the current one (from > > request or cookie or whatever) > > _lang can accept a language to force a specific one... > >>> pages = _lang(Page.objects.all(),'en') > > (get the english ones) > >>> pages = _rootlang(Page.objects.all(),) > > get root is similar to _lang, except that it returns the list of the > > translations that exist for the root languange. > > in the example above, we set root to french. _rootlang will search all > > the french pages, get the translations for those documents. if you > > want, it can return the original root languange version automatically > > when no translation for it exists...IMHO, best place to translate content > > is in the template -- at the point of the display. Most of other i18n > > solutions > works like that. > > I borrowed idea from Zope PlacelessTranslationService and implemented working > draft athttp://trac.studioquattro.biz/djangoutils/wiki/TranslationService. > > Also I started refactoring/improving/etc > athttp://trac.studioquattro.biz/djangoutils/browser/branches/0.1/transl... > (currently broken). > > We can move this discussion to the django-i18n and coordinate efforts with > others interested in this, and when we come > with some concrete implementation add this to the django contrib. > > I'm planning to do more serious work on translations in the next week, so > stay tuned. > > -- > Nebojša Đorđević - nesh, ICQ#43799892 > Studio Quattro - Niš - > Serbiahttp://studioquattro.biz/|http://trac.studioquattro.biz/djangoutils/ > Registered Linux User 282159 [http://counter.li.org] --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://group
Re: translations - cross post. maybe this is a better place to discuss this :)
nesh napisał(a): > I'm -1 on this, translation must be done *without* any changes to the model. I'm -1 on that -1 :) > IMHO, best place to translate content is in the template -- at the point of > the display. I disagree. To me translations (of content) are not just another version of the data, they *are* the data. In many cases I need to have data ordered and filtered with regards to different language versions. This is something different than what "i18n" usually means (I think). The changes to a model are necessary to make a distinction between translatable and non-translatable data; I put an example with a prototype implementation very similar to ashley's idea in django-users, see http://groups-beta.google.com/group/django-users/browse_thread/thread/6a96426735ffd7f1 > I'm planning to do more serious work on translations in the next week, so > stay tuned. Cool, the more ideas the better :) -mk --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Critical ticket: can cause data loss
On 1/23/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > On 1/23/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > > > Could somebody provide some unit tests that isolate the problem? I've > > never mucked with the GenericForeignKey code -- perhaps Jacob or > > Russell could chime in here for the fix? > > I've never really played with GenericRelations, so I don't know their > internals particularly well. I'll have a look tonight and see if I can > make any sense of the problem. I've just attached a unit test to the ticket. It seems to be the same issue described in #2749 and #3081. I think I understand the problem; the patch on #3081 is pretty much correct. I should have this sorted out by tonight. Russ Magee %-) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: translations - cross post. maybe this is a better place to discuss this :)
* stuff4ash wrote, On 23.01.2007 10:24:
> the problem with translations is the many different use "cases". and in
> many cases, avoiding a change to the model is not posible. for example,
> when u have a site with several languanges, but one object is not
> directly translated to another, but just two sites with different
> languanges, you have to at least add a IntegerField, ChoiceField or a
> foreign key to available languange.
If I understood you correctly, you want different objects for different
languages? In that case I simply use something
like this:
class Foo(models.Model):
lang = models.CharField(choices=settings.LANGUAGES,
default=get_language, maxlength="3", db_index=True)
[...]
and simply Foo.objects.filter(lang=) when needed, or add new manager
to do this for you.
I primary use this when I have content that will be language specific (i.e.
English and Serbian language news item are
totally different). IMHO this not violates DRY, I simply make a new ml_news app
which have all functionality that I need.
I did this for the flatpages so I now have ml_flatpages app which displays
different content depending of the selected
language.
> the next issue is "where" the translations should be made. many i18n
> solutions work with separate "languange" files, that . while that is ok
> when you are translating applications (like the admin interface), it is
> not ok for translating _content_, even if they are stored in the
One drawback of having translation tied to the objects are that translations
are not reusable -- if you translate some
content you can't reuse that for another object with the same data. I use
central translation repository (table) for all
translated data so if someone already translated same message (for another
object) it can be reused (and also it will
check for django gettext translation).
> database. in CMS type applications, you want your users to be able to
> translate objects or create objects in different languanges. And
> ideally, from inside the admin interface. and ideally, without having
> to make custom views just because you have multilanguange content.
I looked at the different solutions in the popular CMS which have i18n support
like Drupal and Plone. Drupal i18n module
uses different node for different language which can lead to duplicating data.
Plone uses similar approach like mine (in
the matter of fact, I modeled my TranslationService on the Zope
PlacelessTranslationService).
Also, I'll planning to add (when user have rights to do so, and translation
mode is switched on) links (or some JS
in-place editing) for content translation automatically without any changes to
the template or new views.
> And like i said in my post, you have to be able to define what fields
> should be translatable or not. if you are defining inside the model or
> outside the model is not a big diffence, but i do think it makes sense
> inside the model (you could argument that the admin class and methods
> shouldnt go in the model either), because this directly influences how
> the model is handled in the database, or how the translations are
> handled in the database.
When you use tag you specify which field is to be translated like {% translate
[to ] %}, the main
difference is that I treat translation like any other data in the template -- I
can also (but I'm -0 on this) add same
for the static content without much trouble.
Bad side of my approach is that you can not sort object on the *translated*
value of the field -- for that I don't have
(yet) any solution.
> what has to do with choosing languanges in the view...
>>> pages = _lang(Page.objects.all())
Why choosing language in the view? User is already make that selection with
click-on-the-flag, browser negotiation,
whatever. If you do that, you must specially code views to handle ML content.
gettext like approach is much better.
Views only pass data to the template which will choose how it is
displayed/translated.
> i think you are probably right that all translation logic should be
> done in one place, and the templates are a good place to do it. but if
> you are doing more than just translating, lets say, you want to be able
> to display more than one languange in one page and arranged in a
> specific way or with counts on objects or something more complicated,
> the template logic might get a little more complicated than say just
> looping, which is bad if you also want to keep your templates simple
> for your html designers. so i think both approaches should be posible:
> an easy (and recommended) way of using translation template tags, but
> also implement some easy methods to be able to filter and get by
> languange.
It is possible using object registry to get all translations for the object
*field*, it is (a little) more complicated
to get translated *objects* though, and adding tags to get counts will be
trivial.
Multiple translation on the same page
Re: translations - cross post. maybe this is a better place to discuss this :)
* [EMAIL PROTECTED] wrote, On 23.01.2007 10:49: > nesh napisał(a): >> I'm -1 on this, translation must be done *without* any changes to the model. > I'm -1 on that -1 :) >> IMHO, best place to translate content is in the template -- at the point of >> the display. > I disagree. To me translations (of content) are not just another > version of the > data, they *are* the data. In many cases I need to have data ordered > and filtered > with regards to different language versions. This is something > different than what > "i18n" usually means (I think). Yes, this requires more than one solution. Currently I need translations in literal i18n (gettext) way -- translate message to the another language and my approach is sufficient for that. Storing ML content is the completely different beast. > The changes to a model are necessary to make a distinction between > translatable > and non-translatable data; I put an example with a prototype > implementation very > similar to ashley's idea in django-users, see > http://groups-beta.google.com/group/django-users/browse_thread/thread/6a96426735ffd7f1 I tried this approach first (although before MR branch) and I hated explosion of the new tables which it creates. Until full model inheritance support there is no clean way to support fully translatable models which will support natural ordering, filtering, etc. like ordinary models. Also, I suspect that some changes must be done inside Django ORM layer to support this. >> I'm planning to do more serious work on translations in the next week, so >> stay tuned. > Cool, the more ideas the better :) No more ideas, I'm planning to do complete implementation. Then it's time for the new ideas :) p.s. Let's go to django-i18n, *the* place for I18N discussions :) -- Nebojša Đorđević - nesh, ICQ#43799892 Studio Quattro - Niš - Serbia http://studioquattro.biz/ | http://trac.studioquattro.biz/djangoutils/ Registered Linux User 282159 [http://counter.li.org] --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: translations - cross post. maybe this is a better place to discuss this :)
On 23 Sty, 12:45, nesh <[EMAIL PROTECTED]> wrote: > Storing ML content is the completely different beast. Unfortunately, this is what I need right now :) > I tried this approach first (although before MR branch) and I hated explosion > of the new tables which it creates. Until > full model inheritance support there is no clean way to support fully > translatable models which will support natural > ordering, filtering, etc. like ordinary models. With model inheritance it would probably look just the same: one new table that contains the translatable fields for each model. > Also, I suspect that some changes must be done inside Django ORM layer to > support this. Using the "separate table" backend, yes, I will need left joins to do allow sorting and filtering by the values of translatable fields. The "separate columns for each language" backend does not require any changed to Django, as far as I can see. Even table updates in syncdb are doable without touching Django source. > p.s. Let's go to django-i18n, *the* place for I18N discussions :) I thought about it but did not want to create fourth thread for the same discussion within two days. How about staying on django-users? It is a use of Django after all ;) -mk --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: translations - cross post. maybe this is a better place to discuss this :)
* [EMAIL PROTECTED] wrote, On 23.01.2007 13:04: >> p.s. Let's go to django-i18n, *the* place for I18N discussions :) > I thought about it but did not want to create fourth thread for the > same discussion within two days. How about staying on django-users? > It is a use of Django after all ;) OK, I'll reply there. -- Nebojša Đorđević - nesh, ICQ#43799892 Studio Quattro - Niš - Serbia http://studioquattro.biz/ | http://trac.studioquattro.biz/djangoutils/ Registered Linux User 282159 [http://counter.li.org] --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Critical ticket: can cause data loss
On 1/23/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > I've just attached a unit test to the ticket. It seems to be the same > issue described in #2749 and #3081. I think I understand the problem; > the patch on #3081 is pretty much correct. I should have this sorted > out by tonight. > Ok - I've attached a patch with a fix to #3215. The fix is pretty much what is attached to #3081, cleaned up for a couple of edge cases. The patch fixes #3081, #3215 and #2749. I haven't committed the fix - it's late, I'm jetlagged, and I'm not completely certain I haven't missed an edge case (in particular, the reverse case - the patch for #3081 contains protection in the reverse_m2m traversal, but as far as I can make out generic relations don't have a reverse representation). There is also some potential for cleanup - I'd rather see the type specific portion abstracted into a method on the field rather than having the isinstance(GenericField) call. However, in the meantime, the provided patch makes the unit tests pass and removes the data loss problem. If someone else can give this patch a sanity check and commit it, I'd be much obliged. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: translations - cross post. maybe this is a better place to discuss this :)
yes, lets close this thread: and use this one: http://groups-beta.google.com/group/django-users/browse_thread/thread/6a96426735ffd7f1 On Jan 23, 1:55 pm, nesh <[EMAIL PROTECTED]> wrote: > * [EMAIL PROTECTED] wrote, On 23.01.2007 13:04: > > >> p.s. Let's go to django-i18n, *the* place for I18N discussions :) > > I thought about it but did not want to create fourth thread for the > > same discussion within two days. How about staying on django-users? > > It is a use of Django after all ;)OK, I'll reply there. > > -- > Nebojša Đorđević - nesh, ICQ#43799892 > Studio Quattro - Niš - > Serbiahttp://studioquattro.biz/|http://trac.studioquattro.biz/djangoutils/ > Registered Linux User 282159 [http://counter.li.org] --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
[triage] Howto emphasize a ticket
Hi there, The triage system is really nice! but there's just one thing, with the removal of priorities when a core developer goes to see the "Read for check-in" tickets it has no way to know that some of those tickets should be taken ASAP, for example: #3336 which solved broken links in djangoproject.com. Is there any recommended way to announce the existance of such tickets or just "ping" here asking for those tickets to be closed ASAP? That would apply also for security related tickets and so on. Just ask the users if they like the broken links in the website :P Cheers, Marc. PS: Oh, please check-in #3336 and update the website ASAP :o) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: [triage] Howto emphasize a ticket
On 1/23/07, Marc Fargas Esteve <[EMAIL PROTECTED]> wrote: > That would apply also for security related tickets and so on. Just ask > the users if they like the broken links in the website :P For security issues, the "how to contribute to Django" docs list a dedicated email address -- [EMAIL PROTECTED] -- for reporting; we vastly prefer having those reported via email instead of the public ticket tracker so we can evaluate them and announce a fix at the same time as the vulnerability. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: [triage] Howto emphasize a ticket
On 1/23/07, Marc Fargas Esteve <[EMAIL PROTECTED]> wrote: > The triage system is really nice! but there's just one thing, with the > removal of priorities when a core developer goes to see the "Read for > check-in" tickets it has no way to know that some of those tickets > should be taken ASAP, for example: #3336 which solved broken links in > djangoproject.com. > > Is there any recommended way to announce the existance of such tickets > or just "ping" here asking for those tickets to be closed ASAP? I think the best thing to do in the case of high-priority tickets is exactly what you did: send a message to this mailing list. The reason we'd rather not expose a "priority" field in our ticket system is that people abuse that, giving artificial priority to their own tickets, often anonymously. I've fixed #3336, by the way -- thanks for the pointer. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: [triage] Howto emphasize a ticket
On 1/23/07, Marc Fargas Esteve <[EMAIL PROTECTED]> wrote: > a core developer goes to see the "Read for > check-in" tickets it has no way to know that some of those tickets > should be taken ASAP, FWIW, I think there's a goal that the queue for "ready for check-in" be nearly empty, so prioritizing in that queue should be a moot point. The initial glut of ready tickets is due to a large number of good tickets lost in the flood of un-ready tickets, but which were brought to the surface by the triage process. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
svn properties ?
Hi,
may I suggest to set properties for the files in svn ?
{{{
for filename in `find . -type f`; do
svn propset svn:keyword "URL Author Date Rev Id" $filename
done;
}}}
Regards,
Dirk
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: New branch: newforms-admin
> Excellent -- I'm excited that you're interested in helping out. The > best bet would be to submit patches against the newforms-admin, but > I'll give the caveat that I'm moving pretty quickly on this and may > duplicate your work. The last thing I want is for you to spend time on > a patch, only to have it be made redundant. > > How about this: Suggest some concrete changes you'd like to make, and > I'll try to avoid making those changes. Well, first off I'd like to say that I think you are going in a very good direction with the ModelAdmin class and I would be happy to help out with anything I can. Since you would like to decouple the admin from the models I think it would be a good Idea to have the ModelAdmin do all the validation for the admin options. Currently they are in the django.core.management.get_validation_errors() which validates all of the model class. I would like to move them into the ModelAdmin and add the missing validators, then rewrite the test cases for invalid_admin_options accordingly. I guess the only issue would be when the validation would be called. My initial plan was to add a _validate_FOO() for each option and then have a method ModelAdmin.validate() which would call all of them. My alternative plan which I like better is to add get_FOO() for each option which would both validate and return the option. Then we could rewrite the various views to use this get method instead of self.FOO, now I know this adds a little overhead to an otherwise straight forward operation. But, an added benefit would be the ModelAdmin could be self healing, say you declare list_display with a bunch of fields then spell a field name wrong, which I do all the time :) get_list_display() would just simply remove the bad fieldname with a warning and return the otherwise good list. That way instead of getting a 500 error or an ugly traceback you get a list minus the bad field or the default option. Another obvious benefit is that when you define the ModelAdmin for you class you could provide your own get_FOO() to make your ModelAdmin dynamic or user customizable. For example I would like to have an application where users can select which fields to display in the list, since everyone has his/her own tastes, with my get_FOO() I could store each users preference in a cookie or the DB. I'm not 100% on combining the validation into the get method, so any input would be excellent or if anyone has any better ideas. I will start working on just writing the validation methods since they could be easily turned into the get methods I'm proposing. Then If no one else likes the idea I wont go down that path. Robert Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.com > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Why does the admin app tie directly to models?
Why does the admin app tie directly to models? Why not applications? Nate --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django with CherryPy 3.0
On 1/22/07, Graham King <[EMAIL PROTECTED]> wrote: > Yes, it does. I telnet to 8000 to keep a request open, and make a > regular browser request. With the current dev server the browser will > hang until I kill the telnet. With the patch the browser responds. > > +1 from me. > > I'm going to keep the patch on my local checkout and will report if I > notice anything funny. Keeping in mind the comments about possible thread-safety heisenbugs, let's make it so that the threaded behavior is *optional*, but people can turn it on if they're concerned about Ajax-induced stalling. What do you think? Anybody willing to update the patch and post it into our ticket system? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Looking up into an ordered list... A new feature?
How to achieve to search within a list of id that have been sorted in a precise way? the __in lookup tag will automatically reorder the list by ascendancy (and I reckon in_bulk does the same too). I have a list where items are ordered by rate (which is not a field of the same table) and giving the ordered list using the __in keyword will undo this order. Is there any way to achieve this? I am posting here because I believe this is a new feature for which I'm likely to submit a ticket as I know some other folks looking for it already. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: svn properties ?
On 1/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> may I suggest to set properties for the files in svn ?
>
> {{{
> for filename in `find . -type f`; do
> svn propset svn:keyword "URL Author Date Rev Id" $filename
> done;
> }}}
Pardon my ignorance, but what would this accomplish?
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Encouraging contributed documentation
Let me start by saying that I think that djangoproject.com and the Django book are both doing really good jobs of providing documentation and helping both to introduce new users to the framework and teach old dogs some new tricks. But... There's an awful lot of really good documentation floating around on other sites, some of which goes beyond anything covered in the official docs. That's always bugged me (even though I'm just as guilty as a lot of people when it comes to writing about Django and keeping it on my own site), because it carries two disadvantages: 1. It fragments documentation and detracts from having a "one-stop shop" for information about Django -- every time we have to refer somebody to information that's only on someone else's site, we're simultaneously pointing out a failure in our documentation. 2. It comes at a risk; links have a tendency to rot over time, and if a useful tutorial or blog entry goes to the great 404 in the sky one day it'll hurt Django as a whole. So I'd like to propose that we draw up some guidelines for contributing documentation for Django, and begin encouraging documentation contributions just as much as we encourage code contributions. The requirement to supply documentation with patches which add new functionality is a good start, but there's still quite a bit of existing functionality that has no official documentation (the dispatcher, for example). The community aggregator has shown time and again that there are plenty of people out there who are willing and able to provide good write-ups of functionality we haven't yet documented officially (and to point out any errors in things we have documented), so I think we should do our best to work with them on getting that information into the official docs. Maybe we could even choose some of the more prolific bloggers to form an official documentation team and work on filling in the gaps and maintaining the docs we already have? That'd also help take some of the burden off the core dev team, who currently maintain both the code and the documentation :) -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Encouraging contributed documentation
+1 I'd also like to see a script that generates a CHM (Compiled HTML Help) from the official Django ReST docs. The CHM could then be included as part of the installer-based release for Windows users. One of these days I'll probably get fed up waiting for the pages on djangoproject.com to load and write the damn script myself, unless someone beats me to it :) -+ enlight +- --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django with CherryPy 3.0
On Jan 23, 7:55 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > Keeping in mind the comments about possible thread-safety heisenbugs, > let's make it so that the threaded behavior is *optional*, but people > can turn it on if they're concerned about Ajax-induced stalling. What > do you think? Anybody willing to update the patch and post it into our > ticket system? Credit should definitely go to Istvan Albert, but I started a patch with documentation update(s) here: http://code.djangoproject.com/ticket/3357 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: svn properties ?
On 1/23/07 9:58 PM, Adrian Holovaty wrote:
> On 1/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> may I suggest to set properties for the files in svn ?
>>
>> {{{
>> for filename in `find . -type f`; do
>> svn propset svn:keyword "URL Author Date Rev Id" $filename
>> done;
>> }}}
>
> Pardon my ignorance, but what would this accomplish?
It would mean we could do CVS-style keyword expansion inside files. That is,
SVN would automatically expand "$Author$" to the name of the person who last
checked in the file.
Personally, I hate keyword expansion with a hatred usually reserved for
members of Class Arachnida and my freshman-year college roommate.
That's a -1, for anyone keeping track.
Jacob
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Why does the admin app tie directly to models?
On 1/23/07 9:16 PM, Nate Straz wrote: > Why does the admin app tie directly to models? Why not applications? Because sometimes you want certain models within in app *not* to be admin-editable. Jacob --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: svn properties ?
On Jan 23, 2007, at 9:44 PM, Jacob Kaplan-Moss wrote:
>
> On 1/23/07 9:58 PM, Adrian Holovaty wrote:
>> On 1/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>> may I suggest to set properties for the files in svn ?
>>>
>>> {{{
>>> for filename in `find . -type f`; do
>>> svn propset svn:keyword "URL Author Date Rev Id" $filename
>>> done;
>>> }}}
>>
>> Pardon my ignorance, but what would this accomplish?
>
> It would mean we could do CVS-style keyword expansion inside files.
> That is,
> SVN would automatically expand "$Author$" to the name of the person
> who last
> checked in the file.
>
> Personally, I hate keyword expansion with a hatred usually reserved
> for
> members of Class Arachnida and my freshman-year college roommate.
>
> That's a -1, for anyone keeping track.
>
I could care less about most of the keywords. However, having Rev or
Id set is handy for the sysadmin down the road trying to figure out
where the bug came from.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: svn properties ?
On 1/24/07, Sean Perry <[EMAIL PROTECTED]> wrote: > I could care less about most of the keywords. However, having Rev or > Id set is handy for the sysadmin down the road trying to figure out > where the bug came from. Isn't that what `svn blame` is for? Count me -1 on keywords expansion, too. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
