Customizable Separator for slugify

[Joe Jasinski]

Hi All,
I'm wondering if anyone would find it useful to allow the slugify
function to take an optional argument that would let us specify what
type of separator to use. Sometimes it might be nice to let slugify
use an underscore instead of a dash. I see that slugify is grouped
with the template filters code so perhaps it's intent is only to be
used as a template tag, but I've seen people using it in raw python
code.

SUGGESTED PSUDOCODE

200 def slugify(value, slug_separator='-'):
....
208 return mark_safe(re.sub('[-\s]+', slug_separator, value))
....


ORIGINAL CODE
http://code.djangoproject.com/browser/django/trunk/django/template/defaultfilters.py

200 def slugify(value):
201 """
202 Normalizes string, converts to lowercase, removes non-alpha
characters,
203 and converts spaces to hyphens.
204 """
205 import unicodedata
206 value = unicodedata.normalize('NFKD', value).encode('ascii',
'ignore')
207 value = unicode(re.sub('[^\w\s-]', '', value).strip().lower())
208 return mark_safe(re.sub('[-\s]+', '-', value))
209 slugify.is_safe = True
210 slugify = stringfilter(slugify)

This is my first post on Django Developers, so I figure I'd introduce
myself. My name is Joe and I'm a Django web developer in Chicago.
I've been working with Django for a few years and find it a lot of
fun!

If this is the wrong place to ask, my apologies. Thanks for reading,

Joe

[dffdgsdfgsdfhjhtre]

99.9% of slugs in the wild use dashes instead of anything else, so an argument to the slugify function would be pointless. At any rate, you can always make a wrapper:

def better_slugify(value, seperator='-'):

    return slugify(value).replace('-', seperator)

[Alexander Artemenko]

It will be much more useful to have customizable slugify function et
all, because django's builtin sligify does not support russian
symbols.

It would be nice to have optional 'SLUGIFY_FUNC' setting to override
the default function. It'll allow me to use slugify from pyutils
module, for example.

On Jan 4, 5:05 am, Joe Jasinski <joe.jasin...@gmail.com> wrote:
> Hi All,
>   I'm wondering if anyone would find it useful to allow the slugify
> function to take an optional argument that would let us specify what
> type of separator to use.  Sometimes it might be nice to let slugify
> use an underscore instead of a dash.  I see that slugify is grouped
> with the template filters code so perhaps it's intent is only to be
> used as a template tag, but I've seen people using it in raw python
> code.

Alexander

[Gabriel Hurley]

Adding Yet Another Setting doesn't seem like much of a solution here.

To the original poster's question I'd say that using anything but dashes for slugify would be very uncommon, but I don't see any reason why the slugify filter *couldn't* take an optional parameter to define what token should be used if some people would find that useful. Providing a patch against trunk with tests and docs are a good way to see it happen.

The issue of Russian (or any other unicode) characters with slugify is an unrelated issue. I wasn't around for the initial creation of the slugify filter, but I'm sure the conversion to ascii in it is because Internet Explorer didn't support IDNs until version 7. While a majority of browsers support IDNs now, it's still not 100%. Off the top of my head I'm not entirely sure what the right solution for Django is for that issue, but there are quite a lot of possible solutions that don't introduce new settings.

All the best,

    - Gabriel

[Gabriel Hurley]

I did actually just come up with two problems involved in having a customizable separator for slugify:

1) SlugField would also have to take a parameter to define the separator so that there wouldn't be inconsistencies in the output of SlugField and slugify. This seems like it would be a big pitfall for potential user error.

2) For users who have been using slugify as-is, but then change to a new separator: if you stored a URL path component in your DB with a SlugField then changed the slugify separator from a dash to a something else, not only would you end up with an inconsistent mix of things in your DB, if you ever tried to reconstruct that same URL using slugify you wouldn't come up with the same result.

    - Gabriel