Christoph Hermann

I think if we change the behaviour of `underscored` we should change `dasherize` too. WIth your change they would behave differently. i.e. ``` js dasherize('oneAtATime'); // => 'one-at-a-time' dasherize('ATime'); //...

With 3.0 we moved to gulp, but build instructions would be nice for gulp too.

Hi, The problem is `underscored`. Humanize uses `underscored` and replaces all the underscores. ``` js equal(_('ThisIsATest').underscored(), 'this_is_a_test'); // actual: this_is_atest ``` If we fix `underscored` `humanize` will work correct to.

no problem ;-)

Sounds interesting. Do you want to make a PR?

@lokson Thx for your awesome work! Will review tonight.

This would be awesome :+1:

How should we handle variadic functions like f.e. [`camelize`](https://github.com/epeli/underscore.string#camelizestring-decapitalizefalse--string)?

From a `decamelize` I would expect the API to be something like `decamelize(string, [separator="_"])`. `underscored` doesn't take a separator and it would make no sense to change the API of...

I don't think we will offload our implementations to Lo-Dash since underscore.string will be a fully standalone library in version 3.0 (#359) and as such should implement all relevant methods.