Page MenuHomePhabricator

It should be possible to turn lead paragraph on in other namespaces
Open, LowPublic

Description

It should be possible to configure the lead paragraph transform to namespaces other than main. In particular, this is important for ensuring articles in the draft namespace are consistent with those in main

original report

On Dutch wikipedia there was a discussion on https://nl.wikipedia.org/wiki/Help:Helpdesk#Plaatsing_infobox (Dutch) about how the mobile website displays the infobox. It was concluded the infobox is indeed placed at the first empty line, that was confirmed by Krinkle. However, on the 'Kladblok' (Dutch for draft) this didn't happen, confusing the editor first.

Will it be possible to make the behaviour the same?

Acceptance criteria

  • A config flag exists that allows turning on the LeadParagraphTransform in multiple namespaces rather than main in various namespaces.
  • The config flag defaults to [ 0 ].

Developer notes

Inside includes/MobileFrontend.body.php the logic for showing a lead paragraph is like so:

showFirstParagraphBeforeInfobox = $ns === NS_MAIN &&
                        $featureManager->isFeatureAvailableInContext( 'MFShowFirstParagraphBeforeInfobox', $context );

Instead of doing this there should be a config flag do this:

showFirstParagraphBeforeInfobox = $this->isLeadParagraphEnabledInNamespace( $ns ) &&
                        $featureManager->isFeatureAvailableInContext( 'MFShowFirstParagraphBeforeInfobox', $context );

Event Timeline

Akoopal created this task.Dec 3 2018, 10:34 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 3 2018, 10:34 PM
Mbch331 added a subscriber: Mbch331.Dec 4 2018, 6:45 AM

Hi, I'd like to expand some of the local wiki context, their use case as I understood it.

When editors draft articles or experiment in their sandboxes (which are typically stored under the User namespace), they found that viewing it on mobile resulted in a different layout than if the same wikitext was saved on a main-namespace page.

This difference confuses users, because they see something on one page that they cannot reproduce on another. Namely that a template is positioned differently between desktop and mobile, but they can't do that themselves.

The user assumed they were doing something wrong, or missing a piece of the syntax; or that there was a software bug or cache problem preventing it from working correctly.

From a developer perspective, I suspect the reason that we don't apply this aspect of the mobile re-formatter to all namespaces, is that we're concerned it would break non-article pages where our assumptions about article contents might not hold up. Is that correct?

Given complex layouts that might exist on User profile pages and WikiProject pages, etc. it wouldn't surprise me if that's the reason we haven't so far.

On the other hand, if it is triggered only for class=infobox, and can be toggled per-wiki, then it might be worth working with the community to try and enable that for nlwiki. I don't think it would be unexpected for an Infobox on a non-article to behave the same as on an article page (this should be very rare anyway, and might actually match the use case of "sandbox pages and drafts" exactly). If it is triggered for any kind of table or block element, then we'd likely encounter problems, and reducing it to just infoboxes would be a way forward to avoid those problems.

Long-term, I think the real problem is that wiki page content is organised as a single unit. Re-formatting is incompatible with that, but we try the best we can. If the infobox were a primitive and first-class concept in the software (e.g. through an extension, maybe using MCR), then its rendered position and format could be freely defined by skins. Like how we define and position TOC and edit links already (except, better). It would also remove the problem of needing to differentiate between articles and non-articles, because we'd never have a false positive match for something that isn't an infobox.

Jdlrobson renamed this task from Enable placing the infobox at the first empty line also for drafts? to It should be possible to turn lead paragraph.Dec 12 2018, 12:23 AM
Jdlrobson triaged this task as Normal priority.
Jdlrobson updated the task description. (Show Details)
Jdlrobson moved this task from Incoming to Triaged but Future on the Readers-Web-Backlog board.
Jdlrobson added a project: patch-welcome.
Jdlrobson added a subscriber: Jdlrobson.

Certainly possible but a volunteer patch will likely make this happen quicker!

Jdlrobson renamed this task from It should be possible to turn lead paragraph to It should be possible to turn lead paragraph on in other namespaces.Dec 12 2018, 12:38 AM
Jdlrobson lowered the priority of this task from Normal to Low.Jul 31 2019, 6:50 PM