[01:12:23] <hare>	 https://github.com/wikimedia/parsoid-jsapi << How reliable is this? Can I use this as a service in my app, or is this considered out-of-date?
[01:14:36] <Reedy>	 it hasn't been touched in two years...
[01:14:40] <Reedy>	 cscott: ^^
[01:30:08] <Reedy>	 hare: Noting you can composer require parsoid these days... I don't know how stable/well that will necessarily work though
[06:37:35] <am12>	 what
[08:25:53] <Hi-Angel>	 Hey! I wanted to make our team to migrate from google-docs to mediawiki software. I was asked something I couldn't find an answer for: suppose we set up a wikimedia with restricted access, is it possible to share a wiki page into public through a unique link?
[08:28:02] <Vulpix>	 Hi-Angel: No, that's not possible. You can make one or some pages public in a private wiki, but that requires an edit in the configuration file, specifying what pages you want to make public
[08:28:38] <Vulpix>	 It's not as simple as clicking a link and select "share"
[08:28:53] <Hi-Angel>	 I see. This is sad :c Thanks
[08:51:59] <Hi-Angel>	 Vulpix, I wonder though: after that config file is edited, does one have to restart some service, or is it Just Work™? In case of the latter I guess it should be simple enough to automate that…
[08:52:25] <Vulpix>	 it Just Work™ :)
[08:52:34] <Hi-Angel>	 Oh, cool, thanks!
[08:53:11] <Vulpix>	 The configuration file is a php file, so changes are applied immediately
[12:43:53] <TheUnblockable21>	 Which extension is it that makes links ignore case *on enwiki*? (It could be a config setting?)
[12:43:54] <TheUnblockable21>	 (EG 'Page name' will automatically redirect you to 'Page Name')
[12:43:54] <TheUnblockable21>	 (If 'Page name' doesn't exist)
[12:43:54] <TheUnblockable21>	 (and 'Page Name' does)
[13:16:50] <Vulpix>	 TheUnblockable21: doesn't seem to work: https://en.wikipedia.org/wiki/MaIN_pAgE
[13:17:29] <Vulpix>	 But if you want such an extension, there is one: https://www.mediawiki.org/wiki/Extension:SaneCase
[13:18:00] <TheUnblockable21>	 @Vulpix: Type it into the search bar
[13:18:19] <Vulpix>	 I've typed it into the search bar before posting the link :)
[13:18:43] <Vulpix>	 Ah, no, the *search bar*, not the *location bar*
[13:18:57] <Vulpix>	 Well, that's done with Extension:CirrusSearch
[13:19:35] <Vulpix>	 If installing ElasticSearch is a big burden for you, there's an alternative: https://www.mediawiki.org/wiki/Extension:TitleKey
[13:24:29] <TheUnblockable21>	 Aha!
[13:24:31] <TheUnblockable21>	 Thanks
[13:26:21] <TheUnblockable21>	 Does it do the same for links too?
[13:35:23] <Vulpix>	 TheUnblockable21: No, links are always case sensitive
[16:30:21] <cscott>	 hare, Reedy: unfortunately it's definitely unmaintained these days
[16:30:48] <cscott>	 hare, Reedy: I tried to get folks to adopt it instead of mwparserfromhell for a number of years, w/o any luck
[16:31:35] <cscott>	 i think what's needed now is a drop-in replacement in python that uses the rest api to request parsoid HTML
[16:31:55] <cscott>	 it turns out (apparenty) that not enough people are writing bots or MW tools in JS
[16:32:42] <cscott>	 composer require parsoid should work well also, but it's even less clear that people want to write bots or MW tools in PHP
[16:33:04] <cscott>	 CLI scripting in PHP seems to be a niche hobby
[16:33:49] <cscott>	 fwiw, `composer require parsoid` is actually the maintained solution, though.  we plan on maintaining the API backend to Parsoid which lets it run standalone, and which the tools in parsoid/bin/*.php all use.
[18:15:19] <cscott>	 Krinkle: re T145604 the issue is not technical, but management-related
[18:15:21] <stashbot>	 T145604: RFC: Future of magic links - https://phabricator.wikimedia.org/T145604
[18:15:54] <cscott>	 Krinkle: i don't think there are any significant technical objections, but actually turning off magic links would require engineering work by parsing and editing that neither of us has on our roadmap
[18:16:00] <cscott>	 not as a priority, at least.
[18:16:12] <cscott>	 subbu ^
[18:16:22] <cscott>	 It's T145590 / T 145589
[18:16:23] <stashbot>	 T145590: Update Parsoid to be compatible with magic links being disabled - https://phabricator.wikimedia.org/T145590
[18:16:41] <cscott>	 T145589
[18:16:43] <stashbot>	 T145589: Update VisualEditor to be compatible with magic links being disabled - https://phabricator.wikimedia.org/T145589
[18:17:11] <cscott>	 so the Q is whether moving it to 'last call' status implies that we're actually going to do it anytime soon
[18:18:09] <cscott>	 but from a technical perspective I think we're all on board
[18:18:49] <cscott>	 it *might* make an interesting extension using the new parsoid extension API (as a dom postprocessing step that links ISBNs etc)
[18:19:07] <cscott>	 so in theory we could probably justify roadmapping it on those grounds.  but we have a lot of competing priorities.
[18:20:11] <cscott>	 it was originally being driven by legoktm IIRC as a personal project, and i'm not sure he's got the bandwidth right now to push the remaining pieces forward either
[18:21:25] <legoktm>	 That's an accurate summary
[18:27:09] <subbu>	 cscott, thanks. yes, that is accurate. cscott Krinkle we could potentially carve it off as an OPW project in 6 months if we described and scoped it properly.
[18:27:28] <subbu>	 but, Krinkle if techcom has any perspective / position on that rfc, let us know.
[18:42:49] <Krinkle>	 subbu: yeah, no urgency, just want to make sure it's okay to approve or whether there are still unknowns that should be discussed/decided within the scope of the RFC.
[20:42:17] <hare>	 cscott: "composer require parsoid should work well also, but it's even less clear that people want to write bots or MW tools in PHP" you'd be surprised
[20:42:48] <hare>	 there are a surprising number of PHP wiki-bots out there, including Internet Archive Bot
[21:03:29] <Reedy>	 IA Bot is hardly a beacon of...