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.

In T111231#3448910, @Jdlrobson wrote:

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 - upload video here

http://jdlrobson.com/DEMO2.mov

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

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 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.

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.

I've created T199096: Add support for wikidata summaries in the /page/summary/ endpoint for #reading-infrastructure-team-backlog to do its work this quarter on the service endpoint.

Change 434193 abandoned by Jdlrobson:
Add a "standard" compatible wikidata summary endpoint

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