Community Wishlist Survey 2019/Wikidata/Date handling improvements – additional precision and correction of translations in interface

Date handling improvements – additional precision and correction of translations in interface

  • Problem: On Wikidata, it is still not possible to add dates with precision better than the day or dates with time zone information, which prevents Wikidata from accurately recording when events occurred; and dates are still incorrectly localized for most languages (e.g. "4 8 1961" in Chinese), which obviously impedes a lot of contributors in understanding what they actually mean. These issues can harm the ability of editors to add data, making them problematic for data consumers as well.

    While "data entry is impossible" is self-explanatory, it's probably worth explaining just how complicated and irritating the date formatting issues are. On Wikidata dates can be shown with different precisions, from "day" (the current limit) to a billion years. Each of those precisions has to be translated correctly, and BC dates and AD years before 100 should be handled specially. This doesn't really work right now – "2 January [in] 1 AD" is shown as "1. január 2" in Hungarian (interpreted by readers as first of January in the year 2), and it's obviously even worse without displayed month names. Centuries and decades are also shown haphazardly in several languages because the software doesn't allow for things like grammatical inflection, though this is more of an irritant than an impediment.

    Although these are nominally separate issues, fixing either of them would involve changing the way Wikidata's interface handles dates, so it could be more effective for them to be worked on in tandem, and it would avoid duplication of work.

  • Who would benefit: primarily Wikidata contributors
  • Proposed solution: fix the irritating UI problems; add functionality which is needed to enable data entry and data storage
  • More comments:
  • Phabricator tickets: Selection of some tickets. I have added bold to the ones that seem the most impactful. I'm not expecting all of them to be resolved but it would be nice if work could be done on all of them.
    • phab:T57755 – Allow time values more precise than day (15 October 2013)
    • phab:T63909 – Make use of before and after in Time datatype (25 February 2014)
    • phab:T63958 – Use existing $dateFormats to format dates on Wikidata (26 February 2014)
    • phab:T95553 – Full stop in messages such as Wikibase-time-precision-century is incorrect in English (9 April 2015)
    • No tickets yet:
      • Translate date formats correctly
      • Correct grammatical inflection for dates (e.g. decades in Hungarian)
  • Proposer: Jc86035 (talk) 08:38, 30 October 2018 (UTC)

Discussion

Originally this proposal was broader in scope, so many of the comments discuss separate issues. Jc86035 (talk) 11:51, 17 November 2018 (UTC)
Discussion from before the start of voting. Jc86035 (talk) 11:51, 17 November 2018 (UTC)
  • Please add other Phabricator tickets if you think they are relevant to this request (although not necessarily those which are children of tasks already linked). Thanks, Jc86035 (talk) 08:38, 30 October 2018 (UTC)
  • Addon: Some properties like P150 (contains administrative territorial entity) seem to slow down the opening or scrolling of a page. Add a 'collapsable' (Hide/Show) possibility for properties which list many items --katpatuka (talk) 06:17, 4 November 2018 (UTC)
@Katpatuka: Do you want to improve the page load time (i.e. something like making statements load "lazily" after the initial page load) or do you want to allow properties to be collapsed? Jc86035 (talk) 06:49, 4 November 2018 (UTC)
@Jc86035: Both may be possible... I'm not a coder but I notice that I have to wait 3-5 seconds until the whole page has opened fully - so some sort of profiling would be good. For example if I click the edit link (connecting to wikidata:Special:SetLabelDescriptionAliases) too early only wikidata:File:Set_label,_description_and_aliases.png shows up without the rest of the page (using Firefox 52.9.0). --katpatuka (talk) 09:16, 4 November 2018 (UTC)
@Katpatuka: I've added three tickets (the last three) to the list; do you think something is missing? Jc86035 (talk) 09:27, 4 November 2018 (UTC)
@Jc86035: Should be ok then, thanks ;) --katpatuka (talk) 09:56, 4 November 2018 (UTC)
Partial (lazy) loading, or collapsing Statements might lead to a higher risk of duplicate data. I would never recommend it. For the same reason there is no "Statement Add" button at the top of the page; only at the bottom, so users need to scrol down and read existing Statements. I encounter the problem of duplicate data already now on pages with a lot of Statements. Rather I would choose for a logical/structured sequence of properties + alphabetical sorting (e.g. in Aliases or multiple alma mater, professions, functions, contains, etc.). We should always see all statements for one item. To prevent duplicate data I would implement an online constraint checking with an error message before saving the data. But some pseudo-duplicate statements are always possible: e.g. multiple official web sites, multiple VIAF codes, etc. Speeding up page load should always be a point of attention; but even more important is completeness and referential integrity improving the overall data quality. Geert Van Pamel (WMBE) (talk) 14:12, 4 November 2018 (UTC)
Principle of software engineering: first make it work, then only make it fast, efficient, and nice. Geert Van Pamel (WMBE) (talk) 08:46, 5 November 2018 (UTC)
  • Strong +1 on the date editing (phab:T57755), I was thinking to add a proposal focused on that --Sabas88 (talk) 11:16, 4 November 2018 (UTC)
  • It could be really useful to have a "Wikidata usability initiative" similar to Wikipedia's one. There is more room that what we can imagine for usability improvements on Wikidata. This would greatly empower the contributors. I know that this type of project need a full time team of UX specialists. It needs a specific funding. --Thibdx (talk) 00:14, 5 November 2018 (UTC)

Unfortunately, our team will not be able to work on this proposal because it wants to address too many things that it should have really been their own proposals. Even if we didn't work on any other proposal, we couldn't possibly finish this in a year. MaxSem (WMF) (talk) 00:38, 15 November 2018 (UTC)

@MaxSem (WMF): I've only linked to eleven tickets, excluding the Epic ones (which I was not expecting to actually be worked on, and it would obviously be impossible to create all the datatypes Wikidata will ever need). If I were to remove the tickets that are not bold-formatted and the "no tickets yet" points, or even just the Epic ones, would it be small enough? Jc86035 (talk) 06:03, 15 November 2018 (UTC)
@Jc86035:, we discussed this and consensus was that if you kept only the date related issues, this proposal would be fine. MaxSem (WMF) (talk) 19:08, 15 November 2018 (UTC)
@Jc86035:, you still have time to amend. MaxSem (WMF) (talk) 07:59, 16 November 2018 (UTC)
@MaxSem (WMF): By "date-related issues", are you referring to the time datatype issues (i.e. adding seconds precision and time zones), the date display issues, or both? I have amended the proposal so that only date-related issues are listed, so it should already be a bit smaller than some other proposals which haven't been archived. Jc86035 (talk) 10:22, 16 November 2018 (UTC)
@MaxSem (WMF): Since voting opens in less than five hours and I won't be staying up all night, I will be moving this proposal back myself. If it is still too much then I think it would be better to remove the parts of the proposal which pertain to adding hour/second/minute precision than to archive the proposal outright. Jc86035 (talk) 15:10, 16 November 2018 (UTC)
Eh some of those tickets are actually related so that it's possible that there's a synergy effect in reducing workload that they might not be as much as they seems. C933103 (talk) 06:16, 15 November 2018 (UTC)
  • Allowing date/times more precise than 1 day will have to make some provision to distinguish all the existing dates, which in reality are in local time (despite what documentation says), from dates created after the implementation, which would need a time zone. Jc3s5h (talk) 11:25, 19 November 2018 (UTC)

Voting

  •   Support Jc86035 (talk) 05:20, 17 November 2018 (UTC)
  •   Support, however I would like to use this opportunity to express my disappointment against the limited ability of the community tech team which lead to the rejection of many aspects of this proposal and also many other proposals. Especially with the amount of donation WMF have been gathering from users each year. C933103 (talk) 06:43, 17 November 2018 (UTC)
  •   Support ديفيد عادل وهبة خليل 2 (talk) 11:44, 17 November 2018 (UTC)
  •   Support Shisma (talk) 12:30, 17 November 2018 (UTC)
  •   Support wikidata definitely should handle date/time better, it's an important datatype for many purposes. ArthurPSmith (talk) 16:41, 17 November 2018 (UTC)
  •   Support Micru (talk) 17:04, 17 November 2018 (UTC)
  •   Support Thibdx (talk) 17:58, 17 November 2018 (UTC)
  •   Support Liuxinyu970226 (talk) 01:22, 18 November 2018 (UTC)
  •   Support Jklamo (talk) 03:42, 18 November 2018 (UTC)
  •   Support Psychoslave (talk) 04:20, 18 November 2018 (UTC)
  •   Support NMaia (talk) 11:00, 18 November 2018 (UTC)
  •   Support Viswaprabha (talk) 23:35, 18 November 2018 (UTC)
  •   Support Sabas88 (talk) 09:08, 19 November 2018 (UTC)
  •   Support Zeromonk (talk) 09:27, 19 November 2018 (UTC)
  •   Support Dhx1 (talk) 12:48, 19 November 2018 (UTC)
  •   Support Geraki TL 14:01, 19 November 2018 (UTC)
  •   Support Hibm98 (talk) 16:52, 19 November 2018 (UTC)
  •   Support Concise date formatting is surely needed. Vulphere 12:52, 20 November 2018 (UTC)
  •   Support Novak Watchmen (talk) 15:08, 21 November 2018 (UTC)
  •   Support Gce (talk) 17:33, 21 November 2018 (UTC)
  •   Support Pasleim (talk) 18:17, 22 November 2018 (UTC)
  •   Support Snipre (talk) 10:49, 23 November 2018 (UTC)
  •   Support KaMan (talk) 16:46, 23 November 2018 (UTC)
  •   Support Nvrandow (talk) 20:10, 23 November 2018 (UTC)
  •   Support Sannita - not just another it.wiki sysop 00:35, 24 November 2018 (UTC)
  •   Support Matěj Suchánek (talk) 09:44, 24 November 2018 (UTC)
  •   Support Yxh1433 (talk) 14:21, 24 November 2018 (UTC)
  •   Support Ranjithsiji (talk) 22:30, 25 November 2018 (UTC)
  •   Support Afaz (talk) 00:08, 26 November 2018 (UTC)
  •   Support I don't exactly agree with all the sub-points but in general, yes, data handling problem should be fixed. VIGNERON * discut. 10:28, 26 November 2018 (UTC)
  •   Support The current data handling system is a mess. While we are at the project of changing it it would be good to implement http://www.loc.gov/standards/datetime/edtf.html in full. ChristianKl❫ 12:35, 26 November 2018 (UTC)
  •   Support I hope this will be fixed in the next few decades… Tacsipacsi (talk) 17:30, 30 November 2018 (UTC)