Page MenuHomePhabricator

Add LiquidThreads status to MediaWiki's info action
Closed, ResolvedPublic

Description


Version: unspecified
Severity: enhancement

Details

Reference
bz38534

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:51 AM
bzimport set Reference to bz38534.
Reedy added a comment.Jul 20 2012, 7:55 PM

(In reply to comment #0)

Some form of a Hook should be added to core, allowing extensions to add extra output to this page

Gerrit change 26970

(In reply to comment #2)

Gerrit change #26970

Thanks for working on this. It probably makes sense to add this info to an existing section (such as "Basic information") rather than adding a separate section. I worry adding sections per-extension will lead to a situation similar to what we have right now with Special:Preferences. As discussed on IRC, I guess it'd be something like this:

$pageInfo['header-basic'][] = array( wfMessage( 'Moo' ), wfMessage( 'True' ) );

I'm also not sure if I see where you define the messages used in your Gerrit change (e.g., "pageinfo-usinglqt-yes"). https://gerrit.wikimedia.org/r/#/c/26970/1/i18n/Lqt.i18n.php,unified is really confusing me, but that may be me or Gerrit being stupid.

The same applies to bug 40829 (Gerrit change 27091). CCing Siebrand.

If we're not going to show when a true/false value is false, then maybe we should structure this differently.
Have a list of things which are considered on/true maybe?

madman.enwiki wrote:

Gerrit change #27019 (just leaving this here because I couldn't understand why I was getting a 404 the first three or four times, herp derp).

Upon reflection, I believe I agree with Siebrand; hasn't one of our goals so far been to only show relevant information, hence the change to the restrictions table? It's open to discussion as we don't have any sort of design goal, I suppose, but I don't think any structural change is required. Also, I think if an extension is going to be adding less than two rows to action=info, it should do so in one of the tables core provides.

You may want to ask for input from design@lists, as ui/ux is important here.

I've thought about this for a bit and decided to simply only output when it's true/yes/on.

-easy: being LQT.

(In reply to comment #8)

-easy: being LQT.

This is idiotic. Restoring the easy keyword.

This has now been merged - see gerrit 26970. Closing.