Last modified: 2014-04-10 07:03:35 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...
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.
(Mark as ASSIGNED for completeness.) Yes, worth discussing.
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.
IMO this should not be the task of the parser however, hence the low priority on this bug.
Mass-moving bugs into the new 'Parsoid' product.
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.
Changing component to general- this would either happen in MediaWiki PHP/DOM post-processing or the client side.
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.
(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. :-)
Presumably an optional parameter to that core API is "stub length preference".
(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. :-)
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.
As a note, if we did this cross-cluster, that would fix bug 11 (!) which would be a lovely additional feature.
(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 ;)
(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. :-)
Roan's going to try to work on this, at least as a first run.