Wikimedia Meta-Wiki

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

< Community Wishlist Survey 2019‎ | Wikidata
(Redirected from Community Wishlist Survey 2019/Wikidata/Improvements to the Wikidata data model and user 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)[reply]

Discussion

Originally this proposal was broader in scope, so many of the comments discuss separate issues. Jc86035 (talk) 11:51, 17 November 2018 (UTC)[reply]
Discussion from before the start of voting. Jc86035 (talk) 11:51, 17 November 2018 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
@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)[reply]
@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)[reply]
@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)[reply]
@Jc86035: Should be ok then, thanks ;) --katpatuka (talk) 09:56, 4 November 2018 (UTC)[reply]
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)[reply]
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)[reply]
  • 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)[reply]

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)[reply]

@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)[reply]
@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)[reply]
@Jc86035:, you still have time to amend. MaxSem (WMF) (talk) 07:59, 16 November 2018 (UTC)[reply]
@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)[reply]
@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)[reply]
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)[reply]
  • 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)[reply]

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2019/Wikidata/Date_handling_improvements_–_additional_precision_and_correction_of_translations_in_interface&oldid=18674150"