Closed evilaliv3 closed 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 ;).
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.
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?
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.
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 .
@vargaviktor Would you be okay with an API like this, then?
humanizeDuration(1234567, { language: 'shortHu' })
humanizeDuration(1234567, { language: 'hu' })
@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.
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.
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.
@vargaviktor do you hava any clue on this?
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 .
Okay. Sounds like I can close this issue for now (and work on #60 and #61)?
ok!
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: