Last modified: 2014-04-10 07:03:35 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T39902, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 37902 - Implement rendering of redlinks and stubs (in a post-processor?)
Implement rendering of redlinks and stubs (in a post-processor?)
Status: ASSIGNED
Product: Parsoid
Classification: Unclassified
General (Other open bugs)
unspecified
All All
: High enhancement
: ---
Assigned To: Roan Kattouw
:
Depends on: 62803
Blocks: 33084 51245 38726
  Show dependency treegraph
 
Reported: 2012-06-24 19:36 UTC by James Forrester
Modified: 2014-04-10 07:03 UTC (History)
9 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description James Forrester 2012-06-24 19:36:26 UTC
For the arbitrary stub threshold preference, perhaps just hint with the character length of the link and leave it to the UI to decide how to render based on user preferences? This would mean that we wouldn't fragment the parser cache...
Comment 1 Gabriel Wicke 2012-06-24 20:09:42 UTC
See my reply in bug #37901. I'd prefer to take the opportunity and move as many user preferences out of the parser as possible.
Comment 2 James Forrester 2012-06-24 20:10:33 UTC
(Mark as ASSIGNED for completeness.)

Yes, worth discussing.
Comment 3 Amir E. Aharoni 2012-07-21 11:26:04 UTC
I'm a bit surprised about the importance. Coloring for stub may be an enhancement, but a link to a nonexistent page definitely shouldn't be blue.
Comment 4 Gabriel Wicke 2012-07-22 21:00:13 UTC
IMO this should not be the task of the parser however, hence the low priority on this bug.
Comment 5 James Forrester 2012-08-06 19:25:41 UTC
Mass-moving bugs into the new 'Parsoid' product.
Comment 6 Gabriel Wicke 2012-08-06 21:23:10 UTC
Moving this to the CPP DOM subcomponent for now, as this would be something to implement on the DOM if it is going to be done on the server side. A JS-only implementation could also use node to work on the server-side DOM as a fall-back for non-js clients.
Comment 7 Gabriel Wicke 2013-01-28 22:47:03 UTC
Changing component to general- this would either happen in MediaWiki PHP/DOM post-processing or the client side.
Comment 8 C. Scott Ananian 2013-03-26 22:03:16 UTC
One option might be to merge in information from another API into the <head> of the document which parsoid returns, to minimize round trips -- but in that case the API should first be added to core.  The simplest possible API would supply the name of an article and get back an array of stubbed or red links in that article.
Comment 9 James Forrester 2013-03-27 02:32:07 UTC
(In reply to comment #8)
> One option might be to merge in information from another API into the <head>
> of the document which parsoid returns, to minimize round trips -- but in that
> case the API should first be added to core.  The simplest possible API would
> supply the name of an article and get back an array of stubbed or red links
> in that article.

Only problem is that this doesn't solve the "colouring stubs differently at a user-set arbitrary byte length" preference; I'd be reasonably OK with us removing that feature anyway, but that should be an actual decision discussed with people rather than just over-looked. :-)
Comment 10 C. Scott Ananian 2013-03-27 03:23:01 UTC
Presumably an optional parameter to that core API is "stub length preference".
Comment 11 James Forrester 2013-03-27 06:32:21 UTC
(In reply to comment #10)
> Presumably an optional parameter to that core API is "stub length
> preference".

That could work, but feels a little messy. Gabriel as guardian of all that is appropriate coding might well have some thoughts. :-)
Comment 12 Gabriel Wicke 2013-03-29 20:26:50 UTC
For stub thresholds, the API could also return an array of linked articles and their respective size. I think it would be fine to put the burden of an additional request onto those few users using stub indicators (they are disable d by default). The actual rendering can be done client-side based on that user's stub thresholds, which can sadly be arbitrary byte sizes.
Comment 13 James Forrester 2013-09-05 21:23:30 UTC
As a note, if we did this cross-cluster, that would fix bug 11 (!) which would be a lovely additional feature.
Comment 14 Gabriel Wicke 2013-09-05 21:59:13 UTC
(In reply to comment #13)
> As a note, if we did this cross-cluster, that would fix bug 11 (!) which
> would
> be a lovely additional feature.

Sounds doable with separate API requests to each target wiki. Or even HEAD requests for external links, so that even non-wiki external links could be redlinked ;)
Comment 15 James Forrester 2013-09-05 21:59:52 UTC
(In reply to comment #14)
> (In reply to comment #13)
> > As a note, if we did this cross-cluster, that would fix bug 11 (!) which
> > would be a lovely additional feature.
> 
> Sounds doable with separate API requests to each target wiki. Or even HEAD
> requests for external links, so that even non-wiki external links could be
> redlinked ;)

That would just be showing off. :-)
Comment 16 James Forrester 2014-02-27 21:56:12 UTC
Roan's going to try to work on this, at least as a first run.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links