Community Wishlist Survey 2022/Wikisource/Fix search and replace in the Page namespace editor

Add links
From Meta, a Wikimedia project coordination wiki

Fix search and replace in the Page namespace editor

  • Problem: Like every year, we're begging to fix this bug, that it's ridicously still present. The search and replace function in the default editor is broken, and it's a basic function of every editor.
  • Proposed solution: Fix the underlying issues in the JS API leading to the search and replace function being broken. Alternatively, remove the search&replace button and replace function as a independent widget.
  • Who would benefit: All Wikisource users
  • More comments: Former submissions:

Discussion

I strongly support this proposal. Fixing known bugs should be alwais prioritized. --Alex brollo (talk) 14:11, 18 January 2022 (UTC)[reply]

Well, in fact fixing known bugs should be a routine, not a subject of annual pleading. --Jan Kameníček (talk) 00:33, 29 January 2022 (UTC)[reply]
Totally agree... — ElioPrrl (talk) 11:06, 29 January 2022 (UTC)[reply]

According to T183950, the problem here is that PRP's Page: content model breaks assumptions other parts of Mediawiki make regarding the data of a wikipage. Specifically, Page: wikipages consist of three distinct sections: the header, main content area, and footer. Other parts of the stack fundamentally assume a wikipage is one complete part. To handle this PRP overrides (among other things) the text selection methods from the jquery.textSelection plugin, but so far it has only implemented the getSelection method because that was needed to make VisualEditor work (I am unclear on what specifically this need was; VE has at least some specific knowledge of PRP for other reasons, so it's entirely possible the getSelecion override isn't even necessary any more). What it's doing is concatenating the header, body, and footer so that it can provide VE a single text unit to operate on. But when the 2010 Wikieditor's search and replace function runs, it gets the same concatenated text, meaning that when it finds matching substrings within the text it finds a range that is offset relative to the first character of the header rather than the first character of the body. PRP does not yet override setSelection, so when the 2010 Wikieditor selects the matched text it uses this offset and ends up selecting a range that is off by the number of characters in the header (which includes <noinclude> tags etc., so even an apparently empty header will throw it off). The same holds true for when it tries to replace the found text.

As a working assumption, the fix is simply to implement overrides for the other jquery.textSelection methods in PRP, in the vicinity of /mediawiki/extensions/ProofreadPage/modules/page/ext.proofreadpage.page.edit.js L385. The overrides should presumably just need to track the offset caused by the header and adjust the value when calling through to the original method. If we want search and replace to work in header and footer fields we'd need to be a little more fancy, keeping track of which ranges correspond to which text field and mapping to the correct offset depending which field we're in. To be hyper-hyper fancy we'd need to add UI to the 2010 Wikieditor to allow toggling on and of searching in the header/footer; but I don't think there is any real need for this. Just getting search and replace working in the body will be a massive improvement.

This isn't really a bug per se. Multiple parts of the tech stack have changed over the years, leading to the missing functionality (setSelection override and friends) that didn't used to be a problem now showing up as seeming bugs in other components. In other words, AIUI this should be firmly within the CommTech CW scope and ought to be a nicely manageably-sized task. tpt is also familiar with the existing code there (judging by T183950 and git blame) and has historically been very generous with their limited time in answering questions about such things. I also believe SWilson and Matmarex have touched this code for various reasons and may be able to assess whether my understanding expressed above is at least approximately correct. --Xover (talk) 11:24, 5 February 2022 (UTC)[reply]

On French Wikisource, there is another button (RegEx, in the Aide à la relecture ≈ Proofread tools tab) that performs search and replace without any bug. Maybe it suffices to implement it in every Wikisources. — ElioPrrl (talk) 19:21, 12 February 2022 (UTC)[reply]

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2022/Wikisource/Fix_search_and_replace_in_the_Page_namespace_editor&oldid=22833172"