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
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
