This is presumably no longer relevant, since MW versions before 1.43 are no longer supported.

@LGoto - thanks for the response; but I don't understand this. Why would any of this project require coordination with the WMF?

@LGoto - I don't know who those ML experts are that you consulted with, but I believe adding agentic editing to Wanda is completely feasible. There are already agentic editing tools for MediaWiki - here is one example. (You can see a demo of it here.) For that matter, there was already a patch to add LLM-based editing to Wanda, here - it was abandoned for various reasons, but I tried it while it was still under development and it could in fact do basic editing, like "Simplify the wording in this page". What specifically did they think was unfeasible? If they want, we can reduce the stated scope - it's not a problem; I don't think anyone expects this single project to result in a complete agentic editing solution.

Test was added! Thank you, @SarthakSingh2904.

@Alex44019 - can this task be closed?

I've mentored two different GSoC projects in two previous years, so I assume I can handle it this time as well. That said, if I'm not allowed to do it this year, I'll remove myself from one of them.

@Miloslanda - sorry, I hadn't realized that there was still a call to cl_to in the code that I had not yet been fixed. I think it's fixed now, so... this issue might finally be resolved.

@TheDJ - alright, I changed most of the SQL calls in the code (including all of the INSERT calls) into prepared statements; thanks for the suggestion.

@SomeRandomDeveloper and @FO-nTTaX - thanks to both of you for your help. I believe this problem is fully fixed now!

Sorry for the long delay. I don't know if there's a way to fix this. If you want some simple formatting, like making the entire link bold, one option is to wrap the entire #formredlink: call in HTML, like <span style="font-weight: bold;">...

@SomeRandomDeveloper - does this patch fix the problem?

I assume this can be closed now. Thank you @ArclightAutomata for the fix!

@TheDJ - thanks for listing all of those in one place. Of the "Technical concerns", I think I've now fixed the first four, plus another one that you didn't list but a few people mentioned: that the function and global variable names were all in the main namespace. That just leaves "no error handling" and "memory leaks". I think the error handling is adequate, and I'm not aware of any memory leaks, but it would be good to hear more specifics on either one of those.

I plan to take care of this later today, unless anyone wants me to wait longer.

Wow, what a simple fix! No, there's no specific reason why it's using ParserAfterTidy - I'm guessing that I just copied that from another extension.

I'm marking this as "Invalid", because I think it was fixed already - feel free to re-open if you think it's still a problem.

@Miloslanda - please make sure you're using the latest version of Page Forms, 6.0.4.

@Alex44019 - thank you for the analysis, and for the fixes/improvements to the documentation. I look forward to any patches you provide.

Thanks, @thcipriani and @Reedy! Let's see how this goes. Maybe this will be a good test case for removal of REL branches for many other extensions...

I assume this can be closed...

Sorry, that's really a question for @Techwizzie - it's his extension, I'm just a fan. :) From my perspective, though, I think this makes sense.

Well, I created (and merged in) a cherry pick to REL1_45 - but it looks like cherry picks to any previous branch will require some manual work.

Sure, that sounds good to me - let me know if you want me to do it.

@TechieNK - thank you for this fix!

That translation thing sounds interesting! Could/should a prompt be added for that, if the user's language is different from the content language?

I do wonder about that. Given that, right now, Wanda is just basically doing a text search rather than using a vector database, is it even possible for the LLM to read and answer questions in language A about content that's in language B?

Maybe there's no need for this setting, i.e. the additional LLM prompt "Please provide your answer in the language with code ..." should just always be added? I don't know if there would be a case where it's not a good idea to add this.

Okay, this looks good! Could you create a patch for it?

Sorry for the delay. I don't see any way for me to delete these branches, either.

Marking this as "Invalid" - feel free to re-open if escaping the curly brackets doesn't work.

I can't say for sure, but I don't think I have that option.

Okay, I think I see the issue: Page Forms only creates a "Data structure" section if one does not exist (see here), but in the SMW code, it creates one no matter what. Maybe I had assumed that the SMW code would always be called be first, if both were installed; I'm not sure. Anyway, one relatively easy solution would be to have the SMW code first check before adding a section, like the PF code does. Your code does what might be the better solution, - assuming that no one will ever want to have two sections with the same name, which I think is a reasonable assumption. It seems a little needlessly complicated, though: the lines from 44-63 seems like they could be handled with a single section of code, without the "if" statement.

Done! Thank you, @Samwilson.

I think it makes sense to remove the REL branches for every such extension that's also on Gerrit. It may seem drastic, but these branches currently cause a lot of confusion, without much of an obvious benefit. Sure, it's nice to get the right version of an extension for one's wiki running, say, MW 1.35, but for these extensions, there's a good chance that the REL1_35 branch is not the right version, and will still have MW 1.35 compatibility bugs.

Option #5! Also a good one.

Actually, there's a fourth option, as far as I can tell: delete the REL1_43 and REL1_44 branches, and recreate them as copies of master. (This unfortunately can't be done for REL1_39, since the latest Cargo code only supports MW 1.40 and higher.) I would think this is the best option, at least for those two branches, since it's the most painless overall. But I'm not against any of these.

Hi, I think you just need to escape the curly brackets - see here: https://www.mediawiki.org/wiki/Extension:Page_Forms/Defining_forms#Reusing_form_elements

Feature added! Thank you, @Jayanthvikashs .

Evidently some other fix needs to be backported to these branches before this change (or any other) can pass validation; I thought it was this one, but clearly not, since this cherry-picked version gets the same error:

Okay, thanks, very interesting. And I guess I understand the need for a bot, for a large site - there would be too many approval-requiring changes being done for humans to have to deal with them every time.

@Anderlaxe - sorry, I think I'm missing some basic information. Is there the possibility of Approved Revs being used on some Wikimedia site? Or another large site? And why would a bot be needed for approving changes?

Oh, yes! I forgot about this - sorry.

Thank you, @sanjaisid!

@SomeRandomDeveloper - thanks for pointing this out; I believe this is fixed now.

@Gorasuhl - thanks for pointing this out; I think this is fixed now.

I believe this issue was fixed by the change to Codex in T406737, so I'm closing this. I assume that the patch submitted can be "abandoned" now, since it's no longer relevant.

@Tepid_b: thank you for doing all this research! What a relief that this is not actually a Widgets bug.

In the interest of keeping things manageable, I'm closing this, since neither I nor others have been able to duplicate the problem; but please re-open this if you still see this happening.

@Taylan - thank you for the research, and the detailed explanation! Hopefully this fixes the problem.

Closing this now; this probably could have been closed a long time ago!

@SomeRandomDeveloper - thank you for these patches. The one for master is not going through because of the recent removal of the cl_to field from the categorylinks table - which presumably is also preventing commits in something like 50 other extensions that use cl_to (including some of my own). I need to modify my extensions to not query cl_to - although if you want to try your hand at fixing WatchAnalytics, feel free. (The use of cl_to in WatchAnalytics seems more involved than in most of the others.)

@SomeRandomDeveloper - yes, I'm the closest thing this extension has to a maintainer. This looks like a great improvement! If you want correct attribution, etc. for this patch, feel free to create a Gerrit patch for it, and I will check it in; otherwise I will create it myself. Either way is fine with me.

Okay, interesting. I still can't reproduce the problem, though. It might be because of the old Approved Revs version, although I don't think there have been any changes to "blank if unapproved" handling during that time. Could it be that you placed this line in LocalSettings.php before the inclusion of AR?

Great to hear! Thanks for reporting the problem.

Thank you, @TechieNK!

By the way, if anyone's curious, "CTE" = "common table expression".

Thank you, @Jayanthvikashs!

Yes, I see the problem. The loading of Sortable.js was changed about a month ago, in 4c7cd83cdce - I assume that was what broke this. @Samwilson - any thoughts on this? It seems like the require( 'ext.pageforms.sortable' ); call that was added is not working.

@SomeRandomDeveloper - this looks great! Could you submit it in Gerrit?

Fixed now, I think!

Thank you for the fix!

@Orfur - thank you for looking into this. I agree that switching to variables is the way to go - it's what I've been doing with my other extensions also. I will try to get this done soon.

There are no other subtasks for this task, if I understand your question.

Fixed, I think, thanks to @TechieNK's patch!

I just wanted to mention that this looks like a subset of T377307.