Does cite store references in page_props or somewhere else, so that they could be retrieved on a SpecialPage given a page title?

Should the task title be updated to reflect this is for RL incompatible UAs? Or are we going to go the extra step and actually support lazy-loaded references for JS-but-RL-incompatible UAs?

@Sumit Cite stores them in page props and they can be accessed via Cite::getStoredReferences
Unfortunately the blocking bug however limits our ability to make progress int his area right now...

I talked with @Nirzar about this today.
He is fine with just rendering the title and the list of references in a single special page given that the number of people who get to this is likely to be low.
Here is my prototype of how this might look (Nirzar to provide an updated one)

We also talked about using JavaScript to render the citations in the article itself via JavaScript when expanded/scrolled to.

In T125897#2090155, @Jdlrobson wrote:

I talked with @Nirzar about this today.
He is fine with just rendering the title and the list of references in a single special page given that the number of people who get to this is likely to be low.

I just want to annotate "low" with some actual data before we rush to judgement. Traffic analysis for December 2015:

• Grade A browsers: 85.58% (13 billion page views)
• Grade C browsers: 5.63% (870 million page views)
• Grade X browsers: 8.79% (1.3 billion page views)

This is from the "wmf pageview browsers 2015-12" Google Doc previously shared previously. (Exact breakdown kept internal for now, but this is the aggregate).

The non-Resourceloader group is Grade C.

The non-JavaScript group is Grade C plus any page views with Grade A or Grade X browsers from users with JavaScript disabled or that experienced connectivity issues that resulted in JavaScript not fully initialising.

Why is it now "Special:MobileCitations" in the task description? There are non-mobile users without JavaScript enabled.

@jayvdb the mobile prefix is needed if we put this in the MobileFrontend extension which is the current suggestion. It would of course work for desktop users who wanted to use it (that said the predominant use case at the moment is mobile). I've updated the card.

I personally still believe the Cite API is the way to go, in which case this would be Special:Cite and it would live in the Cite extension.

As part of the writing of unit tests I needed to setup some scaffolding for the special page to write php unit tests for the formatter:
https://gerrit.wikimedia.org/r/277358

Change 277358 had a related patch set uploaded (by Jdlrobson):
Special Mobile Cite page and PHPUnit tests

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

@phuedx and @Jhernandez could you take a look? Thanks!

Looks good to me, I've QAd and all, but I can't merge because I've had to make a change to the patch to make it work, so somebody else should have a look.

I'd like to see a browser test added for this though, either as a followup patch or in this same one. At the very least a blocking task for rolling lazy references to stable if it is not browser tested on the happy path.

In T125897#2297540, @Jhernandez wrote:

Looks good to me, I've QAd and all, but I can't merge because I've had to make a change to the patch to make it work, so somebody else should have a look.

I'd like to see a browser test added for this though, either as a followup patch or in this same one. At the very least a blocking task for rolling lazy references to stable if it is not browser tested on the happy path.

There's been a browser test follow up for a few days now but as I've said [[ https://gerrit.wikimedia.org/r/288441 | on the patchset ]]it gives us minimal protection due to the fact Chrome webdriver doesn't allow you to spoof user agent.

Change 277358 merged by jenkins-bot:
Special Mobile Cite page and PHPUnit tests

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

I've setup T135539 and T135542 (I've pulled the latter in as a blocker for sign off)
You can see this in action on http://en.m.wikipedia.beta.wmflabs.org/wiki/Barack_Obama