Re: [GSoC 2014 proposal]. Improving admin translation and formalizing Meta objects.

[Adam Mesha]

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 "Добавить нов*ую* Статью"
> for "Add new Article" and "Добавить нов*ый *Пост" for "Add new Post".
>

The problem is a lot more complicated in that, because in addition to
gender agreement, in Russian and a lot of languages you need to use the
accusative and not the nominative in sentences like this ("post" happens to
have the same form here but "article" changes from статья to статью).
Moreover, whatever the set of forms you decide to allow to be defined in
the admin, there will always a language which needs another form.  And one
language may need one form in a given sentence while another language needs
a different form in that sentence (say a genitive versus a dative), so you
need to allow the translator to say which form is going to be used in the
sentence, not the programmer.  So it's quite a complicated problem if you
really want to allow high quality translations.

-- 
Adam Mesha 
Life is either a daring adventure, or nothing. - Helen Keller

-- 
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAPFOCZd2odvutE7Fnr5S9zDcVPEFm-ncPq9-Ae%3DGPjvcW%3DGbjg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add support for get_or_none?

[dude]

+1, cool idea!

everybody write a lot of code for try/except block. this feature can help 
shorten code.

14 марта 2014 г., в 4:34, Josh Smeaton  написал(а):

> +1 on get_or_none. It seems to be a pattern that comes up quite a lot in user 
> code, and I know I've had use for it lots of times. Cal, are you thinking of 
> having a loose function get_or_none(qs, args, kwargs), or implementing it 
> directly on the manager? I think it'd make sense to implement on the manager, 
> but the name doesn't "fit" with the other methods available, so perhaps it'd 
> be better to match it up with get_or_create as a simple shortcut.
> 
> Josh
> 
> On Friday, 14 March 2014 04:48:16 UTC+11, Cal Leeming [Simplicity Media Ltd] 
> wrote:
> Sorry yes, you're quite right.
> 
> To be clear - the proposed solution in this thread is to make 
> `.get_or_none()` work exactly the same as `.get()`, with the only exception 
> that None is returned in place of DoesNotExist. All other logic (args, 
> kwargs, exceptions etc) stay exactly the same.
> 
> Cal
> 
> 
> On Thu, Mar 13, 2014 at 5:41 PM, Sean Bleier  wrote:
> I like the implementation referenced in the SO thread, but I would just point 
> out that `.get_or_none()` should accept both *args and **kwargs. `Q` objects 
> can be passed in as arguments to `.get()` and `.filter()`, so it's only 
> natural to allow that for `.get_or_none()`.
> 
> 
> On Thu, Mar 13, 2014 at 10:26 AM, Cal Leeming [Simplicity Media Ltd] 
>  wrote:
> Just read through all those threads/tickets, here's my conclusion.
> 
> #2659 was rejected 8 years ago [1] on the basis that it's a "feature creep", 
> and that it "doesn't offer anything revolutionary". However the same could be 
> said for .first() and .last(), yet those were accepted.
> 
> #11352 was rejected by luke plant 2 years ago [4] based on the suggested 
> implementation in that ticket, which is not the same implementation as what 
> I'm proposing this time round. The design of `get_object_or_none` being added 
> into shortcuts is not a good approach, and was right to be rejected.
> 
> #17546 was rejected 2 years ago [3] on the basis that #2659 and #11352 were 
> rejected, both of which I've addressed above.
> 
> First argument - `first()` and `.last()` have been added, yet the principle 
> behind why they were added is the same as `.get_or_none()`. 
> Second argument - The implementation being suggested in this thread is not 
> the same as what has been suggested in the three rejected tickets.
> Third argument - Thread [2] had mostly positive feedback, but there was no 
> BDFL decision specifically on `get_or_none`.
> 
> If I'm missing something here, please let me know.
> 
> Cal
> 
> [1] https://code.djangoproject.com/ticket/2659
> [2] 
> https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/get_default/django-developers/3RwDxWKPZ_A/mPtAlQ2b0DwJ
> [3] https://code.djangoproject.com/ticket/17546
> [4] https://code.djangoproject.com/ticket/11352
> 
> 
> On Thu, Mar 13, 2014 at 5:05 PM, Shai Berger  wrote:
> On Thursday 13 March 2014 18:45:31 Cal Leeming [Simplicity Media Ltd] wrote:
> > Seems this issue was brought up several years ago, though the thread was
> > later hijacked for other functionality and get_or_none fizzled out.
> > https://groups.google.com/forum/#!topic/django-developers/Saa5nbzqQ2Q
> >
> > In Django 1.6 there were convenience methods added for .first(), for the
> > same principle of not having to catch an IndexError (or in this case, a
> > DoesNotExist error);
> > https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.model
> > s.query.QuerySet.first
> >
> > This seems to be wanted by several users, as seen here;
> > http://stackoverflow.com/questions/1512059/django-get-an-object-form-the-db
> > -or-none-if-nothing-matches
> >
> > Seems to be quite an easy fix, just needs a proper patch.
> >
> > Any thoughts?
> >
> You linked the wrong thread.
> 
> https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/get_default/django-developers/3RwDxWKPZ_A/mPtAlQ2b0DwJ
> 
> https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/first%28%29/django-developers/iaOIvwzUhx4/x5wKtl7Bh2sJ
> 
> I was (and still am) for a get_or_none() that raises an exception when
> it finds multiple objects, but we were overruled.
> 
> Shai.
> 
> --
> 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-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/201403131905.09028.shai%40platonix.com.
> For more options, visit https://groups.google.com/d/optout.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> 

Re: [GSoC 2014 proposal]. Improving admin translation and formalizing Meta objects.

[Andrew Pashkin]

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 needed to 
solve this problem - is some way, in Django, that would allow to inject 
pymorphy in admi, and Django actually has it - for now I think it would be 
enough to override templates of admin and use pymorphy within them. 

On Wednesday, March 12, 2014 10:52:59 PM UTC+4, Алексей Сидаш wrote:
>
> 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 Meta 
> property of Admin-related objects (like ModelAdmins and Inlines, for 
> example) are suitable for storing all the custom letters(Such as "Add new 
> %modelname%") from admin-forms. To get it done, we need formalizing meta 
> objects
>  and 
> adding custom fields for labels in admin forms. then, we only need to make 
> some template changes.This will make admin panel more customizable and 
> translatable. 
>
> Also, I think we may add custom admin widgets for every application, for 
> example, we define a Meta class in application __init__.py, where we make 
> add property widget_template, and add there something custom instead of 
> default links.
> Good luck, thanks for your time. 
>
> P.S. I have got some open-source experience connected with django, see 
> https://github.com/iLikeKoffee/tiny_feedback . It is not ready enough for 
> usage, but you can see my code. I want to make possible adding feedback 
> functionality by couple of shell commands and config variables.
>

-- 
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8390313f-e9c9-48ab-9956-bf40cf846936%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: APPEND_SLASH skip per URL or per base_uri

[Val Neekman]

Yep, $ is required.


On Thu, Mar 13, 2014 at 5:21 PM, Ryan Hiebert  wrote:

> Sorry, auto-send.
>
> In your example, APPEND_SLASH wouldn't add a slash, because the URL in the
> URLConf doesn't have a slash on it.
>
> I figure you probably meant this, though:
>
> url(r'^profile$', views.profile, name='profile', append_slash=False),
>
> (with a dollar sign at the end of the regex pattern).
>
>
> On Thu, Mar 13, 2014 at 4:19 PM, Ryan Hiebert wrote:
>
>> In your example, APPEND_SLASH
>>
>>
>> On Thu, Mar 13, 2014 at 4:12 PM, Val Neekman  wrote:
>>
>>> Some JavaScript frameworks(e.g. AngularJS) remove the ending slash
>>> before making a request.
>>> If APPEND_SLASH = True, then the API would not be consumable by
>>> AngurlarJS.
>>>
>>> Would it be a good idea to add options to disable the APPEND_SLASH
>>> behaviour per *url()*, or per a *base_uri*?
>>>
>>> *Example 1:*
>>> *settings.py:*
>>> APPEND_SLASH = True
>>>
>>> *urls.py:*
>>> url(r'^profile', views.profile, name='profile', append_slash=False),
>>>
>>> *Example 2:*
>>> *settings.py*
>>> APPEND_SLASH = True
>>> APPEND_SLASH_EXCLUDE = ('/api/v1/', '/api/v2/', '/etc/)
>>>
>>> What do you think?
>>>
>>> If the answer is YES, then would it be too late to push a patch up for
>>> inclusion in 1.7?
>>>
>>> Thanks,
>>>
>>> Val
>>>
>>>  --
>>> 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 django-developers@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/e01272a7-585f-42fe-85e5-8b0020aef882%40googlegroups.com
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>  --
> 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 django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CABpHFHRSM%2BwirffyTWVtAn5spojQ%3DY6QWcr%3DHukPnAj-sejgqQ%40mail.gmail.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADy_H8FWs9W7ttYAHinei%2Bz%2B9xkm5pACZq_wPxq2%3DD3_iBSOoQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add support for get_or_none?

[Josh Smeaton]

+1 on get_or_none. It seems to be a pattern that comes up quite a lot in 
user code, and I know I've had use for it lots of times. Cal, are you 
thinking of having a loose function get_or_none(qs, args, kwargs), or 
implementing it directly on the manager? I think it'd make sense to 
implement on the manager, but the name doesn't "fit" with the other methods 
available, so perhaps it'd be better to match it up with get_or_create as a 
simple shortcut.

Josh

On Friday, 14 March 2014 04:48:16 UTC+11, Cal Leeming [Simplicity Media 
Ltd] wrote:
>
> Sorry yes, you're quite right.
>
> To be clear - the proposed solution in this thread is to make 
> `.get_or_none()` work exactly the same as `.get()`, with the only exception 
> that None is returned in place of DoesNotExist. All other logic (args, 
> kwargs, exceptions etc) stay exactly the same.
>
> Cal
>
>
> On Thu, Mar 13, 2014 at 5:41 PM, Sean Bleier 
> > wrote:
>
>> I like the implementation referenced in the SO thread, but I would just 
>> point out that `.get_or_none()` should accept both *args and **kwargs. `Q` 
>> objects can be passed in as arguments to `.get()` and `.filter()`, so it's 
>> only natural to allow that for `.get_or_none()`.
>>
>>
>> On Thu, Mar 13, 2014 at 10:26 AM, Cal Leeming [Simplicity Media Ltd] <
>> cal.l...@simplicitymedialtd.co.uk > wrote:
>>
>>> Just read through all those threads/tickets, here's my conclusion.
>>>
>>> #2659 was rejected 8 years ago [1] on the basis that it's a "feature 
>>> creep", and that it "doesn't offer anything revolutionary". However the 
>>> same could be said for .first() and .last(), yet those were accepted.
>>>
>>> #11352 was rejected by luke plant 2 years ago [4] based on the suggested 
>>> implementation in that ticket, which is not the same implementation as what 
>>> I'm proposing this time round. The design of `get_object_or_none` being 
>>> added into shortcuts is not a good approach, and was right to be rejected.
>>>
>>> #17546 was rejected 2 years ago [3] on the basis that #2659 and #11352 
>>> were rejected, both of which I've addressed above.
>>>
>>> First argument - `first()` and `.last()` have been added, yet the 
>>> principle behind why they were added is the same as `.get_or_none()`. 
>>> Second argument - The implementation being suggested in this thread is 
>>> not the same as what has been suggested in the three rejected tickets.
>>> Third argument - Thread [2] had mostly positive feedback, but there was 
>>> no BDFL decision specifically on `get_or_none`.
>>>
>>> If I'm missing something here, please let me know.
>>>
>>> Cal
>>>
>>> [1] https://code.djangoproject.com/ticket/2659
>>> [2] 
>>> https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/get_default/django-developers/3RwDxWKPZ_A/mPtAlQ2b0DwJ
>>> [3] https://code.djangoproject.com/ticket/17546
>>> [4] https://code.djangoproject.com/ticket/11352
>>>
>>>
>>> On Thu, Mar 13, 2014 at 5:05 PM, Shai Berger 
>>> 
>>> > wrote:
>>>
 On Thursday 13 March 2014 18:45:31 Cal Leeming [Simplicity Media Ltd] 
 wrote:
 > Seems this issue was brought up several years ago, though the thread 
 was
 > later hijacked for other functionality and get_or_none fizzled out.
 > https://groups.google.com/forum/#!topic/django-developers/Saa5nbzqQ2Q
 >
 > In Django 1.6 there were convenience methods added for .first(), for 
 the
 > same principle of not having to catch an IndexError (or in this case, 
 a
 > DoesNotExist error);
 > 
 https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.model
 > s.query.QuerySet.first
 >
 > This seems to be wanted by several users, as seen here;
 > 
 http://stackoverflow.com/questions/1512059/django-get-an-object-form-the-db
 > -or-none-if-nothing-matches
 >
 > Seems to be quite an easy fix, just needs a proper patch.
 >
 > Any thoughts?
 >
 You linked the wrong thread.


 https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/get_default/django-developers/3RwDxWKPZ_A/mPtAlQ2b0DwJ


 https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/first%28%29/django-developers/iaOIvwzUhx4/x5wKtl7Bh2sJ

 I was (and still am) for a get_or_none() that raises an exception when
 it finds multiple objects, but we were overruled.

 Shai.

 --
 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-develop...@googlegroups.com .
 To post to this group, send email to 
 django-d...@googlegroups.com
 .
 Visit this group at http://groups.google.com/group/django-developers.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/django-developers/201403131905.09028.shai%40platonix.com
 .
 For more options, visit https:

Re: APPEND_SLASH skip per URL or per base_uri

[Ryan Hiebert]

Sorry, auto-send.

In your example, APPEND_SLASH wouldn't add a slash, because the URL in the
URLConf doesn't have a slash on it.

I figure you probably meant this, though:

url(r'^profile$', views.profile, name='profile', append_slash=False),

(with a dollar sign at the end of the regex pattern).


On Thu, Mar 13, 2014 at 4:19 PM, Ryan Hiebert  wrote:

> In your example, APPEND_SLASH
>
>
> On Thu, Mar 13, 2014 at 4:12 PM, Val Neekman  wrote:
>
>> Some JavaScript frameworks(e.g. AngularJS) remove the ending slash before
>> making a request.
>> If APPEND_SLASH = True, then the API would not be consumable by
>> AngurlarJS.
>>
>> Would it be a good idea to add options to disable the APPEND_SLASH
>> behaviour per *url()*, or per a *base_uri*?
>>
>> *Example 1:*
>> *settings.py:*
>> APPEND_SLASH = True
>>
>> *urls.py:*
>> url(r'^profile', views.profile, name='profile', append_slash=False),
>>
>> *Example 2:*
>> *settings.py*
>> APPEND_SLASH = True
>> APPEND_SLASH_EXCLUDE = ('/api/v1/', '/api/v2/', '/etc/)
>>
>> What do you think?
>>
>> If the answer is YES, then would it be too late to push a patch up for
>> inclusion in 1.7?
>>
>> Thanks,
>>
>> Val
>>
>>  --
>> 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 django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/e01272a7-585f-42fe-85e5-8b0020aef882%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHRSM%2BwirffyTWVtAn5spojQ%3DY6QWcr%3DHukPnAj-sejgqQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: APPEND_SLASH skip per URL or per base_uri

[Ryan Hiebert]

In your example, APPEND_SLASH


On Thu, Mar 13, 2014 at 4:12 PM, Val Neekman  wrote:

> Some JavaScript frameworks(e.g. AngularJS) remove the ending slash before
> making a request.
> If APPEND_SLASH = True, then the API would not be consumable by AngurlarJS.
>
> Would it be a good idea to add options to disable the APPEND_SLASH
> behaviour per *url()*, or per a *base_uri*?
>
> *Example 1:*
> *settings.py:*
> APPEND_SLASH = True
>
> *urls.py:*
> url(r'^profile', views.profile, name='profile', append_slash=False),
>
> *Example 2:*
> *settings.py*
> APPEND_SLASH = True
> APPEND_SLASH_EXCLUDE = ('/api/v1/', '/api/v2/', '/etc/)
>
> What do you think?
>
> If the answer is YES, then would it be too late to push a patch up for
> inclusion in 1.7?
>
> Thanks,
>
> Val
>
>  --
> 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 django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/e01272a7-585f-42fe-85e5-8b0020aef882%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABpHFHQatxQjPtS_OpEXT%3D59ZRO6qq81ggQ1e6bewsSXqmCSiQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: APPEND_SLASH skip per URL or per base_uri

[Aymeric Augustin]

On 13 mars 2014, at 22:12, Val Neekman  wrote:

> Would it be a good idea to add options to disable the APPEND_SLASH behaviour 
> per url(), or per a base_uri?
> url(r'^profile', views.profile, name='profile', append_slash=False),

Hi Val,

In my opinion this is too specific. The logic for APPEND_SLASH doesn't require 
much code. Just write your own middleware or subclass Django's middleware.

-- 
Aymeric.


-- 
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/BB521ED4-9281-44EF-BD38-D7CE231C00B6%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

APPEND_SLASH skip per URL or per base_uri

[Val Neekman]

Some JavaScript frameworks(e.g. AngularJS) remove the ending slash before 
making a request.
If APPEND_SLASH = True, then the API would not be consumable by AngurlarJS.

Would it be a good idea to add options to disable the APPEND_SLASH 
behaviour per *url()*, or per a *base_uri*?

*Example 1:*
*settings.py:*
APPEND_SLASH = True

*urls.py:*
url(r'^profile', views.profile, name='profile', append_slash=False),

*Example 2:*
*settings.py*
APPEND_SLASH = True
APPEND_SLASH_EXCLUDE = ('/api/v1/', '/api/v2/', '/etc/)

What do you think?

If the answer is YES, then would it be too late to push a patch up for 
inclusion in 1.7?

Thanks,

Val

-- 
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e01272a7-585f-42fe-85e5-8b0020aef882%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add support for get_or_none?

[Cal Leeming [Simplicity Media Ltd]]

Sorry yes, you're quite right.

To be clear - the proposed solution in this thread is to make
`.get_or_none()` work exactly the same as `.get()`, with the only exception
that None is returned in place of DoesNotExist. All other logic (args,
kwargs, exceptions etc) stay exactly the same.

Cal


On Thu, Mar 13, 2014 at 5:41 PM, Sean Bleier  wrote:

> I like the implementation referenced in the SO thread, but I would just
> point out that `.get_or_none()` should accept both *args and **kwargs. `Q`
> objects can be passed in as arguments to `.get()` and `.filter()`, so it's
> only natural to allow that for `.get_or_none()`.
>
>
> On Thu, Mar 13, 2014 at 10:26 AM, Cal Leeming [Simplicity Media Ltd] <
> cal.leem...@simplicitymedialtd.co.uk> wrote:
>
>> Just read through all those threads/tickets, here's my conclusion.
>>
>> #2659 was rejected 8 years ago [1] on the basis that it's a "feature
>> creep", and that it "doesn't offer anything revolutionary". However the
>> same could be said for .first() and .last(), yet those were accepted.
>>
>> #11352 was rejected by luke plant 2 years ago [4] based on the suggested
>> implementation in that ticket, which is not the same implementation as what
>> I'm proposing this time round. The design of `get_object_or_none` being
>> added into shortcuts is not a good approach, and was right to be rejected.
>>
>> #17546 was rejected 2 years ago [3] on the basis that #2659 and #11352
>> were rejected, both of which I've addressed above.
>>
>> First argument - `first()` and `.last()` have been added, yet the
>> principle behind why they were added is the same as `.get_or_none()`.
>> Second argument - The implementation being suggested in this thread is
>> not the same as what has been suggested in the three rejected tickets.
>> Third argument - Thread [2] had mostly positive feedback, but there was
>> no BDFL decision specifically on `get_or_none`.
>>
>> If I'm missing something here, please let me know.
>>
>> Cal
>>
>> [1] https://code.djangoproject.com/ticket/2659
>> [2]
>> https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/get_default/django-developers/3RwDxWKPZ_A/mPtAlQ2b0DwJ
>> [3] https://code.djangoproject.com/ticket/17546
>> [4] https://code.djangoproject.com/ticket/11352
>>
>>
>> On Thu, Mar 13, 2014 at 5:05 PM, Shai Berger  wrote:
>>
>>> On Thursday 13 March 2014 18:45:31 Cal Leeming [Simplicity Media Ltd]
>>> wrote:
>>> > Seems this issue was brought up several years ago, though the thread
>>> was
>>> > later hijacked for other functionality and get_or_none fizzled out.
>>> > https://groups.google.com/forum/#!topic/django-developers/Saa5nbzqQ2Q
>>> >
>>> > In Django 1.6 there were convenience methods added for .first(), for
>>> the
>>> > same principle of not having to catch an IndexError (or in this case, a
>>> > DoesNotExist error);
>>> >
>>> https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.model
>>> > s.query.QuerySet.first
>>> >
>>> > This seems to be wanted by several users, as seen here;
>>> >
>>> http://stackoverflow.com/questions/1512059/django-get-an-object-form-the-db
>>> > -or-none-if-nothing-matches
>>> >
>>> > Seems to be quite an easy fix, just needs a proper patch.
>>> >
>>> > Any thoughts?
>>> >
>>> You linked the wrong thread.
>>>
>>>
>>> https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/get_default/django-developers/3RwDxWKPZ_A/mPtAlQ2b0DwJ
>>>
>>>
>>> https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/first%28%29/django-developers/iaOIvwzUhx4/x5wKtl7Bh2sJ
>>>
>>> I was (and still am) for a get_or_none() that raises an exception when
>>> it finds multiple objects, but we were overruled.
>>>
>>> Shai.
>>>
>>> --
>>> 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 django-developers@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/201403131905.09028.shai%40platonix.com
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
>> 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 django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAHKQagFCyR2GGcY%2BV%2BGzdR%3DKi3P9%2BTVbT4BzVD_bDoJBN1w6Qw%40mail.gmail.com

Re: Add support for get_or_none?

[Sean Bleier]

I like the implementation referenced in the SO thread, but I would just
point out that `.get_or_none()` should accept both *args and **kwargs. `Q`
objects can be passed in as arguments to `.get()` and `.filter()`, so it's
only natural to allow that for `.get_or_none()`.


On Thu, Mar 13, 2014 at 10:26 AM, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> wrote:

> Just read through all those threads/tickets, here's my conclusion.
>
> #2659 was rejected 8 years ago [1] on the basis that it's a "feature
> creep", and that it "doesn't offer anything revolutionary". However the
> same could be said for .first() and .last(), yet those were accepted.
>
> #11352 was rejected by luke plant 2 years ago [4] based on the suggested
> implementation in that ticket, which is not the same implementation as what
> I'm proposing this time round. The design of `get_object_or_none` being
> added into shortcuts is not a good approach, and was right to be rejected.
>
> #17546 was rejected 2 years ago [3] on the basis that #2659 and #11352
> were rejected, both of which I've addressed above.
>
> First argument - `first()` and `.last()` have been added, yet the
> principle behind why they were added is the same as `.get_or_none()`.
> Second argument - The implementation being suggested in this thread is not
> the same as what has been suggested in the three rejected tickets.
> Third argument - Thread [2] had mostly positive feedback, but there was no
> BDFL decision specifically on `get_or_none`.
>
> If I'm missing something here, please let me know.
>
> Cal
>
> [1] https://code.djangoproject.com/ticket/2659
> [2]
> https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/get_default/django-developers/3RwDxWKPZ_A/mPtAlQ2b0DwJ
> [3] https://code.djangoproject.com/ticket/17546
> [4] https://code.djangoproject.com/ticket/11352
>
>
> On Thu, Mar 13, 2014 at 5:05 PM, Shai Berger  wrote:
>
>> On Thursday 13 March 2014 18:45:31 Cal Leeming [Simplicity Media Ltd]
>> wrote:
>> > Seems this issue was brought up several years ago, though the thread was
>> > later hijacked for other functionality and get_or_none fizzled out.
>> > https://groups.google.com/forum/#!topic/django-developers/Saa5nbzqQ2Q
>> >
>> > In Django 1.6 there were convenience methods added for .first(), for the
>> > same principle of not having to catch an IndexError (or in this case, a
>> > DoesNotExist error);
>> >
>> https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.model
>> > s.query.QuerySet.first
>> >
>> > This seems to be wanted by several users, as seen here;
>> >
>> http://stackoverflow.com/questions/1512059/django-get-an-object-form-the-db
>> > -or-none-if-nothing-matches
>> >
>> > Seems to be quite an easy fix, just needs a proper patch.
>> >
>> > Any thoughts?
>> >
>> You linked the wrong thread.
>>
>>
>> https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/get_default/django-developers/3RwDxWKPZ_A/mPtAlQ2b0DwJ
>>
>>
>> https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/first%28%29/django-developers/iaOIvwzUhx4/x5wKtl7Bh2sJ
>>
>> I was (and still am) for a get_or_none() that raises an exception when
>> it finds multiple objects, but we were overruled.
>>
>> Shai.
>>
>> --
>> 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 django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/201403131905.09028.shai%40platonix.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> 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 django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAHKQagFCyR2GGcY%2BV%2BGzdR%3DKi3P9%2BTVbT4BzVD_bDoJBN1w6Qw%40mail.gmail.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 django-developers@googlegroups.com.
Vi

Re: Add support for get_or_none?

[Cal Leeming [Simplicity Media Ltd]]

Just read through all those threads/tickets, here's my conclusion.

#2659 was rejected 8 years ago [1] on the basis that it's a "feature
creep", and that it "doesn't offer anything revolutionary". However the
same could be said for .first() and .last(), yet those were accepted.

#11352 was rejected by luke plant 2 years ago [4] based on the suggested
implementation in that ticket, which is not the same implementation as what
I'm proposing this time round. The design of `get_object_or_none` being
added into shortcuts is not a good approach, and was right to be rejected.

#17546 was rejected 2 years ago [3] on the basis that #2659 and #11352 were
rejected, both of which I've addressed above.

First argument - `first()` and `.last()` have been added, yet the principle
behind why they were added is the same as `.get_or_none()`.
Second argument - The implementation being suggested in this thread is not
the same as what has been suggested in the three rejected tickets.
Third argument - Thread [2] had mostly positive feedback, but there was no
BDFL decision specifically on `get_or_none`.

If I'm missing something here, please let me know.

Cal

[1] https://code.djangoproject.com/ticket/2659
[2]
https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/get_default/django-developers/3RwDxWKPZ_A/mPtAlQ2b0DwJ
[3] https://code.djangoproject.com/ticket/17546
[4] https://code.djangoproject.com/ticket/11352


On Thu, Mar 13, 2014 at 5:05 PM, Shai Berger  wrote:

> On Thursday 13 March 2014 18:45:31 Cal Leeming [Simplicity Media Ltd]
> wrote:
> > Seems this issue was brought up several years ago, though the thread was
> > later hijacked for other functionality and get_or_none fizzled out.
> > https://groups.google.com/forum/#!topic/django-developers/Saa5nbzqQ2Q
> >
> > In Django 1.6 there were convenience methods added for .first(), for the
> > same principle of not having to catch an IndexError (or in this case, a
> > DoesNotExist error);
> >
> https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.model
> > s.query.QuerySet.first
> >
> > This seems to be wanted by several users, as seen here;
> >
> http://stackoverflow.com/questions/1512059/django-get-an-object-form-the-db
> > -or-none-if-nothing-matches
> >
> > Seems to be quite an easy fix, just needs a proper patch.
> >
> > Any thoughts?
> >
> You linked the wrong thread.
>
>
> https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/get_default/django-developers/3RwDxWKPZ_A/mPtAlQ2b0DwJ
>
>
> https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/first%28%29/django-developers/iaOIvwzUhx4/x5wKtl7Bh2sJ
>
> I was (and still am) for a get_or_none() that raises an exception when
> it finds multiple objects, but we were overruled.
>
> Shai.
>
> --
> 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 django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/201403131905.09028.shai%40platonix.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHKQagFCyR2GGcY%2BV%2BGzdR%3DKi3P9%2BTVbT4BzVD_bDoJBN1w6Qw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add support for get_or_none?

[Shai Berger]

On Thursday 13 March 2014 18:45:31 Cal Leeming [Simplicity Media Ltd] wrote:
> Seems this issue was brought up several years ago, though the thread was
> later hijacked for other functionality and get_or_none fizzled out.
> https://groups.google.com/forum/#!topic/django-developers/Saa5nbzqQ2Q
> 
> In Django 1.6 there were convenience methods added for .first(), for the
> same principle of not having to catch an IndexError (or in this case, a
> DoesNotExist error);
> https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.model
> s.query.QuerySet.first
> 
> This seems to be wanted by several users, as seen here;
> http://stackoverflow.com/questions/1512059/django-get-an-object-form-the-db
> -or-none-if-nothing-matches
> 
> Seems to be quite an easy fix, just needs a proper patch.
> 
> Any thoughts?
> 
You linked the wrong thread.

https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/get_default/django-developers/3RwDxWKPZ_A/mPtAlQ2b0DwJ

https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/first%28%29/django-developers/iaOIvwzUhx4/x5wKtl7Bh2sJ

I was (and still am) for a get_or_none() that raises an exception when
it finds multiple objects, but we were overruled.

Shai.

-- 
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/201403131905.09028.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add support for get_or_none?

[Cal Leeming [Simplicity Media Ltd]]

I should just mention, the accepted answer in the SO thread is not the fix
I'm proposing.

I'm thinking something like;
http://stackoverflow.com/a/2021833/1267398

Cal


On Thu, Mar 13, 2014 at 4:45 PM, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> wrote:

> Seems this issue was brought up several years ago, though the thread was
> later hijacked for other functionality and get_or_none fizzled out.
> https://groups.google.com/forum/#!topic/django-developers/Saa5nbzqQ2Q
>
> In Django 1.6 there were convenience methods added for .first(), for the
> same principle of not having to catch an IndexError (or in this case, a
> DoesNotExist error);
>
> https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.models.query.QuerySet.first
>
> This seems to be wanted by several users, as seen here;
>
> http://stackoverflow.com/questions/1512059/django-get-an-object-form-the-db-or-none-if-nothing-matches
>
> Seems to be quite an easy fix, just needs a proper patch.
>
> Any thoughts?
>
> Cal
>

-- 
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHKQagED58k46A83FEee8eGOpX_nWD6PLHxCDvp-LWMrGG5jrA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Add support for get_or_none?

[Cal Leeming [Simplicity Media Ltd]]

Seems this issue was brought up several years ago, though the thread was
later hijacked for other functionality and get_or_none fizzled out.
https://groups.google.com/forum/#!topic/django-developers/Saa5nbzqQ2Q

In Django 1.6 there were convenience methods added for .first(), for the
same principle of not having to catch an IndexError (or in this case, a
DoesNotExist error);
https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.models.query.QuerySet.first

This seems to be wanted by several users, as seen here;
http://stackoverflow.com/questions/1512059/django-get-an-object-form-the-db-or-none-if-nothing-matches

Seems to be quite an easy fix, just needs a proper patch.

Any thoughts?

Cal

-- 
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHKQagEqGR%3DuPNhki1%3D%3DXjA7pT79ur-HJmGiaW%2B6ZdFdMXjt%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSoC 2014 proposal]. Improving admin translation and formalizing Meta objects.

[Baptiste Mispelon]

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 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 right about 
abusing meta with this work, gettext functionality may be enough, 
gettext `context` feature may help. See this question 
. 
We need to make some changes in templates, admin tempates to add 
apropriate context for needed letters.

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 "Добавить 
нов*ую* Статью" for "Add new Article" and "Добавить нов*ый *Пост" for 
"Add new Post".
The suffix (bold) depends on noun's(Model name in this case) 
grammatical gender.
I believe, this problem takes place not only in Russian, but, 
unfortunately, I speak only Russian and English.
One of the solutions is providing *gettext_context* field in model's 
Meta(or in more suitable place) and select aproppriate translation, 
depending on this property using contextual markers 
.



Also, I think we may add custom admin widgets for every
application, for example, we define a Meta class in
application __init__.py, where we make add property
widget_template, and add there something custom instead of
default links.


I don't see any benefit in this, you'll need to explain this in
more detail.



Do you see red line? Here, instad of simple link, some custom 
information may be shown. For example, /"N new users registered in 
last 24 hours"/ and staff like that.


Also, notifications in main page of admin panel may be useful, for 
example: Blog application, where admins can publish posts and users 
can comment them. When post, published by me is commented, Blog 
application pushes new notification, and I can see an active button in 
admin(Something like github notifications).


Thank you for your answer,

Best regards,

Alexey

--
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 
django-developers@googlegroups.com 
.

Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/de489d7d-dd72-42fc-9497-785771ad23a0%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5321A273.1040307%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSoC 2014 proposal]. Improving admin translation and formalizing Meta objects.

[Алексей Сидаш]

> 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 right about abusing 
meta with this work, gettext functionality may be enough, gettext `context` 
feature may help. See this 
question.
 
We need to make some changes in templates, admin tempates to add apropriate 
context for needed letters.
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 "Добавить нов*ую* Статью" 
for "Add new Article" and "Добавить нов*ый *Пост" for "Add new Post".
The suffix (bold) depends on noun's(Model name in this case) grammatical 
gender.
I believe, this problem takes place not only in Russian, but, 
unfortunately, I speak only Russian and English.
One of the solutions is providing *gettext_context* field in model's 
Meta(or in more suitable place) and select aproppriate translation, 
depending on this property using contextual 
markers
.

 
>
>> Also, I think we may add custom admin widgets for every application, for 
>> example, we define a Meta class in application __init__.py, where we make 
>> add property widget_template, and add there something custom instead of 
>> default links. 
>>
>
> I don't see any benefit in this, you'll need to explain this in more 
> detail.
>


Do you see red line? Here, instad of simple link, some custom information 
may be shown. For example, *"N new users registered in last 24 hours"* and 
staff like that.

Also, notifications in main page of admin panel may be useful, for example: 
Blog application, where admins can publish posts and users can comment 
them. When post, published by me is commented, Blog application pushes new 
notification, and I can see an active button in admin(Something like github 
notifications).

Thank you for your answer,

Best regards, 

Alexey 

-- 
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/de489d7d-dd72-42fc-9497-785771ad23a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[GSoC 2014 Proposal] Django admin translation improvements

[Алексей Сидаш]

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 that Meta 
property of Admin-related objects (like ModelAdmins and Inlines, for 
example) are suitable for storing all the custom letters(Such as "Add new 
%modelname%") from admin-forms. To get it done, we need formalizing meta 
objectsand
 adding custom fields for labels in admin forms. then, we only need to 
make some template changes.This will make admin panel more customizable and 
translatable. 
Also, I think we may add custom admin widgets for every application, for 
example, we define a Meta class in application __init__.py, where we make 
add property widget_template, and add there something custom instead of 
this (http://www.djangobook.com/en/2.0/_images/admin_index.png). My email 
is alexeysid...@gmail.com Good luck, thanks for your time.

P.S. I have got some open-source experience connected with django, see 
https://github.com/iLikeKoffee/tiny_feedback . It is not ready enough for 
usage, but you can see my code. I want to make possible adding feedback 
functionality by couple of shell commands and config variables.

-- 
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 django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/dfc60db6-0d60-4af6-9d5a-313b26013517%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.