Re: Proposal: Allow stopwords in slugs generated by ModelAdmin.prepopulated_fields

The PR was merged! Thanks everyone for your input and assistance. On Wednesday, May 20, 2020 at 12:51:56 PM UTC-4, Scott Cranfill wrote: > > Thanks for the additional feedback, folks! > > We have opened a fresh PR, rebased on the latest master and referencing > #11157, at

Re: Proposal: Allow stopwords in slugs generated by ModelAdmin.prepopulated_fields

Thanks for the additional feedback, folks! We have opened a fresh PR, rebased on the latest master and referencing #11157, at https://github.com/django/django/pull/12945 Best, Scott On Saturday, May 16, 2020 at 5:25:29 AM UTC-4, Adam Johnson wrote: > > There's a bit more support now, and

Re: Proposal: Allow stopwords in slugs generated by ModelAdmin.prepopulated_fields

There's a bit more support now, and there have been no opinions against it. Because of this I've reopened the older closed ticket #11157: https://code.djangoproject.com/ticket/11157 . Andy/Scott, I hope you can retarget your PR as per my comment there. Thanks! Admin users still get a preview of

Re: Proposal: Allow stopwords in slugs generated by ModelAdmin.prepopulated_fields

I very much prefer a slug "to-be-or-not-to-be-that-is-the-question" than "be-or-not-be-question" (which doesn't make sense). אורי u...@speedy.net On Wed, Apr 8, 2020 at 11:35 PM Andy Chosak wrote: > Automatic slug generation in ModelAdmin via prepopulated_fields >

Re: Proposal: Allow stopwords in slugs generated by ModelAdmin.prepopulated_fields

I'm in favor of the change. It seems to me that most slugs I see these days have stop words in them and they read better because of that. I don't think JavaScript warnings would be helpful. A release note is sufficient. Admin users still get a preview of the slug and can edit it if needed. On

Re: Proposal: Allow stopwords in slugs generated by ModelAdmin.prepopulated_fields

Does anyone else have an opinion on whether or not we should still be removing these stopwords? Hopefully someone more involved in i18n can weigh in. > I'm not sure if there are any i18n concerns here. In fact, ceasing this practice removes the impetus for the recurring issues being raised

Re: Proposal: Allow stopwords in slugs generated by ModelAdmin.prepopulated_fields

I agree with Mariusz on the ticket/PR that my answer alone isn't enough impetus to make this change. Hopefully someone more involved in i18n can weigh in. Although it changes the order of operations, I think this still works to achieve the same behaviour. This snippet can be run at the end of a

Re: Proposal: Allow stopwords in slugs generated by ModelAdmin.prepopulated_fields

Thanks, Adam, for your reply. I've opened a ticket at https://code.djangoproject.com/ticket/31511, which includes a link to a PR that makes this change. Any advice on documenting how to wrap window.URLify? Thanks, Andy On Thursday, April 9, 2020 at 1:41:30 PM UTC-4, Adam Johnson wrote: > > I

Re: Proposal: Allow stopwords in slugs generated by ModelAdmin.prepopulated_fields

I for one am quite surprised to learn the admin has this behaviour. I'm extra surprised it assumes it's in English if only ASCII letters are used. This is quite a naïve assumption  (See what I did in that sentence?) Was removal of these words introduced for SEO reasons? > Seems likely.

Proposal: Allow stopwords in slugs generated by ModelAdmin.prepopulated_fields

Automatic slug generation in ModelAdmin via prepopulated_fields uses a urlify.js