"Short" option support

[WaveMeUp]

Hello!

I thought that adding a whole new short language is not the best solution for this problem, so I've decided to create a little option for supporting short words.

Usage: humanizeDuration(3692131200000, { short: true })

I've added short words for English and Russian languages, so you can try it for yourself.

The default value for this option is false. We're passing this parameter into the function, which returns shortly words if possible.

I think this method is much more flexible than adding a new language. Looking forward to your opinion.

[EvanHahn]

I'd prefer this to use the existing feature to add new languages. Would that work for you?

[WaveMeUp]

@EvanHahn as I said before, "I think this method is much more flexible than adding a new language", for example, if you're creating Angular JS filter with this library, and want to use multi-language support with short words, my solution is better, especially when you dynamically change a language. I think it's quite common case.

[EvanHahn]

I'm not familiar with Angular filters, so please pardon my confusion here. Because these pseudo-languages are nonstandard, I hesitate to add them to the library. Can you further show me the use case, preferably with code?

[WaveMeUp]

For example, we have a quite complex web application for booking flights. There you can dynamically change languages. Sometimes we need to convert ms to a readable format, and sometimes we need short words. So for this purposes, I've created a really small filter:

angular.module('engine')
        .filter('duration', ['$rootScope',
            function ($rootScope) {
                return function (number, useShort) {
                    return humanizeDuration(number, { language: $rootScope.locale, units: ['d','h','m'], round: true, short: useShort || false});
                }
            }]);

You can use it this way in templates:

{{ 3692131200 | duration}}

And if you want to use short words, just pass an optional parameter to the filter:

{{ 3692131200 | duration: true}}

Thanks to dynamic language change (via $rootScope.locale variable) the whole solution is really flexible, and, in my opinion, much more flexible rather than using addition short languages.

[EvanHahn]

Would something like this work?

var humanizer = humanizeDuration.humanizer({
  languages: {
    en_short: {
      y: function () { return 'y'; },
      mo: function () { return 'mo'; },
      // ...
    }
  }
});

angular.module('engine')
        .filter('duration', ['$rootScope',
            function ($rootScope) {
                return function (number, useShort) {
                    var language = $rootScope.locale;
                    if (useShort) {
                      language += '_short';
                    }

                    return humanizer(number, { language: language, units: ['d','h','m'], round: true});
                }
            }]);

[WaveMeUp]

Yes, it will, and I knew that you will write something like that :) But cmon, adding a string? It looks quite silly, in my opinion. Small and nice boolean option and you're doing great. And it also better if your language doesn't have short words yet, it will return full words.

[EvanHahn]

I'm still hesitant to add this for several reasons.

1. You may not find it ideal, but Humanize Duration already has some support for what you're trying to do.
2. Short languages are nonstandard. For example, I might shorten "month" to "mo" where you might shorten it to "m".
3. We'll need to have an answer for languages that don't have shortened versions yet. Your PR only has English and Russian—what about the many other languages this library supports? That seems like an odd quirk of documentation. This will also break across versions as we add short languages unless we add all of them right now.
4. What about languages that don't really need shortening? Japanese and Korean are two languages that don't seem like they can be condensed much.
5. We have CSV files in our tests that enumerate all of the possible options. This will effectively double the amount of these. That's more work for the maintainer of this library (me).
6. It is a new feature of any kind which will require maintenance (again, more work for me).

What do you think?

[EvanHahn]

Because I'm hesitant to add this and there hasn't been movement in a few months, I'm going to close this issue.