Nice. Shouldn’t the to_s go right after “string”, though?

to_s is to convert the Multibyte::Chars back to a string after normalization.

tarmo: Ah, right. A to_s after “string” would make it more robust for input like nil or numbers, but that might not be desired.

I’m not sure the nil safety is warranted. 99.999% of people will call this with String#parameterize, not Inflector.parameterize…

This method should also collapse multiple occurrences of the separator (‘foo—-bar’ => ‘foo-bar’) and strip leading/trailing occurrences (‘foo-bar’ => ‘foo-bar’).

A couple of considerations. When $KCODE isn’t set to UTF-8 in Ruby <= 1.8.6 this will break because normalize isn’t defined on String. Parameterizing non-ASCII strings results in a blank string: ‘おはよ’.parameterize => ‘’. I know that non of the other inflector methods support non-ASCII characters, what’s the verdict on this?

I updated Slugalizer based on some of the code traded in the parameterize comments. The biggest change was that is now turns e.g. “foo@bar.com” into “foo-bar-com” instead of “foobarcom” – but it still squeezes multiple separators and removes leading/trailing separators, so " ! foo—dash@bar.com ! " becomes “foo-dash-bar-com”.

I think the current version of Slugalizer has no downsides compared to the current version of parameterize, but it also handles the stuff tomstuart mentioned. It also works with other $KCODEs than ‘u’, that I can tell.

While I do think it’s good to keep it lean, if this method should be present at all, it might as well be as good as it can be – at least as long as it’s just a matter of another short line or two of code.

Regarding the blank string, I think that’s perfectly reasonable. It would certainly be more useful if Japanese etc were transcribed, but I think then we’re firmly in plugin country (see Stringex).

Thanks, NZKoz!

Also check this ticket