Wikipedia:Bots/Requests for approval/BU RoBOT 5

The following discussion is an archived debate. Please do not modify it. To request review of this BRFA, please start a new section at WT:BRFA. The result of the discussion was

Withdrawn by operator.

BU RoBOT 5

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

Time filed: 02:34, Sunday, September 13, 2015 (UTC)

Automatic, Supervised, or Manual: Automatic

Programming language(s): AWB

Source code available: AWB, regex available upon request

Function overview: Replaces {{Cfd result}} with {{Old CfD}}

Links to relevant discussions (where appropriate): Wikipedia:Templates_for_discussion/Log/2014_June_5#Template:Cfd_result

Edit period(s): One time run

Estimated number of pages affected: 7,706

Exclusion compliant (Yes/No): Yes, as per AWB default

Already has a bot flag (Yes/No): Yes

Function details: The bot replaces {{Cfd result}} with {{Old CfD}} as per the result of the TfD linked above by making appropriate changes to the various parameters. General fixes will be turned off. To avoid confusion, this bot uses regex to make the conversion and is not substituting the template, as is often done.

Discussion

Wikipedia:Categories for discussion/Administrator instructions should be updated, possibly in addition to scripts that use the templates (I don't know if they exist, but if they do). I suppose the choice of which to merge into which is minor; {{Old CfD}} has a couple more options but I don't like the way it takes dates, and has slight visual differences with the {{Old TfD}}, {{Old MfD}}, etc. family. Can we see the regex? — Earwig ^talk 20:18, 13 September 2015 (UTC)[reply]

I had planned to update WP:CFD/AI after the bot run. Once the change is more-or-less complete, I plan to post to WP:AN and CfD's talk page about the change as well to ensure people know about it. Personally, I don't edit in the area of CfD, so I don't know what modules may exist. I'm out of town until Tuesday, so I'll supply the regex when I get back. I'll modify Template:Old CfD (edit | talk | history | links | watch | logs) to take a generic date parameter in the near future, with support for the piped dates as well. Probably with |date2=, but maybe with a module that allows both forms to be entered in the single date parameter. ~ Rob^Talk 20:31, 13 September 2015 (UTC)[reply]

Actually, looking at the template source it seems it already supports |date= with the full string. Hmm, perhaps a documentation update is all we need. Sounds good.

Approved for trial (50 edits) Please provide a link to the relevant contributions and/or diffs when the trial is complete., contingent on being able to review the regex when you get a chance. — Earwig ^talk 20:55, 13 September 2015 (UTC)[reply]

Heh. After working on a module for an hour and failing miserably, I checked the template and realized the same thing, only to come back here and find you beat me to it by a half hour. I'll adjust the regex appropriately and post it here for approval before running the trial. ~ Rob^Talk 21:30, 13 September 2015 (UTC)[reply]

@The Earwig: You can find the regex at User:BU RoBOT/Task 5 Regex. Note that the only thing left to do, now that we've realized the more general date format is accepted in this template, is to move things from the unnamed parameter to the "name" parameter. It'll also swap the template name if it makes that edit. After the bot run is complete, Cfdresult can redirect to Old CfD to finish things up. Ping me when you've taken a look at the regex to let me know if I'm okay to go ahead with the trial. ~ Rob^Talk 01:31, 16 September 2015 (UTC)[reply]

@BU Rob13: Okay, you can go ahead now. — Earwig ^talk 03:51, 16 September 2015 (UTC)[reply]

The trial was a disaster, and I've mass rollbacked my edits. I'm withdrawing this BRFA. ~ Rob^Talk 22:26, 16 September 2015 (UTC)[reply]
@BU Rob13: I will mark it as withdrawn in a moment, but I am curious what went wrong. What's the procedure moving forward with the template merging? — Earwig ^talk 23:07, 16 September 2015 (UTC)[reply]
I discovered two minor errors early on that I attempted to fix. First, some of the regex wasn't greedy enough. For instance, "\s*(?!date)" would allow through " date" because it would interpret \s* as adding no spaces and then the next character would be the space, an allowed character by the negative lookahead. That was an easy fix. The more problematic issue was that pipes in links were being interpreted as parameters, causing issues. I attempted to fix that and somehow screwed up big time, resulting in edits that would rename the template and do nothing else. That shouldn't be possible, because the template name changes were subrules and proper restrictions were placed on the primary rule to prevent the subrule from being reached if the primary rule was not used. This is likely a problem in my corrected regex, and I don't have the time to figure it out. As for the way forward, I created Template:Cfd result/sandbox, which should be good to substitute, but frankly I don't trust my competence on that after a long day of screwing up. Possibly Alakzi could take a look; he's much better with templates than I am. I tested it in my sandbox with odd results. When it's substituted, it works fine, but when it's not substituted, the template doesn't transclude, which is characteristic of normal substitutions, not the safe substitutions I used. That doesn't make a lick of sense to me. ~ Rob^Talk 00:03, 17 September 2015 (UTC)[reply]
Understood. Parsing wikicode with regex is always a slippery slope; that's why tools like mwparserfromhell exist, but I have no idea how AWB handles that kind of thing. A merge wherein one template changes its appearance to be identical to the other seems like a good first step. I don't see why we can't change {{Old CfD}} to accept the parameters of both templates, and redirect {{Cfd result}} to it. {{BotWithdrawn}} — Earwig ^talk 01:38, 17 September 2015 (UTC)[reply]
I've reopened this request as per our talk discussion. The sandbox for substitution apparently works fine; it didn't transclude because the ! magic word isn't detected as a pipe, so the template is just presented as plain text until you substitute it and the pipe substitutes along with it. I think this is the best way forward as it preserves future simplicity of the template. If we start throwing in a lot of if statements and such to allow the parameters to work in different ways depending on how they're presented, we're going to make the template more difficult to maintain for very little short-term gain. There's also some tricky edge cases that are of concern. For instance, if there's existing transclusions of {{Old CfD}} with the date placed without pipes, that would be taken as a section if we used a simple if statement to interpret {{{1}}} as a section unless {{{2}}} is present. We'd have to do something fancy with regex (needing a module, possibly) to differentiate between a single unnamed parameter with a full date and a single unnamed parameter with a section name. Not worth the cost of time now and maintenance later. ~ Rob^Talk 04:14, 28 September 2015 (UTC)[reply]
- Would you like to repeat the 50-edit trial? — Earwig ^talk 04:18, 28 September 2015 (UTC)[reply]
  - It's entirely up to you. The manner of carrying out the task is entirely different from the original proposal, but technically speaking, this is almost identical to other tasks that I've had approved, such as task 2 and the pending task 6, which has had a successful trial with the exception of some issues related to the way the wrapper substituted handled categories. I've already tested the wrapper used here in my sandbox, and it's fairly simple to begin with. I'll leave it to your experience to judge whether this is something that could be "speedily" approved or not. As a side note, the issue of empty parameters that occurred in task 6 is not present here. ~ Rob^Talk 05:00, 28 September 2015 (UTC)[reply]
- @BU Rob13: I just created Template:Old CfD/sandbox as a merger (diff). This seems workable to me. What do you think? — Earwig ^talk 01:26, 1 October 2015 (UTC)[reply]
  - @The Earwig: Personally, I'm very against this method of merging templates. A template merge is meant to merge functionality, not duplicate functionality and complicate the template. This results in different transclusions of the same template potentially looking very different. It makes it harder for editors to look only at the wikicode for the template and know what's going on. The only solution to that is detailed documentation, but that's likely to confuse as well. For instance, an uninformed editor, upon seeing all the different cases, may try combining them (i.e. using piped dates and an unnamed section parameter), which would cause an error. The majority of editors do not know much about how templates work or are coded. They just want to be able to look at the wikicode, look at the documentation in a few seconds, and be able to tell what's going on. We're seriously compromising that if we start unnecessarily introducing all these different cases in which the template behaves differently. I also question what this template (or any template, for that matter) would look like if it underwent 2-3 more merges using this method. ~ Rob^Talk 02:38, 1 October 2015 (UTC)[reply]
    - Well... okay, but that last point is surely a slippery slope. The template was fairly complicated to begin with due to supporting the alternate, awkward date format; the only thing I added was support for {{{1}}} as a section name along with an explanatory comment (which we could even make standard now, since it is a bit cleaner, but that's neither here nor there). There was actually a bit of simplification with respect to the old date format handling. I should point out there's no great variation in appearance depending on arguments. As for documentation, that template already has documented and undocumented deprecated functionality (usercat and alternate date syntax, respectively) – no reason why we can't simply state "here is the normal format, here is the legacy format that you shouldn't use but is explained in case you see it anywhere". I think most editors are capable of understanding that. Wikicode complexity is debatable, but surely the ugliest part of this template is something we have no control over, and I can add some extra comments to explain how it works if you prefer. — Earwig ^talk 02:55, 1 October 2015 (UTC)[reply]
      - I guess my background as far as this goes comes from {{Infobox NFL player}}, which I've done some work with. That template is a mess due to plenty of merges and legacy parameters that have been left lying around either in the code or in wikicode scattered across thousands of articles. That's an example of how the little things add up, in my opinion, to the point where that template can be hard to figure out sometimes. Dirtlawyer1 has been spending time coming up with a list of maintenance tasks that need to be carried out on that template to make it more reasonable, and those are lost man-hours that could be used on something more useful if the template had been better maintained right along. I'm hesitant to take any first step toward unnecessary complexity when there are other alternatives. I just don't see the point of introducing new functionality and immediately marking it as legacy when a simple substitution fits the same need and reduces complexity. This might be a fundamental difference of opinion, though, and who knows, maybe I'm in the minority. It would be worthwhile to bring in some other editors who are more familiar with merging than I am to comment on which they believe should be preferred here. Off the top of my head, Pigsonthewing could definitely comment, but the only other editor I know who regularly handled merges is indeffed now, so it would be helpful if you could invite any that you know to the discussion as well. ~ Rob^Talk 03:39, 1 October 2015 (UTC)[reply]
        Yes, I would definitely like to see more input on this. Unfortunately no one comes to mind at the moment, but let's see who is willing to comment. I don't have a very strong opinion here, but my general philosophy is to avoid using a bot when a problem can be solved by (relatively) minor template modifications. Let's see. — Earwig ^talk 04:26, 1 October 2015 (UTC)[reply]
        @BU Rob13: You rang? How may I help here? Dirtlawyer1 (talk) 04:53, 1 October 2015 (UTC)[reply]
        @Dirtlawyer1: It was more of a tangential mention, but now that I think of it, you probably would have an opinion on this. Which is more desirable in merging two templates that have identical functionality but conflicting parameters: a bot run to substitute a wrapper of the merge target or changing the merge target's template to contain switches and various if statements to handle the conflicting parameters and then redirecting? Such a wrapper looks like Template:Old CfD/sandbox. By conflicting parameters, I mean that one template uses {{{1}}} for one thing, and the other uses it for another purpose. Your name came up because I noted {{Infobox NFL player}} as an example of a template that has become fairly complicated and messy due to little unnecessary complications that have built up over time due to merges and various changes in consensus (such as those deprecated parameters we had discussed a while back, which are still in the main space all over the place). ~ Rob^Talk 05:00, 1 October 2015 (UTC)[reply]
        Without knowing more, Rob, my best answer is "it depends." If it's a clean merge, and there is no particularly good reason for maintaining separate wrappers, I generally prefer a single clean template as a result. Give me the short version: What purpose(s) do these templates serve? How many total transclusions of each template are there? How important are these templates? Dirtlawyer1 (talk) 05:33, 1 October 2015 (UTC)[reply]

@Dirtlawyer1: The two templates are essentially identical in function, and there are thousands of transclusions for both. They are used on talk pages of categories that went through the WP:CFD process to keep track of the discussion and note the result. The decision to merge has already been made at TfD; it's just a matter of how we merge. I've argued for a straight up substitution of the wrapper I created so that all transclusions look alike in terms of wikicode and we don't have to complicate the template code. Earwig has suggested that a bot task isn't needed here, and we can instead add various parser functions to the merge target and then just redirect to the target. The plus side of this is that no bot is needed and we don't need to make thousands of edits, but the result is a template that is slightly more complicated. We disagree over whether that's a serious issue. Feel free to correct me if I'm not summarizing your stance appropriately by the way, The Earwig. ~ Rob^Talk 06:25, 1 October 2015 (UTC)[reply]

For an idea of the added complexity, compare {{Old CfD}} to {{Old CfD/sandbox}}, by the way. The handling of the {{{1}}} parameter with relation to the section is the difference. ~ Rob^Talk 06:29, 1 October 2015 (UTC)[reply]
Yep, that's a fair summary. I do agree with you about avoiding complexity in many situations, but in this particular one, I think the added complexity is minor enough that combining the templates is fine. — Earwig ^talk 06:51, 1 October 2015 (UTC)[reply]
So, like, what are the main outstanding issues? If there's an issue with numeric versus named parameters or a conflict in their order that can't be solved by the template being easily intelligent about understanding which is which, could it be more user-friendly to just fix this all in one go (e.g. convert all to named), even if it means visiting transclusions to fix parameters? It's less ideal, but if there are a bunch of edge cases lying around or it's going to be a nightmare using the post-merge template because it's too picky or unstable for existing transclusions or something else, might it be less stressful to clean up all transclusions of both with "the new format" all in one go so we don't have to worry about it again? I mean, past a certain point, it's entirely valid to scrap the old and start fresh if need be—you'd just need to ensure any existing scripts ideally don't break (or, at least, their maintainers are notified in advance). The goal of "merge" isn't necessarily to ensure backward-compatibility and interoperability; it's fundamentally to change "2 templates" into "1 template," usually for the sake of human ease-of-use, because it sucks having to be familiar with and learn two different template syntaxes (or have to constantly consult the docs). --slakr^\ talk / 05:13, 2 October 2015 (UTC)[reply]
- The main outstanding issue is more-or-less a difference in opinions over whether it's more desirable to do a bot run for longer-term simplicity or avoid a bot run and make things slightly more complicated. Our opinions appear to differ over whether the complication is a big deal or warrants a bot run. The last sentence of your comment sums up my stance better than I have been, so I'll steal it. Having two distinct but overlapping syntaxes in a single template, even if the coding isn't necessarily hugely complicated (it's less than I thought, admittedly), forces users to be aware of two different syntaxes within one template. It's especially problematic for newer editors. As Slakr points out, that's generally what a merge is done to avoid. ~ Rob^Talk 06:01, 2 October 2015 (UTC)[reply]

The only overlapping syntax that is being added by the proposed change is |1= as an alternative for |action=. The date parameter weirdness doesn't count, because that was changed a while ago; the docs don't even mention it anymore and it's kept around for the very same legacy reasons, but I don't see anyone saying we should get rid of it in existing transclusions. Users do not need to be aware of the alternate syntaxes here unless they are closely investigating wikicode in old talk pages, and by that point, they're already on their own. Also, this template is only used by admins (or people making NACs), who aren't exactly clueless template newbies, so the whole point about making things easier for "newer editors" is pretty ridiculous. Everything you guys are saying is absolutely true and valid in general, but in this case, I haven't heard a single convincing reason why it should apply. Anyway. That's enough for me here – I'm not interested in pursuing this discussion further, so I'll let slakr or another BAGer continue. — Earwig ^talk 06:59, 2 October 2015 (UTC)[reply]

To clarify a point you made, I absolutely would support a bot run to remove the old date syntax, but that flies in the face of WP:COSMETICBOT, so I haven't brought it up (and won't). I know I'm in the minority there. ~ Rob^Talk 09:01, 2 October 2015 (UTC)[reply]

Withdrawn by operator.. We can do it via changing the template and redirecting. ~ Rob^Talk 07:03, 4 October 2015 (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 WT:BRFA.