Allow pluralizing admin URLs

[Al Johri]

It seems like some of the official documentation suggests using plural model names in the url as a convention such as /articles/1/ but the admin uses singular model names and this option is not configurable. It seems like its been this way since for a very long time browsing through the commit history (pre-2008).

I propose allowing the user to use the model's default_related_name (plural of the model name) as opposed to the model._meta.model_name that is being used now in a configurable option.

This is the line that currently sets the url in the admin: ​https://github.com/django/django/blob/255fb992845e987ef36e3d721a77747a0b2df620/django/contrib/admin/sites.py#L251

This doesn't seem like a difficult change and allows for more consistent urls.

[Tim Graham]

I don't see much advantage to the additional complexity. The admin doesn't need perfect URLs, in my opinion. Feel free to raise the idea on the DevelopersMailingList to get other opinions. You could also ​customize these URLs in your own AdminSite.

[Aymeric Augustin]

I'm not convinced it's worth breaking every admin URL — lots of people bookmark these — just for this reason.

Also using the singular for the changelist view means that if you're on the changeform view, you can chop off the number and get to the changelist view. Some people do that.

[Al Johri]

Replying to aaugustin:

I'm not convinced it's worth breaking every admin URL — lots of people bookmark these — just for this reason.

Also using the singular for the changelist view means that if you're on the changeform view, you can chop off the number and get to the changelist view. Some people do that.

I was thinking that this can just be configurable as opposed to breaking every admin URL. The default can be changed in the next (major?) release and for new projects via settings.py.

Wouldn't that still work? If you're on /articles/1/change/ (changeform view) you can move to /articles/ (changelist view)?

[Simon Charette]

The default can be changed in the next (major?) release and for new projects via settings.py.

The bar to introduce new settings is pretty high as they're another global switches we need to account for in the test suite. As others have already stated I'm not convinced this is worth the additional complexity.