Wikipedia:Bots/Requests for approval/Fluxbot 8

Add links
From Wikipedia, the free encyclopedia
The following discussion is an archived debate. Please do not modify it. To request review of this BRFA, please start a new section at Wikipedia:Bots/Noticeboard. The result of the discussion was Withdrawn by operator.

Fluxbot 8[edit]

New to bots on Wikipedia? Read these primers!

Operator: Xaosflux (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)

Time filed: 01:28, Saturday, June 11, 2022 (UTC)

Function overview: Clone of Wikipedia:Bots/Requests for approval/Qwerfjkl (bot) 10

Automatic, Supervised, or Manual: Supervised

Programming language(s): AWB

Source code available: N/A

Links to relevant discussions (where appropriate): Wikipedia:Bots/Requests for approval/Qwerfjkl (bot) 10, Wikipedia:Interface_administrators'_noticeboard#Clear_out_Category:Pages_using_deprecated_source_tags

Edit period(s): one time

Estimated number of pages affected: 500

Namespace(s): Primarily "user" (pages in Category:Pages using deprecated source tags - except ones in MediaWiki space).

Exclusion compliant (Yes/No): Yes

Adminbot (Yes/No): Yes (intadmin needed).

Function details: Clone of Wikipedia:Bots/Requests for approval/Qwerfjkl (bot) 10, requires an intadmin operator.

Discussion[edit]

  • I will enable 2FA on this bot account before operations. — xaosflux Talk 01:35, 11 June 2022 (UTC)[reply]
    • There are only 400 pages, so might not be worth a bot task. ― Qwerfjkltalk 07:12, 11 June 2022 (UTC)[reply]
    • I oppose moving pages from Category:Pages using deprecated source tags to Category:Pages with syntax highlighting errors by using an invalid (empty) lang, like Wikipedia:Bot requests/Archive 80 (Diff ~1084326837) did. I also oppose bluntly removing the tags from .js pages in case they appear in strings etc. Just prepend //<nowiki> to the top and append //</nowiki> to the bottom, that should fix most cases. — Alexis Jazz (talk or ping me) 11:38, 11 June 2022 (UTC)[reply]
      @Alexis Jazz if the only instances of 'source' on the script are at the top/bottom and the fix is remove: does that resolve that concern? — xaosflux Talk 11:43, 11 June 2022 (UTC)[reply]
      Xaosflux, I suppose, can't think of any problems that approach would cause. I see some uses of source tags where seemingly nowiki was intended instead. Adding nowiki to the top+bottom of Special:Search/incategory:"Pages using deprecated source tags" -insource:nowiki intitle:/\.js/ should be safe I think. That's 217 pages atm. Out of the 84 pages on Special:Search/incategory:"Pages using deprecated source tags" insource:nowiki intitle:/\.js/ some will be caught by your strategy of dealing with source tags that only appear at the top/bottom. Hopefully after that the number of pages left will be low enough to sift through by hand. Actually that's already doable for 84 pages, but if we can drop that a bit further that would be convenient. — Alexis Jazz (talk or ping me) 11:57, 11 June 2022 (UTC)[reply]
      These will still mostly be "by hand", I don't plan on letting this run loose on script pages. — xaosflux Talk 11:59, 11 June 2022 (UTC)[reply]
      Xaosflux, given what WOSlinker said below, I also oppose removing source tags from the top and bottom as they may currently prevent parsing of whatever is inside. Replacing top source tags with <syntaxhighlight lang="text> and bottom closing source tags with </syntaxhighlight> would be safer in that case. Maybe a regex like /^\/\/[ ]*<[Ss]ource>([^]*)\/\/[ ]*<\/[Ss]ource>$/ (replace with //<nowiki>$1//</nowiki>)? — Alexis Jazz (talk or ping me) 12:22, 11 June 2022 (UTC)[reply]
  • Noticeboard notice left at Wikipedia:Administrators'_noticeboard#Adminbot_BRFA. — xaosflux Talk 01:38, 11 June 2022 (UTC)[reply]
  • I clicked on a few random pages in that category, 1, 2, 3, 4, all of them have literally no use for syntax highlighting - can we just remove the tags instead of trying to "fix" them? Legoktm (talk) 04:44, 11 June 2022 (UTC)[reply]
    I'm a bit concerned over removing them from .js pages, as mentions of it regularly in a string (E.g. console.log("<source></source>")) or similar will still get it added to the category - its not just in // comments. Aidan9382 (talk) 05:19, 11 June 2022 (UTC)[reply]
    @Legoktm I'm fine with removing it as well; @Aidan9382 I can expand this slightly to include those cases - so remove if it is in the top/bottom comments, convert if in a log - will that satisfy your concern? — xaosflux Talk 10:19, 11 June 2022 (UTC)[reply]
    I'll be honest, its probably quite a rare edge case. I could imagine you could get away without having to handle an edge case just fine, but if you really wanted to cover it, just (somehow) make sure that the <source> tag isnt inside a string and that'd do a fine enough job - if it is, probably best to replace it instead. Aidan9382 (talk) 11:55, 11 June 2022 (UTC)[reply]
    If this results in a "just do it on your main account" - this is still good feedback for how to best deal with this one-time thing as well. — xaosflux Talk 11:00, 11 June 2022 (UTC)[reply]
    On some pages, the source/syntaxhighlight tags are no use but on others, it stops the javascript code transcluding templates and/or being added to categories due to the code on the page. -- WOSlinker (talk) 11:55, 11 June 2022 (UTC)[reply]
    The source tag at top and bottom of the uses javasript page was added in some cases to stop items appearing at Special:WantedTemplates. This could also be done with nowiki instead though. -- WOSlinker (talk) 12:05, 11 June 2022 (UTC)[reply]
  • Rather than replacing <source> with <syntaxhighlight lang="">, on .js pages, could we replace <source> with <syntaxhighlight lang="javascript"> and on .css pages replace <source> with <syntaxhighlight lang="css"> if the lang is not included? -- WOSlinker (talk) 11:51, 11 June 2022 (UTC)[reply]
    That certainly makes more sense, assuming we should keep the tag at all. I'm certainly fine with this BRFA being a "what is the best way to deal with this" discussion, there is no urgency on this. — xaosflux Talk 11:56, 11 June 2022 (UTC)[reply]
    WOSlinker, as an empty lang parameter just puts the page in Category:Pages with syntax highlighting errors that's already better, but actually I'd suggest <syntaxhighlight lang="text"> which is valid and behaves the same as a source tag without lang parameter. None of this stuff is actually visible when viewing these pages. — Alexis Jazz (talk or ping me) 12:07, 11 June 2022 (UTC)[reply]
    @Alexis Jazz, for syntaxhighlight in general, so you know what lang should be used for wikitext? I'm aware of tid but I believe there's another. ― Qwerfjkltalk 13:42, 11 June 2022 (UTC)[reply]
    @Qwerfjkl "wikitext" isn't a supported language for syntaxhighlight. And most of these pages actually are js/css; that being said for the pages that actually are js/css here - they are already opening in the js/css editor, and the highlight doesn't render on the page viewer - so they seem a bit useless -- is there any good reason to actually keep these? — xaosflux Talk 15:03, 11 June 2022 (UTC)[reply]
    Qwerfjkl, see mw:Extension:SyntaxHighlight#Supported languages. Xaosflux, the highlighting is useless but they prevent templates/links/etc inside from being parsed which could otherwise result in entries in WhatLinksHere, WantedCategories, WantedPages, etc. But lang=text or nowiki works just as well for that. — Alexis Jazz (talk or ping me) 15:51, 11 June 2022 (UTC)[reply]
    @Alexis Jazz agree, I think remove source tags when "wrapping" the whole page and replacing with nowiki may be the best solution for these user scripts. — xaosflux Talk 15:59, 11 June 2022 (UTC)[reply]

Arbitrary break / discussion restart[edit]

So... where are we with this? The discussion above has some proposed tweaks and changes but it doesn't sound like any specific resolution was agreed upon. Is this good to go ahead, has the task already been done manually, or is there more to discuss? (please do not ping on reply) Primefac (talk) 16:44, 6 August 2022 (UTC)[reply]

Nothing ever moved on this; there are still about 400 of these. As far as a new strategy, I think it's safe to limit this to:
  1. userjs and usercss pages
  2. that are in js/css/scss content models
  3. where the "source" tags are in a comment
And have the fix be:
  1. remove the source tags
These tags are doing nothing in the comment, and the wikitext editor already uses the markup editor on those pages.
I can do a couple examples on my own account if that would help? If this is still too contentious, I'll just withdraw - some intadmin (maybe me) will prob get around to these one day when we have nothing else to do :) — xaosflux Talk 21:53, 6 August 2022 (UTC)[reply]
  • Withdrawn by operator. well this has gone nowhere, so just w/d'ing. — xaosflux Talk 13:58, 29 August 2022 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. To request review of this BRFA, please start a new section at Wikipedia:Bots/Noticeboard.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Bots/Requests_for_approval/Fluxbot_8&oldid=1107342569"