Ok. Thanks
Anubhav
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to dja
As far as I know, we have no plans to request further details from any of
our applications.
On Thursday, March 27, 2014 5:46:55 AM UTC-4, anubhav joshi wrote:
>
> I read on google melange:
> "mentoring organizations may request further proposal detail from the
> student applicant."
>
> My tests
I read on google melange:
"mentoring organizations may request further proposal detail from the
student applicant."
My tests are about to start so I want to know if and when should I be
expecting this.
Regards,
Anubhav
--
You received this message because you are subscribed to the Google Grou
+1 from pt-br
-mensag. original-
Assunto: Re: [GSoC 2014 proposal]. Improving admin translation and formalizing
Meta objects.
De: Andrew Pashkin
Data: 22-03-2014 06:44
Proof of concept for pymorphy solution:
https://gist.github.com/StillNewb/9703843
On Saturday, March 15, 2014 9:20:24 PM UTC
Proof of concept for pymorphy solution:
https://gist.github.com/StillNewb/9703843
On Saturday, March 15, 2014 9:20:24 PM UTC+4, Алексей Сидаш wrote:
>
> Hello
>
> Yes, Adam Mesha seems to be right. The problem of translation is very
> complicated.
> I see only one solution, all the text in admin
P.S.
Ooops, looks like I forgot about this:
> MediaWiki has a well evolved and mature translation system that deals with
> a very large range of languages, and I think it would be worthwhile to
> check out how they do it there in detail.
>
Great thanks, I will check it out.
--
You received
Hello,
> I believe that there is a better solution than requiring that all strings
> be retranslated for every new app that you create, it's just not as trivial
> as the naive solution that Django currently uses.
>
Yes, retranslatiog all the strings every time does not seem to be a good
idea.
MediaWiki has a well evolved and mature translation system that deals with
a very large range of languages, and I think it would be worthwhile to
check out how they do it there in detail. I believe that there is a better
solution than requiring that all strings be retranslated for every new app
th
Hello
Yes, Adam Mesha seems to be right. The problem of translation is very
complicated.
I see only one solution, all the text in admin panel should not be
generated dynamically.
I mean, that code like *"Add new {{ model.verbose_name }}"* makes
translation to languages like Russian very difficu
2014-03-13 11:00 GMT+02:00 Алексей Сидаш :
> For example, we have two models. *Article* and *Post*.
> In English we say *"Add new Article"* and *"Add new Post"*, right?
> But in Russian article's grammatical gender is "female", but post's
> grammatical gender is "male", so we should say "Добавить
The problem is actually exists, I also want to find a way, how to rid my
cleints of that crazy wording in admin-site.
I've found promising package - pymorphy2
(https://github.com/kmike/pymorphy2), it can find grammatical information
for words and translate words to needed forms. So all what is n
Hi,
Regarding the translation issues, there's a lengthy discussion on
https://code.djangoproject.com/ticket/11688 which you might find
interesting.
--
Baptiste
On 03/13/2014 10:00 AM, Алексей Сидаш wrote:
How so? Can you provide a few examples -- I know that numbering
can be a prob
> How so? Can you provide a few examples -- I know that numbering can be a
> problem for Russian translations, but that's hardly a problem of the admin
> itself.
There are three grammatical genders in Russian, and all the words in
sentense should match gender of subject. You seem to be righ
Hello there!
My name is Alexey and I would like to do some work for django project. I'm
from Russia, and English is not my native language(my native one is
Russian). And Russian localization of django admin is poor. It is even
worse then my English :D. Of course, I do not like it, I believe tha
On Wed, Mar 12, 2014 at 9:58 PM, anubhav joshi wrote:
> Well another thing I think I realize now is that I think is there seems to
> be problem of absence of common theme.
> To this I would say that if one would look closely at the issues covered
> up in the proposal are those which do report of b
Hi Alexey,
On Wednesday, March 12, 2014 7:52:59 PM UTC+1, Алексей Сидаш wrote:
>
> Russian localization of django admin is poor. It is even worse then my
> English :D.
>
How so? Can you provide a few examples -- I know that numbering can be a
problem for Russian translations, but that's hardly
Hello there!
My name is Alexey and I would like to do some work for django project. I'm
from Russia, and English is not my native language(my native one is
Russian). Russian localization of django admin is poor. It is even worse
then my English :D. Of course, I do not like it, I believe that Met
Well another thing I think I realize now is that I think is there seems to
be problem of absence of common theme.
To this I would say that if one would look closely at the issues covered up
in the proposal are those which do report of bad error reporting not just
simple bugs. The issues do repor
Having replied to the potential questions above, I would like to summarize
here once again:
1.) I have a very clear idea of what area of code I will be dealing with.
2.) I have been in conversation with community members on IRC, and have
taken their say in fixing the issues mentioned in the prop
On Wednesday, March 12, 2014 5:57:23 PM UTC+5:30, Russell Keith-Magee wrote:
>
> Hi Anubhav,
>
> I've taken a look at your proposal, and I'm of two minds.
>
> On the one hand, you've identified a bunch of reasonably uncontroversial
> tickets - issues where there is a clear problem, a solution th
Hi Anubhav,
I've taken a look at your proposal, and I'm of two minds.
On the one hand, you've identified a bunch of reasonably uncontroversial
tickets - issues where there is a clear problem, a solution that seems
obvious, and in most cases indications of support from the core team. Your
proposal
I do keep updating gist upon getting feedback/reviews on IRC as well.
Please keep a track.
https://gist.github.com/coder9042/c505dfba9514a6e52fdc
Regards,
Anubhav Joshi
IIT Patna
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscri
Done the required.
https://gist.github.com/coder9042/c505dfba9514a6e52fdc
Regards,
Anubhav Joshi
IIT Patna
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
Hi Anubhav,
It'll be easier to review if you can include ticket numbers with each item
in the 2.X sections. e.g. "Unpickling Models and QuerySet from incompatible
version. (#X)" Ideally, the ticket number would be linked to Trac. Then
I would repeat these summaries & ticket numbers in each
Just realized that the proposal name is : Improving error reporting and
fixing up related issues.
Missed 'reporting' in the thread topic.
Anubhav Joshi
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and st
OK, will do.
Anubhav Joshi
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send emai
Yes, people can look elsewhere for the tickets, but it'd probably have more
*impact* if the tickets were referenced directly in the proposal. That way,
someone can dive into the deeper discussion for a particular bug (by
reading the comments on the ticket). The idea is that you don't want your
Please refer to the thread :
https://groups.google.com/forum/#!topic/django-developers/PDY8EEYaHao for
tickets...
Actually, all of a sudden there has been some problem in my laptop since
this morning and I can't open my hard disk currently. So, I request you all
to please view the proposal and
Just a brief comment. Perhaps it'd be useful to link to the appropriate
trac tickets in your proposal.
Regards,
Josh
On Saturday, 8 March 2014 15:59:27 UTC+11, anubhav joshi wrote:
>
> Hi all,
>My previous thread:
> https://groups.google.com/forum/#!topic/django-developers/PDY8EEYaHao
Hi all,
My previous thread:
https://groups.google.com/forum/#!topic/django-developers/PDY8EEYaHao ,
where I was told by Tim Graham to make all analysis and discussion on
tickets itself and then present here.
I did what I was told, I discussed issues and strategies on Trac and IRC
both.
As suggested by Tim Graham, I am going to post my analysis on respective
tickets.
But there are some issues where I need help in analysing, I have mentioned
those in my above posts. Also there may be issues for which ticket have not
been opened, they are only mentioned in the wiki page.
Hence, i
As suggested by Tim Graham, I am going to put my analysis on respective
tickets.
Also it is possible that some issues are directly mentioned on wiki
page(there is no ticket for them), so its a humble request to please go
through it once here.
Regards,
Anubhav Joshi
IIT Patna
--
You received t
I believe if your tickets are enough work to fill 12 weeks, someone is not
going to come along and complete a majority of them in the meantime. You
can also add something like "I hope to work on this ticket for GSoC 2014."
On Thursday, February 27, 2014 3:57:45 PM UTC-5, anubhav joshi wrote:
>
>
On Friday, February 28, 2014 2:03:10 AM UTC+5:30, Tim Graham wrote:
>
> I think it'll be better to put your analysis of each ticket on the ticket
> itself. Then when you're finished with that, put together a more high level
> overview of the analysis you've done. I think it will be easier to gi
I think it'll be better to put your analysis of each ticket on the ticket
itself. Then when you're finished with that, put together a more high level
overview of the analysis you've done. I think it will be easier to give
feedback if you structure your thoughts in this way. Thanks!
On Thursday,
Here is another issue that I have analysed.
*When the autogenerated field name is too long, there is no proper
displaying of errors, many a time silent failures for some database.*
Written a fix, although some thinking is required in writing the tests.
@classmethod
def _check_long_column_name(cl
On Wednesday, February 26, 2014 7:43:49 PM UTC-8, Russell Keith-Magee wrote:
>
> Hi Anubhav,
>
> Please keep in mind that this is a global mailing list, and if you want
> considered feedback, it's going to take time. Posting two "Please give me
> feedback" pings in 6 hours isn't especially help
Hi Anubhav,
Please keep in mind that this is a global mailing list, and if you want
considered feedback, it's going to take time. Posting two "Please give me
feedback" pings in 6 hours isn't especially helpful. There will be people
who have been asleep for that entire period.
Yours,
Russ Magee %-
Please give me any reviews and suggestions regarding the issues, as and
when I am posting about them.
So that when I my studying and analysis of the issues is done, then I can
chalk out a proper timeline for the required work as well.
Regards,
Anubhav Joshi
IIT Patna
--
You received this messa
Please have a look at all the issues mentioned, correct me where I am wrong
and there are places where I need help(I have mentioned in those places.)
I need feedback and reviews.
Will be posting back again very soon with further analysis of other issues.
Regards,
Anubhav Joshi
IIT Patna
--
Yo
Here is some more analysis:
django.db
1.)
There is a problem with ForeignKey, which when given only blank=True causes
ValidationError as they do not allow null values. If blank=True, null=True
is specified then, there is no problem.
The operation of ModelForms is such so as to construct insta
Regarding the 'improving error reporting' part, I have started with some
issues which may be comparatively easier:
Improving error reporting
django.forms
#15069
In forms.py:
self._errors[name] = self.error_class(e.messages)
When the list of errors is created, the value of the wrong/invali
On Tuesday, February 25, 2014 5:02:26 AM UTC+5:30, Tim Graham wrote:
>
> "Now I would like to know whether it would be suitable for GSoC?"
>
> Maybe! As these tickets touch many different aspects of Django, I'm
> guessing you'll need to do quite a bit of research in order to convince us
> you h
Hi Prithviraj,
I suspect the reason you haven't had a response is that there isn't much to
respond to here.
Regarding integrating django-secure -- I agree that this would be a
worthwhile activity; it was part of the plan for last year's GSoC project
on the validation framework, but got dropped du
On Tuesday, February 25, 2014 5:02:26 AM UTC+5:30, Tim Graham wrote:
>
> "Now I would like to know whether it would be suitable for GSoC?"
>
> Maybe! As these tickets touch many different aspects of Django, I'm
> guessing you'll need to do quite a bit of research in order to convince us
> you h
I am eagerly waiting to hear your comments and opinions.
Thanks,
Prithviraj M Billa
github :: htttp://github.com/Prithvirajbilla
blog:: http://blog.prithvirajbilla.com
On Sunday, February 23, 2014 9:34:15 PM UTC+5:30, Prithviraj Billa wrote:
>
> Hello Guys!
>
>
> I am planning to work on devel
"Now I would like to know whether it would be suitable for GSoC?"
Maybe! As these tickets touch many different aspects of Django, I'm
guessing you'll need to do quite a bit of research in order to convince us
you have the breadth of experience to tackle them all. Some of those
tickets also have
On 24 févr. 2014, at 21:52, anubhav joshi wrote:
> 2.) There it says: "Import errors discovered during application loading
> during can be masked under certain circumstances."
> If I could get a better explanation of this, it would be very helpful.
>
> Also If I could get an answer to the above
Also there were many links to those tickets which were closed because
either they were "fixed" or they "wontfix". So I have removed those as they
were unnecessary on that wiki.
2.) There it says: "Import errors discovered during application loading
> during can be masked under certain circumsta
On Monday, February 24, 2014 9:45:30 PM UTC+5:30, Tim Graham wrote:
>
> A starting place for this would be to bring the BetterErrorMessages wiki
> page up-to-date by removing items that have been fixed or "won't fixed".
> Then it'll be easier to see what's left and whether or not there is enoug
A starting place for this would be to bring the BetterErrorMessages wiki
page up-to-date by removing items that have been fixed or "won't fixed".
Then it'll be easier to see what's left and whether or not there is enough
to fill 12 weeks.
On Monday, February 24, 2014 10:43:04 AM UTC-5, anubhav
Hi all,
I had submitted a proposal earlier also related to
aggregation/annotation but since almost major things had been implemented
by him, I am thinking to switch to 'improving error reporting'.
I am going through the errors mentioned. I have some questions for now.
1.) The two proble
Hello Guys!
I am planning to work on developing and improving the security features of
Django.
I would like some help in formalizing the proposal so that it will meet the
requirements.
Things i understood how security against csrf works and how it is
implemented in django. (please correct
I wanted to work on improving the djangobook by making certain applications
based on every module of the djangobook which will help a beginner to get
along with various features Django.
Example:use of JSON API in the Web Framework Django
Sample apps are in my Repository: *https://github.com/dee
54 matches
Mail list logo
