Allow stopwords in slugs generated by ModelAdmin.prepopulated_fields

[Andy Chosak]

Automatic slug generation in ModelAdmin via ​prepopulated_fields uses a ​urlify.js file which, among other behaviors, ​removes certain stop words from the slug. For example, a string like "To be or not to be, that is the question" will generate a slug "be-or-not-be-question", not "to-be-or-not-to-be-that-is-the-question" as one might expect.

For reference, the current list is: a, an, as, at, before, but, by, for, from, is, in, into, like, of, off, on, onto, per, since, than, the, this, that, to, up, via, with.

The current list of stopwords being removed seems to have been the same since at least 2005 (the earliest code I can find including this logic). Some of these words feel a little unexpected, for example “before” and “since”. It seems likely that stop word removal was introduced for SEO purposes, but this no longer seems to be a modern best practice. I propose removing this behavior so that these words are no longer stripped from slugs generated via prepopulated_fields.

I posted this proposal to ​https://groups.google.com/forum/#!topic/django-developers/9ayU7fTuuAM and received one supportive reply from Adam Johnson. @Scotchester and I have collaborated on a patch.

(#30538 mentions this behavior as part of a more general comparison between urlify.js and Python slugify. It was closed as wontfix due to reasons of backwards compatibility. This ticket specifically addresses stopword removal in the JS code only, not any other differences in behavior between these two methods.)

[Scott Cranfill]

Patch is available for review at: ​https://github.com/django/django/pull/12785

[Mariusz Felisiak]

IMO it's a duplicate of #11157. Changing this behavior would be backward incompatible, and similar issues were closed as wontfix multiple times in the past. I'm not sure if one supportive comment is enough to reopen #11157, we should reach a strong consensus and on the mailing list.

[Scott Cranfill]

Hi Mariusz,

Thanks for your feedback. Andy and I weren't sure how long to wait for more feedback on the mailing list discussion we opened, so we thought starting the ticket and offering a patch might move things along. Happy to take the discussion back there, but I will respond to your comment here, since you haven't commented there yet.

We respectfully disagree that this is a duplicate of #11157. That ticket was more general, addressing the question of whether slugify and URLify should behave the same. The issue we are raising is about changing a specific behavior that exists only in URLify, independent of anything to do with slugify.

Looking forward to further discussion!

[Mariusz Felisiak]

Scott, we have multiple tickets about slugify and URLify that we can basically split them into two categories, language specific behavior and inconsistency. #11157 is about inconsistency with stopwords, your propose is to not strip stopwords which will make their behavior consistent. IMO we can treat this as a duplicate.