ActiveSuport::Inflector#parameterize should strip leading/trailing dashes

Great initiative.

But consider that the separator can be configured, so hard-coding it for dashes is not optimal. So /...#{Regexp.escape(sep)}.../ might be a better idea.

Also, while this method is improved, squeezing of the separator should probably be added – so "foo - bar" becomes "foo-bar" and not "foo---bar".

http://github.com/henrik/slugalizer has all this implemented, with tests.

The squeezing part won't translate directly to the Rails code because Slugalizer limits the separator to a single character, and Rails parameterize doesn't. So either Rails could be made to limit it to one character, or the squeeze could be rewritten as a regexp.

You are right about the separator. I'll post another patch soon.

The squeezing is already there, but it seems that there are no tests for it. I'll add some.

I didn't know about slugalizer. What about making it part of rails and doing all this stuff with it?

Cool, thanks. Slugalizer is very similar to the current version of parameterize. Copying the Slugalizer wholesale would save some work -- the Rails team are free to do so.

On Fri, Sep 12, 2008 at 6:09 PM, Lighthouse support@lighthouseapp.comwrote:

Ok, great,

So this is a new patch that replaces the original code of parameterize with code from slugalizer (just slightly modified for readability). It also adds few more tests.

just fixed error in commit message

Hello,

here is the updated patch.

Is iconv available on all platforms we support?

I also believe that iconv had some strange behaviour with cases Adam's aware of?

On Linux (at least some Linuxes, but not OS X), iconv will not properly decompose characters, so "föö" will become "foo" on OS X but "f" on Linux.

Have noticed this myself, and also seen it mentioned here: http://blade.nagaokaut.ac.jp/cgi...

a 10x performance difference is quite considerable though, so the iconv version could be worth considering...

One possibility is to sniff for OS or something else (if someone can figure out exactly where the issue lies) and use different normalizers based on that. Obviously this would make the code more convoluted.

Might not be a huge win in practice, though, since I would guess a lot of people use OS X (which can use iconv) for dev only, and Linux (which would not use iconv) for production. Then again faster dev is always nice, if you would use this method enough to notice.

Another possibility is to match the input string against some regexp and run it through iconv if it only contains characters iconv can handle. So people who only ever do unaccented strings get speed, and people who work with the full Unicode palette get their decomposition. Also more convoluted, and not sure it would make for a net speedup, but seems likely.

Iconv has more robust transliteration. For example, the German character "ß" is transliterated as "ss" in Iconv (which is correct), but is simply removed if mb_chars.normalize(:kd)... is used. There are several more characters like this, that does not contain any diacritics, but are still outside of 7-bit ascii set.

This can be fixed by creating custom transliteration table for these characters, but that would be messy.

So Iconv is better solution, but has issues on some platforms as Henrik pointed out (i've also noticed this in the past). Not sure what to do with it though...

We could also extract the normlization and transliteration into another inflector method, and isolate the optimisations in there?

We already do something similar to this with sanitize where if there's no "<" chars we return the string unmodified.

Sounds like a good idea.

OK, so we need a name for the 'asciify' method (not asciify ;)) and a suggested test for choosing between the two options.

We can do it when the file is required, so it doesn't have to be fast.

OK, so we need a name for the 'asciify' method (not asciify ;))

What about transliterate?

Quick proof of concept for transliterate. Needs tidying up before it's applied but hopefully it doesn't break anyone's stuff.

Can you guys tests with your platforms where iconv is broken.

Plus, will require 'iconv' always work? if not what situations are there where it's broken?