Antonio Cavedoni wrote: > So this would be no good. > > Perhaps I’m missing something but unicodedata won’t cut it.
This is my point. Cut what exactly? "No good" for what exactly? We could file patches to see what sticks, but it might be better to figure what's wanted first, instead of playing fetch me a rock. A slug function can range from a regex replace to a complete text normalization/decomposition/lookup service that will never be enough because even unicode+mappings aren't a complete solution. If it's the full unicode+mappings case, I'm doubtful that processing should be done on the client, not only because the unicode database is large, but also because the server will have a well tested setup via unicodedata. If there's a need to keep the slug current behaviour, fill out as you write as opposed to fill out on the server, that suggests an ajax callback to the server to get at unicodedata. If a latin1 hack is enough, that can be sent down to the client in the admin js. RT editors like fck do this all the time with entity replacements. No need to use Python if we're dealing with a small subset. Mappings: yes, ord/text mappings are grand (Greek, Russian, Turkish of the top of my head would be good inbuilts, as would latin if a unicode db isn't used). If there's a need for mapping extension, there needs to be a place for people to put dictionaries. If the code falls into an else because it has no lookup, does it insert a stringified hexcode or blank the character out. Etc. cheers Bill --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
