((( < Best Cooking Machines > )))
*Best cooking Machines Collection http://about.awepedia.info/cooking-machines/ These Machines make your cooking easy Please some vegetarian Foods recipes Thanks Bye * --~--~-~--~~~---~--~~ 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: GSoC status?
On 4/28/07, David Larlet <[EMAIL PROTECTED]> wrote: > I just hope those ones will be successful! Maybe we can learn from the > past and improve students/dev communication in order to help them a > bit more if they need it? I think for the most part, in terms of the scope of GSoC, the previous ones were successful. It seemed like most of the hard work was done, for each of the branches. (At least, auth and rlp seemed to do quite well). Problem was there wasn't enough demand/interest in the community to get them fully integrated, no one was stepping up to take over. There were always people (myself included) that wanted to use the various branches, but no one was willing to put the time in to make them trunk ready. The one problem with GSoC is that while students may have lots of time in the summer, that time tends to go towards zero once September hits :) I guess it all just depends on your measure of "success". Jay P. --~--~-~--~~~---~--~~ 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: GSoC status?
2007/4/28, James Bennett <[EMAIL PROTECTED]>: > > On 4/28/07, David Larlet <[EMAIL PROTECTED]> wrote: > > I'm just curious about SoC, especially the REST one, listed on this > > page: http://code.google.com/soc/django/about.html > > > > Maybe it's time to make an "official" announcement? > > Well, what would you like to know? ;) > I just hope those ones will be successful! Maybe we can learn from the past and improve students/dev communication in order to help them a bit more if they need it? David PS : I don't want to blame anyone here for previous GSoC, excuse me if my bad English is too direct. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
<< Home Decorate Tips >>
Decorate Your Home With easy guide http://about.awepedia.info/decorate-your-home/ Best tips for Girls and Women if you have more please share here Rania --~--~-~--~~~---~--~~ 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: Serialize model properties enhancement
On Apr 28, 2:48 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > The open question in my mind is where the serialized data goes - do we > put it into the fields block, or do we start a new 'extra' block? i.e, > which of the following JSON outputs would you expect? I prefer the latter too, with the extra block. > And what happens on deserialization? Is the attribute restored, or > ignored? I'm inclined to prefer the latter serialization format, and > ignore on restoration, but I'd be interested in hearing other > opinions. Regarding deserialization, i guess if a queryset will set these extra columns to a model why not restore them? David Elias --~--~-~--~~~---~--~~ 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: Translated app names in admin - suggestion for ticket #1668
> Only if they are specified, which often isn't the case (because they > usually aren't both needed). A translation solution that requires > developers to write out the model name again for every single model just > for translation purposes is what we are trying to avoid. It's > error-prone and repetitive. [snip] > Asking people to hand-edit a PO file is a recipe for frustration and > accidents. I would feel very uncomfortable making that the approach we > suggest anywhere. If something cannot be done with hand-editing the PO > file, it means it effectively just can't be done. I'm not advocating hand-editing of .po files - but if the solution is going to automagically add translation strings, then you will undoubtedly get strings in there which sometimes will be unneeded. I was only responding to your comment about unneeded translation strings being added programmatically. > I don't understand your concern here. All models in a given app are in > the *same* app, so we can get the app name from any one of those models. > We happen to pick the first. This isn't really a justification for an > Application class, however the issues Joseph raised and you mention have > more bearing on the problem. It's not a big concern, more a comment on what appears IMHO to be a minor wart. I just want to be sure that the core developers are not against the idea, in principle, of a (very lightweight) Application class, if that should be a natural part of the solution (it's in line with the overall approach of Joseph's patch). > Once again, we should be aiming to avoid having to list all these > strings out an extra time just to get them through the i18n framework. > So you are looking in the right sort of areas: where are the strings > going to be needed anyway and how can we get at them with > make-messages.py. > > I'll again keep encouraging you to keep thinking about this. Don't try > to bring it all to a resolution in only a day or two. You've done a lot > of good research and thinking here, so let it bounce around in your head > for a little while to see if anything good or bad pops up. Gives other > people a little while to think about it, too. Good advice, and I'll take it. Regards, Vinay Sajip --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
