Page MenuHomePhabricator

Come up with a porting plan for the Listing extension
Closed, DeclinedPublic


This task is for initial triage of the Listing extension as used on hewikivoyage, since that is one of our possible phase 1 targets:

First, we should examine how it is used on hewikivoyage (how many pages, etc) and the importance of a port -- also, given that this is a non-english wiki, is our port likely to have other i18n issues? If there are only a small # of pages, can we allow/block list them instead of porting?

Assuming we decide that we need to port this extension, we should determine a porting plan:

  • full port to use the Parsoid extension API, or
  • just use the existing core hooks in a more Parsoid-compatible manner (if possible)

Finally come up with a time estimate for this work and use this to determine whether we want to sink that time now, or else revisit the decision to target hewikivoyage in phase 1.

Event Timeline

I pushed a couple patches to gerrit to cleanup the Listing extensions code. See and followup.

This should be fairly easy to port to use the ParsoidExtensionAPI after those patches are merged since it DRYs out some code.

That said, if we know for certain that listings don't use <ref> tags or links, etc. that might need Parsoid semantic markup, we can continue to proxy this to the legacy Parser. So, first order of business to determine this is to look at usage on wikivoyages and see what kind of wikitext is embedded inside listings.

Additionally, all wfMessage use in the listing extension are "inContentLanguage" so no i18n work is needed for it to work on non-english wikis. So, maybe it is simple to write a Parsoid compatible version rather than do any additional analysis or research.

ssastry triaged this task as Unbreak Now! priority.Jan 12 2024, 12:18 AM

@MSantos, looks like the listing extension is slated to be undeployed this year. So, I recommend declining this as well.

ssastry lowered the priority of this task from Unbreak Now! to Low.Jan 12 2024, 12:19 AM