incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !
Closed, ResolvedPublicBUG REPORT
Actions

Assigned To

Authored By

	Verdy_p
	Dec 3 2020, 9:32 AM

Description

Steps to Reproduce:

Select the ISO 8601 format in your preferences (this is the default if your locale is French for example)
Visit https://phabricator.wikimedia.org/T13267 (this is just an example, I just picked here a bug that was submitted years ago) or just render this bug report page.

You'll see that

years are not displayed, it's impossible to see accurate dates for bugs or comments submitted years ago !
the ISO 8601 format is in fact not used at all, instead the en-US format is used (but with months or abbrevs translated in the user's language, and incorrecly ordered)

Actual Results:

"fév 22 AM, 10:57" (if French is the selected UI language)
- which is complete non-sense (in French days of the month should be *before* the month name, abbreviated here)
- the "AM/PM" makes no sense at all in French: note that the default is already using the 24-hours format.
"Jeu, Fév 22, 10:57" (if instead of the ISO 8601 default we select ISO 8601 explicitly): note that the weekday abbreviation appears, AM/PM disappears, but still incorrect order with day of month incorrectly after the month abbrev, the month abbrev now is incorrectly capitalized, and there's still no years!

Expected Results:

"22 fév 2014, 10:57 UTC" (for the normal French format), or
"2014-02-22 10:57 UTC" (for the ISO 8601, if using the local time from the locale, however the timezone should be displayed, we are not all in the US and even in UK, UTC is not correct across seasons!), or
"2014-02-22T10:57Z" (for the standard ISO 8601 format in the UTC timezone)

In all cases, the format MUST explicitly display the year and the timezone.

Current workaround:

We MUST select the English (US?) locale to see years (sometimes...)
We don't know which timezone is used for time.

So Phabricator is almost unusable in any other language than English for the UI, as we must to be able to track time correctly! In fact ALL occurences of dates formatted in Phabricator are wrong, the formater does not work at all (probably lot of failed assumptions or incorrect management/loading of locale settings).

Capture d’écran 2020-12-03 104355.png (890×759 px, 94 KB)

Capture d’écran 2020-12-03 105348.png (595×837 px, 55 KB)

Capture d’écran 2020-12-03 110025.png (545×1 px, 98 KB)

I note that the date formatter seems to use two different formats:

the first one for recent dates (less than one mon ago, with the weekday added, but no AM/PM, and using inconsistant capitalization of months and no year, assuming this is the current year, or just last year for dates in December in the previous year displayed in January)
and another one for older dates (displaying AM/PM even if it's not needed for the 24-hours format, but still no year!)

Capture d’écran 2020-12-03 110810.png (685×1 px, 106 KB)

The date formater used by Phabricator is a complete mess.

Details

	Subject	Repo	Branch	Lines +/-
	Update translations	phabricator/deployment	wmf/stable	+1 -1

Customize query in gerrit

Related Objects

Mentioned Here: T110: Let users configure date format in account settings
T86464: Change default phabricator time format to something standard (don't use AM and PM)
T13267: User should be able to set fallback language(s) in preferences

Event Timeline

Verdy_p created this task.Dec 3 2020, 9:32 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 3 2020, 9:32 AM

Verdy_p updated the task description. (Show Details)Dec 3 2020, 9:33 AM

Verdy_p updated the task description. (Show Details)

Verdy_p updated the task description. (Show Details)Dec 3 2020, 9:35 AM

Verdy_p updated the task description. (Show Details)

Verdy_p updated the task description. (Show Details)Dec 3 2020, 9:38 AM

Verdy_p updated the task description. (Show Details)

Verdy_p updated the task description. (Show Details)Dec 3 2020, 9:44 AM

Verdy_p updated the task description. (Show Details)Dec 3 2020, 9:48 AM

Verdy_p updated the task description. (Show Details)

Verdy_p updated the task description. (Show Details)Dec 3 2020, 9:54 AM

Verdy_p updated the task description. (Show Details)

Verdy_p updated the task description. (Show Details)Dec 3 2020, 9:56 AM

Verdy_p updated the task description. (Show Details)

Verdy_p updated the task description. (Show Details)Dec 3 2020, 10:01 AM

Verdy_p updated the task description. (Show Details)Dec 3 2020, 10:08 AM

Verdy_p updated the task description. (Show Details)Dec 3 2020, 10:17 AM

Verdy_p updated the task description. (Show Details)

This is basically a report that the French translation of some date formats is broken? I'd love to find the corresponding translation on https://translatewiki.net/w/i.php?title=Special:Translate&group=phabricator&language=fr&action=translate but "Export" says it is limited to 10000 strings only. :-/
Anyway, likely this requires fixing the French translation and translations are managed on translatewiki.net.

In all cases, the format MUST explicitly display the year and the timezone.

No. Timezone is already defined by you in your user preferences.

For any other things, see T86464#5191217 and T110.

Restricted Application added a project: Upstream. · View Herald TranscriptDec 3 2020, 11:17 AM

Note that it is not correct either in English (see the screenshots!). In fact it is broken in ALL locales preferences, which are mixed incorrectly.
Aklapper: did you only check anything before early deciding this was "invalid" when it is easy to reproduce and see? Did you look at the provided screenshots clearly annotated?
Just look at any bug that lags nbehind since long: the dates indicated are insufficient. The code justr makes assumptions about dates not lagging more than 1 month...
I can set the locale to English and it is still all messed.
I I found no date settings in the preferences that work correctly (not even when selecting ISO 8601 explicitly).
And your comment about translatewiki.net is very unlikely. It is correct as it is, but the code of Phabricator certainly makes false assumptions about date formats.

Anyway the contents of Phabricator resources in TWN is much too large, it should have been splitted in submodules: Phabricator is the most complex project to translate there, and I've not seen any string there about the expected date formats.

Verdy_p reopened this task as Open.Dec 4 2020, 5:55 AM

Verdy_p raised the priority of this task from Lowest to Medium.

@Verdy_p: Please do not change priority if you don't plan to work on this.
As explained before, there are no plans to change this, hence the status declined is correct here.

I have noticed this task yesterday and wanted to elaborate but was busy on other things. I believe it should be reopened cause Phabricator has an issue in how it translates date. I gave it a try by setting the language to French and explicitly setting all the date / time preferences:

Timezone	Europe/Paris
Date format	ISO 8601 : 2000-02-28
Time format	24 hours, 14h34
Week start on	Monday

the year is never shown
when setting the time format to 24 hours, the translated time still uses AM/PM, though the hour is in 24 hours format (example: PM, 15:46)
The month / day are in the american order: Jun 14 > Juin 14 instead of 14 Juin.
When I set the date format to 12 hours, the dates repeat the AM/PM field for example: Sep 10 AM, 2:45 AM
Regardless of the date format, the year never show up.

I have tried in a few different languages and only found french to lack year or use AM/PM when using 24 hours format.

If translations are broken then please feel free to improve translations.
https://translatewiki.net/wiki/Phabricator:libphutil-core-e0ac3c4e0da81dab/fr is the one for the date format style like Jan 31 2000
https://translatewiki.net/wiki/Phabricator:libphutil-core-b9e155ecbd143fab/fr is the one for recent (last 30d) style like Fri, Dec 4
Thanks!

Thank you @Aklapper that unblocked me! I am reopening since I forgot to reopen in my previous comment, feel free to drop the Phabricator tag and replace it with an translation related tag.

The related QQQ messages refer to a viewutils.php file that no more exists in libphutil but that seems to match this file:

arcanist/src/utils/viewutils.php

<?php

function phutil_date_format($epoch) {
  $now = time();
  $shift = 30 * 24 * 60 * 60;
  if ($epoch < $now + $shift && $epoch > $now - $shift) {
    $format = pht('D, M j');
  } else {
    $format = pht('M j Y');
  }
  return $format;
}

The letters correspond to the format of PHP function DateTime::format() described at thttps://www.php.net/manual/en/datetime.format.php:

A	Uppercase Ante meridiem and Post meridiem
D	A textual representation of a day, three letters
M	A short textual representation of a month, three letters
j	Day of the month without leading zeros
Y	A full numeric representation of a year, 4 digits

File	Id	PHP Code	French	Code on translatewiki	Resulting
viewutils.php:7	b9e155ecbd143fab	`D, M j`	`Ven, Dec 4`	`D, M j`	`Ven, Dec 4`
viewutils.php:9	e0ac3c4e0da81dab	`M j Y`	`Dec 4 2020`	`M j A`	`Déc 4 PM`

The issue is M j Y got translated to M j A. "year" in french is "année" and I guess the translator changed Y to A not realizing its for AM/PM.

Applying that to the erroneous french date fév 22 AM, 10:57 given by @Verdy_p: the date part is fév 22 AM which comes from the translatewiki message M j A (since the actual date is more than 30 days old (2017)).

So I guess it is all about adjusting: https://translatewiki.net/wiki/Phabricator:libphutil-core-e0ac3c4e0da81dab/fr from M j A to j M Y which would display: 4 Déc 2017 as expected in french.

Note that Turkish seems to be affected as well since it uses A in the date instead of M ( https://translatewiki.net/wiki/Phabricator:libphutil-core-e0ac3c4e0da81dab/tr ):

e0ac3c4e0da81dab

A j Y

@Verdy_p do you have the possibility to adjust the translation on translatewiki? Then we will need to export them, though I don't know how often it happens in practice we can surely trigger a manual update.

If at all possible, we might want to enhance the related qqq messages which currently state:

"b9e155ecbd143fab": "Used in:\n\n[https://secure.phabricator.com/diffusion/PHU/browse/master/src/utils/viewutils.php$7 viewutils.php:7]",
"e0ac3c4e0da81dab": "Used in:\n\n[https://secure.phabricator.com/diffusion/PHU/browse/master/src/utils/viewutils.php$9 viewutils.php:9]",

The links are wrong, the repository they point to no more exist and the code has been moved somewhere else. But maybe those qqq messages are automatically generated.

Hi, we do not track translation issues with single language translations on translatewiki.net in Phabricator Thus closing this task again. Thanks for your understanding.

There's no reason to close this: the translations in TWN are used as part of the installed data for Phabricator and must then be checked. So it is really a bug of the Phabricator project itself, even if this comes from data imported from TWN, but for a translation package created and submitted to TWN by the Phabricator project itself.

You may want to retag this somewhere else, but the initial tags I gave ("Phabricator" and "I18n") were accurate. And this is a real issue.

And the data in TWN (/qqq docs) gave no hints about the source, only a broken link that YOU created here in this project but forgot to maintain.

Really this is a problem of Phabricator's maintenance, suitable for a legitimate bug. But visibly if you don't want accurate translation, why do you submit them to TWN (in a so badly designed format with giant and modules sorted randomly, and with false docs)? The result is then that you are importing translated data blindly from TWN, without nay check, and it's hard to figure out what is wrong.

So please modularize it better, and isolate at least the very short translation units that are likely abbreviations or special formats..

As well you seem to generate very poor keys for these messages, based on a hash, not taking into account at least the source file name from which they originate. Phabricator is very large, and each of its modules as well. Using hashes on too large modules does not help.

In T269339#6670300, @Verdy_p wrote:

And the data in TWN (/qqq docs) gave no hints about the source, only a broken link that YOU created here in this project but forgot to maintain.

@Verdy_p: Cannot follow. Please be specific. What "broken link" (URL)? What do I "forget to maintain"?
Also, you've been pointed several times already to https://www.mediawiki.org/wiki/Bug_management/Phabricator_etiquette . If it's still not possible for you to avoid getting personal (apart from adding long, unstructured, partially off-topic comments), then I suggest that you spend your time somewhere else.

But visibly if you don't want accurate translation

I already explained where you can improve existing translations. I've also explained that Wikimedia (a downstream customer of Phabricator) does not plan to work in this area, and I've already linked to Phacility (upstream developers and maintainers)'s view on this. Not sure how you come to such conclusions.

So please modularize it better, and isolate at least the very short translation units that are likely abbreviations or special formats..

Sorry, there is no capacity in Wikimedia to do so. Maybe upstream is more interested and if they are you are free to work with them.

Aklapper added a project: I18n.Dec 5 2020, 8:00 PM

Nikerabbit subscribed.Dec 5 2020, 8:49 PM

@Aklapper that is a valid defect imho, notably once the translations have been adjusted, we need to deploy them on our Phabricator instance something that definitely falls into our plate. I am keeping the task under my umbrella and will look at getting the fix deployed on our instance.

@Nikerabbit we would need an export of translatewiki to the git repository https://phabricator.wikimedia.org/source/phabricator-translations.git . I checked it, it does not have @Verdy_p fixes yet. Then I guess I can check with @20after4 to get the repo update on our Phabricator.

[removing uninvolved subscriber]

(Regular) translation updates are coming soon.

[wmf/stable b6bdf95] Localisation updates from https://translatewiki.net.
 66 files changed, 1785 insertions(+), 1567 deletions(-)
 rewrite projects/libphutil/core/fr.json (60%)
 rewrite projects/phabricator/notification/fr.json (61%)
 create mode 100644 projects/phabricator/pholio/fr.json

Change 647053 had a related patch set uploaded (by Hashar; owner: Hashar):
[phabricator/deployment@wmf/stable] Update translations

https://gerrit.wikimedia.org/r/647053

gerritbot added a project: Patch-For-Review.Dec 8 2020, 8:24 PM

The phabricator translation infrastructure was not built with much understanding of how translatewiki works so it's no surprise that there is a lot of room for improvement in the way the strings are organized, described and presented. To make matters worse, the upstream recently refactored their library structure, the code that was libphutil has been split up and moved around. Some code was moved into rPHAB Phabricator core and the rest was moved into rARC Arcanist. This likely broke a lot of links and might have orphaned translations.

I think this should be fixed now. @hashar or @Verdy_p can you confirm?

Yes that works! Thank you so much for deploying the fix @mmodell :]

Change 647053 abandoned by Hashar:
[phabricator/deployment@wmf/stable] Update translations

Reason:
Got fixed differently

https://gerrit.wikimedia.org/r/647053

	F33934296: Capture d’écran 2020-12-03 110810.png
	Dec 3 2020, 10:08 AM

	F33934283: Capture d’écran 2020-12-03 110025.png
	Dec 3 2020, 10:01 AM

	F33934265: Capture d’écran 2020-12-03 105348.png
	Dec 3 2020, 9:54 AM

	F33934233: Capture d’écran 2020-12-03 104355.png
	Dec 3 2020, 9:44 AM

incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !Closed, ResolvedPublicBUG REPORTActions

Description

Details

Related Objects

Event Timeline

incorrect display of dates in ISO 8601 format: non-sense displayed everywhere in Phabricator, missing years !
Closed, ResolvedPublicBUG REPORT
Actions