Abstract Wikipedia/Dates/is
| This page in a nutshell: This page collects in one place some issues and questions around date representation that may potentially impact the success and acceptance of Abstract Wikipedia. |
Generating dates
It has been broadly suggested that we could automatically generate descriptions as a sort of "first step" toward Abstract Wikipedia because we have tools — notably Reasonator and Mix-n-Match — that generate such descriptions today. It's important to note that these tools generate very useful descriptions but have some real challenges with dates. Some of these challenges arise from the way datetime data is stored in Wikidata; some arise from editor confusion; and some arise because the tools were developed before new properties such as "refine date" were available.
Resolving these issues is outside of the scope of Abstract Wikipedia. But addressing the rendering of dates "correctly" (that is, in the way that the contributing editor would expect) will be necessary for acceptance of Abstract Wikipedia.
Outstanding Wikidata issues around date representation and localization
- This section links to open Phabricator tickets related to dates.
Issues have been identified around the localization of date presentation.
Some of these issues are identified at Use existing $dateFormats to format dates on Wikidata.
There is a specific issue with the representation of centuries in the format “16. century” in English, which has resulted in editors entering the wrong century values.
See Full stop in messages such as Wikibase-time-precision-century is incorrect in English.
There is confusion about the definition and parsing of centuries and millennia.
See Wrong parsing of centuries and millennia.
It was suggested that we simply Stop using “century” and “millennium” in association with Wikidata datetime data.
Presentation of dates in existing tools
Both Mix-n-Match-generated summaries and Reasonator ignore date qualifiers such as “sourcing circumstances”, “refine date”, “earliest date” and “latest date”.
Editors are encouraged to enter a fixed date in the middle of a range and then set a precision (so, enter 1750 with precision “century” to display “18. century”). The date entered is apparently stored (and used for sorting and timelines, which is the object of entering dates this way) but is not visible in the user interface. An item that displays “date of birth = 1. millenium BCE” in the user interface may appear as “he was born 500 BCE” in Mix-n-Match or Reasonator (example: Peisias, and in Reasonator).
If the editor enters “13. century” directly, Wikidata assumes “13. century = 1201–1300” and stores the value “1300” with “precision = century”. As a result, Mix-n-Match displays “She was born in 1300”. This can result in constructions like “she was born in 1300 and died in 1264” when what is meant is “she was born (sometime in) the 13th century and she died in 1264”.
Possible acceptance criteria for date representation in AW
- Understand and render date precision.
- Understand and render date qualifiers such as “sourcing circumstances”, “refine date”, “earliest date” / “latest date”, “start time” / “end time”. (Note that Commons templates do recognize and parse these qualifiers.)
- Render dates in localized syntax for each language (examples: “12 de junho de 1990” in Portuguese, “12 June 1990” in English).
- Translate dates into other calendars if they are standard for a language (for example Persian generally uses the official Iranian calendar, Arabic and some other languages may prefer the Islamic calendar).
- Date representations may require showing both Gregorian and Julian versions in some cases (the specific calendar(s) may be specified in the abstract text content itself?).
- Dates involving the ancient past (geologic eras, solar system and galactic features, etc.) should be displayed with appropriate translation of numbers — for example “65 million years ago”, “4.54 ± 0.05 billion years ago”. This probably applies to most display of large numbers.
Possible solutions for date rendering
...