Page MenuHomePhabricator

Page previews for Wikidata
Open, NormalPublic

Description

Story

Allow page previews to appear on wikidata containing the description of each item

Mocks

Requirements

General

Individual previews will be available for the following:

  • Items
  • Properties
  • Lexemes

Items - previews for items will contain:

  • Description (if available)
  • Label (with language fallback) (if available)
  • Number of statements
  • Number of sitelinks
  • Image (if available)

Properties - previews for properties will contain:

  • Description (if available)
  • Label (with language fallback) (if available)
  • Number of statements
  • Image (if available)

Lexemes - previews for lexemes will contain:

  • language, lexical category
  • lemma
  • Number of statements
  • number of forms
  • number of senses
  • Image (if available)

Language

Previews must appear in the user’s interface language

  • If the users language is not available for the requested preview, previews will fallback to an available language according to MediaWiki fallback chain
  • The name of the language the fallback appears in must be displayed on the page in the user’s interface language

Generic previews

  • If a description is not available for a given preview, a generic preview will appear informing the user that the item does not have a description (copy TBD, something like “there is no description for this item/property/lexeme”)
  • If a description is not available but the page has image, the image will appear along with the generic message
  • If a label is not available for a given preview, a generic preview will appear informing the user that the item does not have a description (copy TBD, something like “there is no description for this item/property/lexeme”)
  • If a label is not available but the page has an image, the image will appear along with the generic message

Acceptance Criteria

Post configuration

When consumed we should check:

  • for pages that do not contain a description, the generic card must not display
  • If a page has no description and no image, the generic card will display
  • Enabled for everyone
  • Logged-in users may turn off descriptions within their user preferences

Note: Further tweaks may be needed by the client/endpoint to deal with Wikidata specific edge cases (E.g. articles with no descriptions) and to ensure that the right language is loaded. Long term we'll probably want to add a 'type' 'wikidata' to https://www.mediawiki.org/wiki/Page_Previews/API_Specification rather than lean on the 'standard' type.

Related Objects

StatusAssignedTask
Resolvedovasileva
OpenNone
OpenNone
DuplicateBene
ResolvedJdlrobson
Resolvedmobrovac
ResolvedEevans
ResolvedEevans
ResolvedDzahn
ResolvedEevans
OpenNone
OpenNone
ResolvedEevans
Resolvedfgiunchedi
ResolvedEevans
ResolvedPchelolo
Opencooltey
Opencscott
OpenNone
Opencscott
Invalid GWicke
Resolvedliangent
Resolvedthiemowmde
OpenNone
Resolvedcscott
Resolvedcscott
ResolvedElitre
Resolvedcscott
Resolvedcscott
Resolvedcscott
Resolvedcscott
Resolvedcscott
Opencscott
Resolvedcscott
Opencscott
Opencscott
Opencscott
Resolvedmobrovac
ResolvedJdforrester-WMF
ResolvedJdforrester-WMF
ResolvedEevans
ResolvedEevans
ResolvedEevans
Resolvedmobrovac
Resolvedcscott
ResolvedPchelolo
ResolvedPchelolo
OpenNone

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
aude moved this task from Backlog to Monitoring on the User-aude board.

Marking as an epic.

All we need to do this is

  1. setup a new REST endpoint who's structure mirrors https://en.wikipedia.org/api/rest_v1/page/summary/Title

but handles wikidata identifiers.

e.g. for French:
https://en.wikidata.org/api/rest_v1/page/summary/Q1/fr

  1. Once that's setup it's just a case of wiring up page previews to be able to consume it.
Jdlrobson renamed this task from [Story] Graduate page previews out of beta features on Wikidata to [EPIC] Graduate page previews out of beta features on Wikidata.May 26 2017, 7:17 PM
Jdlrobson renamed this task from [EPIC] Graduate page previews out of beta features on Wikidata to [EPIC] Page previews for Wikidata.
Jdlrobson renamed this task from [EPIC] Page previews for Wikidata to Page previews for Wikidata.Jun 6 2017, 4:32 PM
Jdlrobson updated the task description. (Show Details)
Jdlrobson updated the task description. (Show Details)
ovasileva updated the task description. (Show Details)Jun 6 2017, 4:33 PM
phuedx updated the task description. (Show Details)Jun 6 2017, 4:35 PM
Jdlrobson added a comment.EditedJun 6 2017, 4:36 PM

Needs mock from Nirzar to show how this looks. If this requires a change to page previews we should create a new card dealing with the required change to the Popups extension.

pmiazga added a subscriber: pmiazga.Jun 6 2017, 4:36 PM
phuedx updated the task description. (Show Details)Jun 6 2017, 4:37 PM
Jdlrobson updated the task description. (Show Details)Jun 6 2017, 4:38 PM

This is barebones page previews for wikidata. it only has item title and description.

I would like for us to investigate more into relevant and useful metadata that we can surface, but maybe as a follow up...

Note on Spec: We will be using same spec as default page previews. height, width, orientation, image dimensions etc. The only thing new here is the typography between title and description.

Note on titles: We don't use titles on wikipedia as the blue link exists. They exist on wikidata as well but due to the lack of information to surface we need at least 1 concrete anchor element. we can use Title till we find better solution to this problem. it's actually not even about finding better solution, it's more about the amount of engineering work that will go into it.

Are you actually deciding on making all titles uppercase? I still think that is a ugly design choice.

Nirzar added a comment.EditedJun 13 2017, 4:55 PM

do you mean titlecase?

Oh yes, sorry. I mean that indeed.

We use sentence-case for articles, ui elements, and most of the in-product communication as well. ugly seems like a subjective opinion, unless there is an objective reason for changing our conventions, I would avoid making it lowercase.

Some relevant information about the use of titlecase/sentence case - https://medium.com/@jsaito/making-a-case-for-letter-case-19d09f653c98

To my knowledge I do not know any product or interface that uses lowercase for titles, hence if you look for research and resources on what to use, lowercase is not part of comparison. Lowercase is usually used in brandmarks and wordmarks for companies to seem more friendly. e.g. facebook.

If there is a connotation that the project community uses with letter casing, that would be a different issue. In that case, we should discuss that.

Yes. The community is spending quite some time explaining to people that labels and descriptions should not start with a capital letter (unless it is a proper noun). If we're showing people the opposite a lot in page previews that'll cause more people to do it wrong imho.

@Lydia_Pintscher what is the primary reason for doing that? also is there a way we can differentiate display of content and content itself?

The reason is that labels are what represents a concept. They are used in all kinds of places. They need to have "proper" casing in order to make them usable in all contexts.
I am not sure what you mean by differentiating display of content and content in this case.

Jdlrobson changed the task status from Open to Stalled.Jul 18 2017, 5:30 PM
Jdlrobson moved this task from Triaged but Future to Needs Analysis on the Readers-Web-Backlog board.

This is going to need a new RESTbase service or a variant of an existing RESTBase service before it can be done. This work can be expedited if someone from Wikimedia Deutschland is able to help us but not a top priority for reading right now!

This is going to need a new RESTbase service or a variant of an existing RESTBase service before it can be done. This work can be expedited if someone from Wikimedia Deutschland is able to help us but not a top priority for reading right now!

In order to provide labels and descriptions in the user's language, it'll also require that language variant support is implemented in RESTBase (see T159985: Implement language variant support in the REST API).

Jdlrobson changed the task status from Stalled to Open.Apr 20 2018, 2:33 PM

@Jdlrobson - upload video here

I worked on this during the hackathon.

This seems relatively straightforward. It needs a new endpoint (POC=https://gerrit.wikimedia.org/r/434193 WIP: Add a wikidata summary endpoint) and configuration like so ($wgPopupsRestGatewayEndpoint = 'http://0.0.0.0:6927/en.wikidata.org/v1/page/summary/') where en is the language. This could be configured on the client and obey user preferences. A minor change in page previews would be needed to support language specific configuration (e.g. $wgPopupsRestGatewayEndpoint = 'http://0.0.0.0:6927/$1.wikidata.org/v1/page/summary/') but apart from that, this is a pure mobileapps change - creating the API.

Demo: http://jdlrobson.com/DEMO2.mov

Change 434193 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/services/mobileapps@master] Add a wikidata summary endpoint

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

Jdlrobson updated the task description. (Show Details)EditedJun 29 2018, 9:33 PM

https://gerrit.wikimedia.org/r/434193 is ready for review and if merged should allow us to get this up and running on https://wikidata.beta.wmflabs.org for testing and work out how much work is necessary on the client. This will likely need a few follow up changes, but, this task does not look too complicated.

Jdlrobson updated the task description. (Show Details)Jun 29 2018, 9:35 PM
Jdlrobson updated the task description. (Show Details)
Jdlrobson updated the task description. (Show Details)Jun 29 2018, 9:40 PM
bearND added a subscriber: bearND.Jun 30 2018, 12:01 AM

@Jdlrobson Thanks for the updated patch!

@Jdlrobson @phuedx I see some discrepancies between https://www.mediawiki.org/wiki/Page_Previews/API_Specification and this task description.

  • "type": "wikidata" vs "wikidata_preview"
  • Extra attributes: number of sitelinks and claims in @Jdlrobson's patch vs. "wikidata_label" on the spec page.

Let's agree on what we want here and update the two sides (task vs spec page) to keep in sync. I'm not sure why we would need the number of sitelinks and claims but I can live with them if they are indeed needed by clients. If there is no immediate use for them I would prefer to keep them out for now. We can add properties later, just not remove them without breaking BWC.

Jdlrobson added a comment.EditedJun 30 2018, 12:47 AM

Long term we'll probably want to add a 'type' 'wikidata' to https://www.mediawiki.org/wiki/Page_Previews/API_Specification rather than lean on the 'standard' type

The first iteration of the patch implements the standard spec.

I am happy to drop sitelinks and claims to keep more consistent.

keeping the other field names the same simplifies the client greatly and allows us at least to test page previews on wikidata with out any changes whatsoever on page previews side.

Type wikidata can come later.

@bearND I've clarified in the commit that this is seen as iterative and the goal for https://gerrit.wikimedia.org/r/434193 is to be compatible with the standard endpoint. Doing this would allow us to begin experimentation on the beta cluster

I've written a POC to demonstrate how we could iterate off this patch to create a new preview type if we decide we want to make changes to the client. I can't comment on the merits of a new summary type right now, but I'm skeptical. I propose we continue that conversation on the talk page.

@Jdlrobson As long as you and @phuedx agree on what it should be and it's all in sync with the documentation that sounds all fine to me. It's certainly fine to introduce the new type in a later patch.

Services: The current version of the patch takes the accept-language header to determine the language to be requested from Wikidata. How do we want to proceed for this MCS endpoint? In other words, would you like to store one entry for all languages or multiple entries in Cassandra, one per language?

Happy to chat through this. No rush. Please let me know if you would like me to attend any services sync relating to this. It feels like we have a few things to work out with the accept-language header before this patch is ready anyway.

We said it'd be nice to display the number of statements and sitelinks in order to give people a quick way to see how "good/useful" the item behind the link is. If you see an item has no sitelinks and statements then it's probably not worth clicking because it'll not tell you much more. But it's totally ok from my side to leave this out for now.

ovasileva updated the task description. (Show Details)Aug 1 2018, 9:21 AM