-
Notifications
You must be signed in to change notification settings - Fork 966
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
German translation #120
German translation #120
Conversation
[InlineData(-3, "vor 3 Stunden")] | ||
[InlineData(-2, "vor 2 Stunden")] | ||
[InlineData(-1, "vor einer Stunde")] | ||
[InlineData(1, "in einer Stunde")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cannot read German but google translate says this means 'in an hour'. If that's correct, which I guess it is considering the positive input for the hour, it shouldn't really be on the HoursAgo
test or maybe we should rename the method to be Hours
so it can fit both past and future entries.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's correct. It missed this, after I've tested some positive input. I've to find a way to test these cases with respect of time zones. Otherwise they will fail, depending on the local time zone. I will remove if for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It shouldn't fail. If you send in UTC date, which is what we're doing here, Humanizer compares against the current UTC date & time. Even if you send in local time you can tell Humanizer it's a local time (using optional utcDate
argument) and it will compare it against the local time. So it should be ok.
Oh, just saw the WIP comment on the description :) I hope you don't mind my premature review then! |
No problem. That was fast. I will make the changes you've requested :) |
I've refrained from adding tests for future dates for now. I've to think about, how to poke with time zone awareness. I've seen you've implemented something regarding this problem (https://github.com/MehdiK/Humanizer/blob/master/src/Humanizer.Tests/DateHumanizeTests.cs#L28) Maybe it's worth to refactor this out, so that it is usable by other tests (should go into another PR). Thoughts? P.S.: I've rebased my changes, so that you've only one commit to merge |
I agree that the verify method could live in a base class for all DateTimeHumanizeTests and that's needed for other locales too. Would be a great second PR. |
You think you could add future date tests as part of this PR? It can later be refactored in the second PR to use the verify method. |
Done |
Awesome. Thanks. I just had a second look at the |
And that came back and bit me in #123!! So we do need that PR to extract the |
This is work in progressReady for review