Page MenuHomePhabricator

Timestamp is grammatically wrong [regression]
Closed, DuplicatePublic

Details

Reference
bz46541

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 22 2014, 1:17 AM
bzimport set Reference to bz46541.
bzimport added a subscriber: Unknown Object (MLST).

What does "is grammatically wrong" mean exactly, or where can I see it?

It's at the header of a feedback-entry, words are in a wrong case. It displays how old feedback is.
examples are: "vor 2 Tage", "vor Ein Monat"

This applies to all output of MWTimestamp::getHumanTimestamp() as described in bug 45385.

mr.heat wrote:

To explain this for English readers:

This works in English: "1 day ago", "2 days ago". It does not work in German because of inflection: "vor 1 Tag" is right but "vor 2 Tage" is wrong. This must be "vor 2 Tagen".

A simple solution is to change the German translation to "Alter: 2 Tage" ("age: 2 days"). But this does not look nice. And it's currently not possible to change this because it is fixed in the code.

Better solution: Don't use the existing translations. Introduce your own translations.

The situation of getHumanTimestamp() confuses me: that bug was marked fixed. TMg and se4598, before you completely forget how AFT looks like ;) could you tell if this had been fixed or not and what was left to do?

By testing against enwiki:
I see "Vor 2 Tagen" and "Vor 1 Monat", which is now correct. "Vor 1 Tag" and "Vor 1 Monat" isn't as nice as "Vor einem Tag" and "Vor einem Monat" would be but I think it's not longer an real bug with AFT.

What still makes me wonder: Why does this not display "yesterday" (instead of "1 day ago") or "monday at" as suggested it would happen in the current code of getHumanTimestamp() of MW and why is the "Vor" in i.e. "Vor 1 Tag" starts uppercase, not lowercase? I don't see where this could come from.

I'm sure there was a time where the above was displayed correct (I just found an old local mw-installation where it displays "yesterday", based on git checkout of mw and aft around 1.22alpha).

So basically it's mostly resolved fixed, but there's probably still an issue in the way AFT calls getHumanTimestamp() or in getHumanTimestamp() itself, but in this should be catched by the testcase of timestamp-class as far as I understand all this. -> I have no clue why it is not like it should be.

(In reply to comment #5)

So basically it's mostly resolved fixed, but there's probably still an issue
in
the way AFT calls getHumanTimestamp() or in getHumanTimestamp() itself, but
in
this should be catched by the testcase of timestamp-class as far as I
understand all this. -> I have no clue why it is not like it should be.

Check bug 55886 please.

I think we should clearly specify what "human timestamp" should be, especially given i18n issues.

[Lowering priority to reflect reality, as AFTv5 is not very actively being worked on anymore.]

Jdforrester-WMF subscribed.

All development work on AbuseFilter v.5 (and indeed, previous versions) is halted. The project is archived, so having open tasks is inappropriate. Consequently, I'm closing all tasks.

SamanthaNguyen moved this task from Backlog to i18n on the ArticleFeedbackv5 board.
SamanthaNguyen edited subscribers, added: ashley, SamanthaNguyen; removed: wikibugs-l-list.

Reinvestigating per T146253

So this is an old bug and I didn't look too closely into this, but this sounds like it's related or possibly even a duplicate of T133468: Language::getHumanTimestamp does not do what it says it should do.

I don't know what T133468 actually means (does that task care about grammaticality?) while this task is rather specific, so merging this way seems to add confusion.