We can sunset, but I'd disagree Flow is a replacement. Actually I'd prefer LQT over Flow (wouldn't use any of them but if I had to choose...). Thanks.

Pinging @Nemo_bis @Nikerabbit and @siebrand since it's still deploying on translatewiki.net

LQT has caused multiple production issues for translatewiki.net:

• T30025: Out of memory error in LiquidThreads when viewing some LQT talk pages
• T155265: LiquidThreads denial of service due to unvalidated limit parameter
• T43272: Unoptimized query in LiquidThreads

While it used to be that I was fixing LQT errors earlier, now there aren't anymore that many UBN!s or log spam, so it's not really maintained by translatewiki.net staff anymore either. Mostly it's just keeping up with core changes.

I also disagree that SD is currently a replacement. SD also has technical debt (based on what I have heard), and it has not been shown that it can replace our Support page workflow fluently: assigning threads to people and supporting querying them semantically, e.g. to provide per project or per assignee listings of open threads. Last time migration was attempted at translatewiki.net the migration scripts weren't robust enough and there were issues about maintenance status of SD. I believe some more work on SD is needed for us to migrate away from it.

LiquidThreads currently doesn't have any replacement which would respect the basic requirements of a freely licensed and collaborative wiki project, such as the right to fork (which requires functioning export/XML dumps). This is probably one reason why it's still used on hundreds of wikis.

Based on the process description I don't see any practical effect of "sunsetting" LiquidThreads, given it was already mostly disabled on all wikis, unless it's about some additional investment to deal with the problems which arose in consequence.

The other option would be an investment in its ongoing maintenance, which I would support: to sustain the usage of MediaWiki by third parties, it makes sense to maintain the compatibility with MediaWiki core and maybe to fix some of the smaller well-known bugs which have been prioritised across the years. If among the 50 (?) third party wikis which use Flow there are some who would like to go back to the more widely used LiquidThreads, e.g. to make sure that their dumps are complete, it would be fine to fund such migration mechanisms too, so as to reduce our technical debt overall.

@Nemo_bis If you don't hate either non-wiki interface or introducing 3rd party services, then IMHO the Discord extension would have worth to be a candidate of LQT replacement. Because as far as I've tested, it's 1. VisualEditor compatible; 2. SemanticMediaWiki compatible; and 3. CLDR accessable.

@Liuxinyu970226 Can you elaborate? That extension I wrote doesn't make sense as a replacement - it just allows embedding a Discord widget showing who's online in a Discord server. That widget doesn't actually allow embedding a Discord chat where you can directly chat into it. IMO, discussion through live chatting and through on-wiki threads are two different things. With Discord you're going to have to create a separate account as well (since of course it's a 3rd party service).

If you really want live chatting within a wiki interface, there's the MediaWikiChat extension (as an example), but I'd say that would be out of scope for this ticket.

(Personally I'm not going to comment on the actual sunsetting of LiquidThreads, but I did just find to happen that the extension I wrote was mentioned here, thus my reply here. I also need to re-release the extension's source code as I was cleaning up my GitHub repos, it'll be back up soon)

@Nikerabbit I'm trying to get a better sense of the stewardship status of LiquidThreads. The work that you were/are doing on this is from a volunteer perspective (Translatewiki.net) vs as WMF staff correct? From what I've gathered from the discussion thus far, LiquidThreads doesn't have active Stewards, Translatewiki.net or otherwise correct?

I keep translatewiki.net running. This means, among other things, that the error log should be quiet and the most important extensions must work acceptably. LiquidThreads is one of those extensions. I will report new issues that affect translatewiki.net and if they are severe and nobody reacts to them, then I must attempt to fix them myself. That is not a stewardship as it does not entail helping others, having a product vision or doing any new development.

Whether that is volunteer or paid work mostly depends on when the issue surface (I am on call 24/7/365 for translatewiki.net) and whether it is something I can fix in a short time.

Thanks @Nikerabbit. That helps me better understand the current state of things.

@Jrbranaa

That helps me better understand the current state of things.

Why on earth you think keeping maintaining the source of server errors can also give you benefits? (please, consider my case, that I still sometimes been stucked due to CSRF token errors when visiting https://translatewiki.net/wiki/Support)

@Liuxinyu970226: How is your question related to the sentence that you quoted, and to the topic of this task?

I've heard some people say that they rely on LQT's "mark as read" ability to use it as a makeshift TODO list (I found that convenient myself, although I've interacted very little with LQT) so SD is not a suitable replacement to them as it is now.

Also SD has some very basic functionality gaps (no export, no search, no human-readable topic names...) which is probably a blocker for transition to many. Probably not too much work to fix though.

@Tgr But keeping development even twn only would also be less and less benefit, as I still can't see which code part resulted my face-to-face to CSRF errors (@Aklapper really I'm not sure if there's benefit to create separated task for my CSRF errors meeting, as staffs fixed once, another coded CSRF error happened just after 3 or 5 days, I really wanna cease this unfair do...loop).

Details of my CSRF errors can also be found at T178242

Usage statistics based on audience(s) served
Actively used on enwikinews and enwiktionary,

Can someone link any relevant discussions on those wikis regarding the status of their use of LQT (or potential migration away from it)?

Pinging enwikinews sysops @Bawolff @Bddpaux @Blood_Red_Sandman @Brian @Brian_McNeil @Cspurrier @DragonFire1024 @Gopher65 @Gryllida @Microchip08 @Mikemoral @Pi_zero @RockerballAustralia @SVTCobra @ShakataGaNai @Skenmy @TUFKAAP @Tom_Morris @Tyrol5 @William_S._Saturn to answer greg's question

In T187487#4247578, @Liuxinyu970226 wrote:

Pinging enwikinews sysops @Bawolff @Bddpaux @Blood_Red_Sandman @Brian @Brian_McNeil @Cspurrier @DragonFire1024 @Gopher65 @Gryllida @Microchip08 @Mikemoral @Pi_zero @RockerballAustralia @SVTCobra @ShakataGaNai @Skenmy @TUFKAAP @Tom_Morris @Tyrol5 @William_S._Saturn to answer greg's question

You should really ask on [[WN:WC]], most active wikinews admins are not active on phab.

Last i heard, wikinews was fairly anti-flow and very much pro continuing using lqt (lqt is used for a forum for non editors to discuss news items on wikinews. It is not used as a talk page replacement). However i have not been active there for many years so im not sure what current sentiment is

In T187487#4225957, @Liuxinyu970226 wrote:

@Tgr But keeping development even twn only would also be less and less benefit, as I still can't see which code part resulted my face-to-face to CSRF errors (@Aklapper really I'm not sure if there's benefit to create separated task for my CSRF errors meeting, as staffs fixed once, another coded CSRF error happened just after 3 or 5 days, I really wanna cease this unfair do...loop).

Details of my CSRF errors can also be found at T178242

This is an unfair criticism of lqt. CSRF checking is a centralized part of MediaWiki that is entirely separate from lqt (or any other extension). Unless lqt is reinventing the wheel here (im pretty sure its not) csrf/session errors are not its fault.

@Bawolff Umm, aren't those the reasons that Wikinews should have benefit by dropping LQT too? (By clicking F12 on Comments:Ireland votes to overturn 35-year-old constitutional ban on abortion)

• This page is using the deprecated ResourceLoader module "jquery.ui.widget".
• This page is using the deprecated ResourceLoader module "jquery.ui.position".
• This page is using the deprecated ResourceLoader module "mediawiki.api.options". Use "mediawiki.api" instead.
• jQuery.Deferred exception: elms.button is not a function TypeError: elms.button is not a function...
• This page is using the deprecated ResourceLoader module "jquery.ui.core". Please use OOUI instead.
• Your skin is incompatible with VisualEditor. See https://www.mediawiki.org/wiki/VisualEditor/Skin_requirements for the requirements.
• (red marked) Uncaught TypeError: elms.button is not a function
• Use of "skin" is deprecated. Use mw.config instead.

In T187487#4290891, @Liuxinyu970226 wrote:

@Bawolff Umm, aren't those the reasons that Wikinews should have benefit by dropping LQT too? (By clicking F12 on Comments:Ireland votes to overturn 35-year-old constitutional ban on abortion)

• This page is using the deprecated ResourceLoader module "jquery.ui.widget".
• This page is using the deprecated ResourceLoader module "jquery.ui.position".
• This page is using the deprecated ResourceLoader module "mediawiki.api.options". Use "mediawiki.api" instead.
• jQuery.Deferred exception: elms.button is not a function TypeError: elms.button is not a function...
• This page is using the deprecated ResourceLoader module "jquery.ui.core". Please use OOUI instead.
• Your skin is incompatible with VisualEditor. See https://www.mediawiki.org/wiki/VisualEditor/Skin_requirements for the requirements.
• (red marked) Uncaught TypeError: elms.button is not a function
• Use of "skin" is deprecated. Use mw.config instead.

For the record, only one of these relates to LiquidThreads. This one:

This page is using the deprecated ResourceLoader module "jquery.ui". Please use OOUI instead.

The other warnings and errors are from Wikinews's Common.js, site scripts, gadgets, and/or other extensions.

@Krinkle OK, but that said, I vote support for archiving this, the entire MediaWiki-extensions-LiquidThreads now looks like a ground of mass, it only has a large number of too simple actions without significant changes-to-code, e.g. Simply changed priority back to Normal and High, without any (even one second) consideration of https://www.mediawiki.org/wiki/Phabricator/Project_management#Priority_levels and https://www.mediawiki.org/wiki/Bug_management/Phabricator_etiquette, or even, without even one Gerrit patch to fix them and assignments.

@Liuxinyu970226: Archiving requires first a plan to uninstall from enwikinews, enwiktionary, huwiki, ptwikibooks, svwikisource...
The priorities of open project tasks are off-topic for this very task.

Have you thought about switching to DiscussionTools? :)

LQT apparently truncates (truncated at some point in the past?) some of its data in a way that might cause it to be invalid UTF-8. That, in combination with some poorly written bot getting stuck in a loop when an LQT page errors out, is flooding production logs with T337700: Exception: "Malformed UTF-8 characters" in Parser\MagicWordArray (via LqtVIew) right now.

T332022: [Epic] Undeploying StructuredDiscussions (Flow) will require a community consultation, we could probably discuss sunsetting LQT as part of that.