EvanHahn / HumanizeDuration.js

361000 becomes "6 minutes, 1 second"
https://evanhahn.github.io/HumanizeDuration.js/
The Unlicense
1.65k stars 175 forks source link

Add support for short Vs long dates form #59

Closed evilaliv3 closed 9 years ago

evilaliv3 commented 9 years ago

While getting feedback from an hungarian collaborator I got the feedback that it would be valuable to add to the library the possibility for to write a short form and a long form for dates.

Here follows the mail really full of interesting details:

In hungarian for exact number there is only the singular version was used.
for year we have 'év' and for years we have 'évek' but 'évek' is only used with the amount of small ('kevés') or few ('néhány').

The documentation shows much more possibilities, which need to be  implemented in the JS side
Just checked a code i think you need also add the defaults to the definitions.

I think from the function humanizer(passedOptions) 
section the delimiter and the spacer should be moved to the language definitions, just because as coder you dont want to know, how a time in string is delitimted or spaced in a specific language.

for example, if you would like to make a sofware in english and hungarian, then we should have the followign two section

An English example:
language: "en",
delimiter: ", ",
spacer: " ",

A possible Hungarian version can be:
language: "hu",
delimiter: "és ", 
spacer: " ", //6 óra és 8 perc

in Hungarian if you have only two values, its possible to use the 'és' as delimiter, but looks stupid, if you have 3 values.
Ok: 5 év és 3 hónap (5 years and 3 months.) NOT OK: 5 év és 3 hónap és 6 nap és 8 perc (...6 days 8 minutes).
OK: 5 év, 3 hónap, 6 nap, 8 perc

I am saying to move this to the language definitions, because its a translator specific knowledge, which should be not known by a developer. A developer should just set the languege, and get the correct value, without any knwoledge on that langauge.

Looking more on the code, it was not realy clear for me how the numbers were handled. Just because you need to nkown that with the example 
humanizeDuration(1200) // "1.2 másodperc" 
is not okay. Just because in hungarian the integer part separator is coma, the correct hungarian should be the "1,2 másodperc".
This is also language specific, like the thousand separator, which is " "(space) in hungarian, both of them should moved to the lang defs.. 
I didn't tested the code to working wrong, because i dont have dev environment here.
(it can be a good help for the tranlsators, if you put a html page on the github, which has a form to enter values, select language, hit a submit button then get test results.)

To make it more colorfull, when you are using part values, the separtor should be again 'és'
'4 év, 6 hónap, 6 nap és 1,5 óra' (4y,6m,6d,and1.5hour) is okay, but '4 év, 6 hónap, 6 nap, 1,5 óra' looks stupid because the congestion of comas came from the separator and from the number. 
But this is also a language knwoledge and should be moved to the lang defs. :)

As engineer, i also look good if i can get a standard SI result. (If you want implement SI display, you give the "SI" as language code, and gave you that standard. :) 
Maybe a default included SI def is usefull for the developers using this javascript code.

( I think its a fortune, until maya language support you dont need to recalculate the value to nongregorian values, because in Maya 1 uinal is 20 days long. :) )

The documentation is realy great, and shows me a great possible use of the javascript, which i think should be implemented in the langdefs too.

This possiblity was the shortEnglishHumanizer.
With a little more lang definition its possible to give the developer to use short version in more language

shortHu will looks like this:

    shortHu: {
      year: function() { return "é"; },
      month: function() { return "hó"; },
      week: function() { return "hét"; },
      day: function() { return "n"; },
      hour: function() { return "ó"; },
      minute: function() { return "p"; },
      second: function() { return "mp"; },
      millisecond: function() { return "ezredmásodperc"; },

Yes, for the shortest time unit in Hungaran there is no short version. :) If you have to display 618 milliseconds in hungarian in short you should display '0,618 mp'.

So could we add to the langauge specific defintions the followings:
integer separator
thousand separator
default delimiter
default separator
short versions

And to request some stupid also :), if it will be support the ISO639-2 language code, then i did the klingon:

    tlh: {                                      //ISO639-2 code for Klingon
      year: function() { return "DIS"; },
      month: function() { return "jar"; },
      week: function() { return "Hogh"; },
      day: function() { return "jaj"; },
      hour: function() { return "rep"; },
      minute: function() { return "tup"; },
      second: function() { return "lup"; },
      millisecond: // no miliseconds, display it as part seconds

//fortunately klingon has no plural form specialites.

:)
EvanHahn commented 9 years ago

I split this up into #60 and #61.

I don't fully understand the distinction between short and long-form Hungarian durations. Do we want two separate languages, like this?

humanizeDuration(1234567, { language: 'shortHu' })
humanizeDuration(1234567, { language: 'hu' })

Or should the language definition look more like this?

hu: {
  year: function(c) {
    if ((c < 3) && (c != 1)) {
      return "évek";
    } else {
      return "év";
    }
  },
  // ...
}

Sorry for not understanding Hungarian!

I think I'm going to leave out Klingon support for now ;).

evilaliv3 commented 9 years ago

i think the suggestion by @vargaviktor was to have both hu and shortHu but this is valuable only if for all the languages we want to go for this duplication.

EvanHahn commented 9 years ago

Why would all languages have to do that? Couldn't you just choose short Hungarian if you wanted it?

Is it because we don't want to make developers have to know about Hungarian?

evilaliv3 commented 9 years ago

i mean that in the future for each language we may have an API for asking for 'long', 'short' and providing the long or the short version. for now that we dont's have so any other short versiion we will cause only overhead to the project.

vargaviktor commented 9 years ago

Yes Evan, I think the user of the js should not know about anything in hungarian. Just select the short or long.

Just an idea. 😃 2015.05.10. 19:42 ezt írta ("Giovanni Pellerano" <notifications@github.com

):

i mean that in the future for each language we may have an API for asking for 'long', 'short' and providing the long or the short version. for now that we dont's have so any other short versiion we will cause only overhead to the project.

— Reply to this email directly or view it on GitHub https://github.com/EvanHahn/HumanizeDuration.js/issues/59#issuecomment-100674151 .

EvanHahn commented 9 years ago

@vargaviktor Would you be okay with an API like this, then?

humanizeDuration(1234567, { language: 'shortHu' })
humanizeDuration(1234567, { language: 'hu' })
evilaliv3 commented 9 years ago

@EvanHahn it does not make sense for me. i mean as adopter of the library in my application i've a list of languages supported let say: it, pl, hu as example i would like to configure humanizer to configure humanize to use the short and then depending on a scope variable e.g. $scope.language have the respective translation applied. so the language will be always hu, but depending on a global variable setting all languages will provide the shorter form or the longer form.

evilaliv3 commented 9 years ago

anyway for a metter of semplicity i think eventually it would be better to not integrate the shorter version now and eventually evaluate if we would like to have this feature for all the languages or not and how much is relevant.

evilaliv3 commented 9 years ago

the reason is that currently the library has already some limit due to the fact that in dates the order of the date components are not the same in each languages. e.g the ordered form DAY/MONTH/YEAR in some countries is written MONTH/DAY/YEARS an currently the library does not take in account this thing.

given that i see the shorter form an addition feature not functional to the scope of the library that should focus eventually on the problem described above befor adding additional features like this.

evilaliv3 commented 9 years ago

@vargaviktor do you hava any clue on this?

vargaviktor commented 9 years ago

Hi,

I think the short form is not critical. Can live.without it. 😃

In Hungary, we write dates in this form year month day. 😃 2015.05.10. 23:25 ezt írta ("Giovanni Pellerano" <notifications@github.com

):

@vargaviktor https://github.com/vargaviktor do you hava any clue on this?

— Reply to this email directly or view it on GitHub https://github.com/EvanHahn/HumanizeDuration.js/issues/59#issuecomment-100703762 .

EvanHahn commented 9 years ago

Okay. Sounds like I can close this issue for now (and work on #60 and #61)?

evilaliv3 commented 9 years ago

ok!