[19:43:05] I'm not sure where the best place to discuss this is. If we're going to generate text from Wikidata, we're going to have to wrestle with ongoing date problems. Examples to follow ... [19:44:33] 1) the ongoing issue with representation of centuries in the format "16. century" in English, which has resulted in editors entering the wrong century values. See discussion at https://phabricator.wikimedia.org/T95553. [19:46:32] Bleh, it's still not fixed? :/ (re @PaulaPKM: 1) the ongoing issue with representation of centuries in the format "16. century" in English, which has resulted in editors entering the wrong century values. See discussion at https://phabricator.wikimedia.org/T95553.) [19:46:51] 2) many description-writing tools (including Mix-n-Match summaries and Reasonator) ignore "sourcing circumstances" and "refine date" qualifiers. [19:49:09] 3) Editors are encouraged to enter a fixed date in the middle of a range and then set a precision (so, enter 1750 and enter precision "century" to display "18.century". The date entered is apparentlt stored but is not visible in the user interface, so an item with DOB = 1. millenium BCE is displayed in M-n-M as "he was born in 500 BCE" [19:49:34] 3) Editors are encouraged to enter a fixed date in the middle of a range and then set a precision (so, enter 1750 and enter precision "century" to display "18.century"). The date entered is apparently stored but is not visible in the user interface, so an item with DOB = 1. millenium BCE is displayed in M-n-M as "he was born in 500 BCE" [19:51:39] 4) WD assumes "13. century" = 1201=1300 and stores 1300 with precision = century. The result is that M-n-M display "She was born in 1300". [19:52:30] I'm not ragging on these tools, but pointing out that our assumption that we can generate descriptions today because these tools do so has some serious issues around dates. [19:54:02] this is why you're paid the big bucks Paula [19:54:33] I am not sure it's fixable. (re @amire80: Bleh, it's still not fixed? :/) [19:55:53] 4) WD assumes "13. century" = 1201=1300 and stores 1300 with precision = century. The result is that M-n-M displays "She was born in 1300". [19:56:39] so where's my check? (re @moebeus: this is why you're paid the big bucks Paula) [19:56:44] Dates are comlicated in many respects. Should the Persian renderers convert Gregorian dates to the official Iranian calendar? [19:57:17] Should we start a page somewhere to collect these date issues? I am sure there are more. [19:59:10] Well, you could start a page under https://meta.wikimedia.org/wiki/Abstract_Wikipedia ? [20:01:03] 4a) and one of the tools then displays this as 1300s, making it a full century off. (re @PaulaPKM: 4) WD assumes "13. century" = 1201=1300 and stores 1300 with precision = century. The result is that M-n-M displays "She was born in 1300".) [20:02:09] Happy to, if that's where we want it. (re @Arthur: Well, you could start a page under https://meta.wikimedia.org/wiki/Abstract_Wikipedia ?) [23:30:56] Date formats have been a known problem since 2017 and there's no sign anybody's working on the back end to fix them (re @PaulaPKM: 1) the ongoing issue with representation of centuries in the format "16. century" in English, which has resulted in editors entering the wrong century values. See discussion at https://phabricator.wikimedia.org/T95553.) [23:32:29] Date formats have been a known problem for aeons. 😉 (re @deryckchan: Date formats have been a known problem since 2017 and there's no sign anybody's working on the back end to fix them) [23:32:51] My impression is that there’s no consensus on *how* they should be fixed. [23:35:31] The lack of a solution to the date problem is an issue for date presentation in Abstract Wikipedia. So if we’re collecting items with the potential to prevent acceptance of the product of AW, this is one. [23:36:21] https://phabricator.wikimedia.org/T63958 [23:37:29] I would propose that Abstract Wikipedia extract dates from Wikidata using a native, unlocalized data structure, then have functions parsing dates to each language (re @PaulaPKM: The lack of a solution to the date problem is an issue for date presentation in Abstract Wikipedia. So if we’re collecting items with the potential to prevent acceptance of the product of AW, this is one.) [23:38:41] Ugh, I wasn’t aware of that one. Thanks I think. :-/ (re @deryckchan: https://phabricator.wikimedia.org/T63958) [23:38:44] We must have really ticked off Thiemo [23:41:35] https://tools-static.wmflabs.org/bridgebot/0555ed94/file_332.webp [23:42:17] Also Gerry probably derailed the other ticket in his frustration [23:42:20] Of course, that's the way to go, but when the dates have problems on Wikidata side and get entered not correctly thereafter, it does not matter that AW has a beautiful representation of the garbage. (re @deryckchan: I would propose that Abstract Wikipedia extract dates from Wikidata using a native, unlocalized data structure, then have functions parsing dates to each language) [23:43:09] I think it was frustrating for him that, perhaps for the first time after years of acclaimed work on l10n, a crowd speaking languages with features he was unaware of had descended on him to tell him his approach to l10n was wrong. [23:43:33] Which? (re @mahir256: Also Gerry probably derailed the other ticket in his frustration) [23:43:52] This one (re @PaulaPKM: 1) the ongoing issue with representation of centuries in the format "16. century" in English, which has resulted in editors entering the wrong century values. See discussion at https://phabricator.wikimedia.org/T95553.) [23:44:53] You're not rendering him entirely faultless in this impasse, then? (re @deryckchan: I think it was frustrating for him that, perhaps for the first time after years of acclaimed work on l10n, a crowd speaking languages with features he was unaware of had descended on him to tell him his approach to l10n was wrong.) [23:50:06] No. [23:50:06] Thiemo's personal insistence that the incorrect partial substitution of dd Mmm yyyy is better than defaulting to ISO / English for non-dmy languages has lost us a lot of time. (re @mahir256: You're not rendering him entirely faultless in this impasse, then?) [23:51:25] He was wrong and accepted others' corrections. I don't hold a grudge against him.