on_date translation is problematic

[silverwind]

Description

As seen on Crowdin, translators have a hard time translating the on alone in on <date> phrases because some languages don't have a concept of such a word. We should evaluate if there are alternatives and whether we can somehow translate the whole phrase.

[yardenshoham]

Blocked by #23863?

[lunny]

Blocked by #23863?

I don't think so.

[silverwind]

I think the solution will be to never have the time element emit this "on", and instead render the element into the translation string via a token. I also checked the JS Intl API, it seems it also can not emit a "on", it can emit a "at" but that does not help us.

[yardenshoham]

One way to avoid on is to use tense=past whenever possible. Ref #24106

[wxiaoguang]

I would suggest to remove the on prefix from TimeSince, if it is not necessary.

Is there a strong reason to keep it?

[silverwind]

In some contexts the on makes sense to form sentences:

I agree on needs to be removed from TimeSince (and in turn <relative-time>), and these sentences should be formed based on a translation string on %s. where %s than renders the TimeSince.

[yardenshoham]

about the last sentence. Not TimeSince, an absolute datetime is more like template "shared/datetime/short"

[silverwind]

Though, the challenge ist that <relative-time> may or may not output the on <date> format, depending on how far back the date is. So I guess the backend must know as well when the on appears to emit the correct translation to avoid on 5 days ago.

[yardenshoham]

Threshold is configurable

[wxiaoguang]

Quote my comment from #24106

In history , IIRC the TimeSince always used relative date, then <relative-time> changed the behavior.

Now, we just make <relative-time> always use tense=past, then it behaves like the old TimeSince , then everything should be fine, and just like before.

Then we do not need the on either.

Correct me if I am wrong.

[yardenshoham]

If you use template "shared/datetime/short" it will just output the day, no on

[wxiaoguang]

New code:

<td>{{template "shared/datetime/short" (dict "Datetime" .CreatedUnix.FormatLong "Fallback" .CreatedUnix.FormatShort)}}</td>

Old code:

<td><span class="notice-created-time" data-tooltip-content="{{.CreatedUnix.AsTime}}"><time data-format="short-date" datetime="{{.CreatedUnix.FormatLong}}">{{.CreatedUnix.FormatShort}}</time></span></td>

There is no on in old code either. Since this problem couldn't be resolved easily, I would suggest to use the old code's behavior.

[yardenshoham]

I'm fine with tense=past by default, just have to be careful with future dates. @silverwind the problem with this is it will show 4 years ago instead of on April 14, 2019 which you prefer

[silverwind]

Threshold is configurable

Then I think it's clear what needs to be done: Make backend aware of the threshold, and make it output a on %s translation string before the threshold and %s when not.

have to be careful with future dates

Future dates should be treated the same as past dates in regards to the threshold.

[wxiaoguang]

IMO, there are different cases:

1. Only relative time
2. An absolute time without on: a table cell, without context text
3. In a sentence with on

So, only the caller knows whether there should be an on word. As a framework function, TimeSince has better to keep simple.

[yardenshoham]

The first should use TimeSince (relative-time with format="relative"). The second and third should be inserted into a phrase and use a function (we currently have template "shared/datetime/short" which is relative-time with format="datetime")