Wikipedia:Bots/Requests for approval/Monkbot 9

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

Approved.

Monkbot 9

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

Time filed: 10:16, Sunday, October 4, 2015 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): awb

Source code available: User:Monkbot/Task 9: Ship infobox lists

Function overview: replaces line-break ( , {{br}}) lists and {{plainlist}} and {{unbulleted list}} templates with generic unordered lists in the various ship infobox templates.

Links to relevant discussions (where appropriate): WT:SHIPS#lists in infobox parameter values

Edit period(s):

Estimated number of pages affected: 20k-ish

Exclusion compliant (Yes/No): yes

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

Function details: complete description at User:Monkbot/Task 9: Ship infobox lists

Discussion

I am curious to see how this works.   should definitely be replaced because of the accessibility issues, but is it worth replacing {{plainlist}} or the other template assuming nesting is not required on a particular page? How often is this construct used? — Earwig ^talk 08:43, 6 October 2015 (UTC)[reply]
I'm a bit unclear about what it is that you are asking. At the time of this writing, there are about 29250 transclusions of {{infobox ship begin}} which is required to be present in every ship-article infobox. That number defines the upper bound. At the time of this writing, Category:WPSHIPS:Infobox list errors has about 20500 articles.
Articles get into Category:WPSHIPS:Infobox list errors through Module:WPSHIPS utilities for one or more of four reasons:
1. a parameter value has  
2. excepting white space, the first characters following the parameter's assignment operator is two or more asterisks (|<param>=** <text>)
3. when a line in a standard unordered list does not begin with one or more asterisks
4. when the number of asterisks at the start of a line is more than one more than for the preceding line (from *<text> to ***<text> for example)
Though it can, Module:WPSHIPS utilities does not currently detect {{plainlist}} and {{unbulleted list}}s. If they alone are the method by which editors have chosen to implement lists in an article's ship infobox, then those articles are not a member of Category:WPSHIPS:Infobox list errors.

If you look at Special:Contributions/Trappist the monk you can see that the edits made by the task 9 script all report converting line-break lists. Shortly after I updated the ship infobox templates to use Module:WPSHIPS utilities I ran an earlier version of the task 9 script on the articles in Category:FA-Class Ships articles so there are articles where only plainlists were converted.

Because task 9 converts   to ordinary unordered lists, where it can, it also converts {{plainlist}} and {{unbulleted list}} for consistency in the whole of the infobox.

—Trappist the monk (talk) 11:00, 6 October 2015 (UTC)[reply]
I noticed that this edit does something odd – bullet points are added to the "Operators" field – but it also look like the original format wasn't quite right. Can you take a look? — Earwig ^talk 19:16, 6 October 2015 (UTC)[reply]

Yep, saw that when I made the edit and elected to allow it to stand. The parameter value is definitely broken so a case of garbage-in-garbage-out. In wikitext, two lines of text without an intervening blank line are rendered as a single line of text – the end-of-line marker is converted to a simple space. This paragraph is written one-sentence-per-line to illustrate that.

Probably the editor intended to include another   tag following the Coastguard flag. The script can't know, so it only operates on the explicit   tags. The result may look a little odd, but no more odd than it did before and, I think, even though wrong, is more meaningful to a reader.

—Trappist the monk (talk) 22:10, 6 October 2015 (UTC)[reply]

~~Hm, but shouldn't the template be making that a plain list rather than adding the bullet points?~~ — Earwig ^talk 23:00, 6 October 2015 (UTC)[reply]

Never mind, I misunderstood how the module works. This looks like the correct behavior; GIGO, as you said. — Earwig ^talk 23:56, 6 October 2015 (UTC)[reply]

Although... this edit adds bullet points to the "complement" section, but I'm not sure why, since the syntax looks correct. Same thing with this edit.
This edit is not quite right. I'm not sure if we could consider this GIGO, since the original format is technically valid. (I think?)
This edit is also leaving an odd result; again, don't know if this is an expected format. Honestly, I hate the look of the three giant flags in the header like that.
Same issue as the first one I noticed with this edit. Would it be better to have the bot skip these cases (i.e., where a parameter uses   but there are some lines not separated by them) and leave them for manual review?
Another instance of clear GIGO with this edit, leaving behind an empty parameter. Probably not worth doing anything about.

Those are the only issues I noticed. Apologies if you already fixed any of them already, since I noticed you made some changes to the bot between edits. — Earwig ^talk 01:18, 7 October 2015 (UTC)[reply]

1a. ARA Santa Fe (S-21) is broken not because of anything that the task 9 script or Module:WPSHIPS utilities did, but because of how other processing outside of my control (HTML cleaner?) mangled the malformed lists in |Ship speed= which see. Here is the raw HTML for the start of |Ship complement=:

<tr style="vertical-align:top;"><td>Complement:</td><td><ul style="list-style:none none; margin:0;"></li></ul>

and the first line of the same when the two non-list lines of |Ship speed= are prefixed with asterisks to make them part of a single list:

<tr style="vertical-align:top;"><td>Complement:</td><td><ul style="list-style:none none; margin:0;">

In the broken example, </li></ul> are closing tags from the previous (submerged speed) list. It is no wonder then that |Ship complement= renders poorly.

1b. Acasta-class destroyer is the same kind of problem; making the |Ship propulsion= parameter value a single list causes the infobox to be rendered correctly.

2. Abeille-class brig at |Ship armament= was a parameter with both   and unordered list mark up so not at all technically correct.

3. Af Chapman is a misuse of one {{infobox ship career}} template to hold three careers. The correct solution to this issue is two or three career templates instead of just the one (ARA Veinticinco de Mayo (V-2) is an example).

4. Abercrombie-class monitor is broken for the same reasons as 44-foot motor lifeboat. When (if) this bot task is approved and after it has run and presumably cleared the majority of articles from Category:WPSHIPS:Infobox list errors, I will do some work to improve the currently crude error messaging in WPSHIP utilities and then turn them on. It is, in my opinion, necessary to educate editors. Leaving malformed lists in an infobox (where they have been malformed for who knows how long) and without any obvious visual cue that there is something wrong, doesn't seem to be a good way of getting the lists fixed.

5. ARA Santísima Trinidad (1974) has a pipe left over from the conversion of a {{plainlist}} template. I agree that such leavings are harmless.

—Trappist the monk (talk) 12:30, 7 October 2015 (UTC)[reply]

I'm still a bit unsure about the first error. Why is having lists within the parameter, when it starts with non-list text, considered invalid? — Earwig ^talk 05:36, 8 October 2015 (UTC)[reply]

Beyond mishandling of unordered lists over which the infobox templates, Module:WPSHIPS utilities, and task 9 have no control (the broken html </li></ul>), lists like that in the |Ship speed= parameter in are probably best done as description lists which markup is semantically correct when compared to <some text> followed by an <unordered list>. In wikimarkup, description lists are the semicolon (term) and colon (description).

—Trappist the monk (talk) 10:54, 8 October 2015 (UTC)[reply]

Okay, that's fair. One final question: is it feasible for the template to automatically place these articles in Category:WPSHIPS:Infobox list errors on the basis of that issue? My concern is that (given the number of edits this bot will make) we'll end up with a number of slightly-broken pages without a clear way to identify which ones need this particular problem fixed. — Earwig ^talk 03:54, 9 October 2015 (UTC)[reply]

I've added a check to the Module:WPSHIPS utilities/sandbox that looks for:

|<parameter>=some text
*list item

When found, the sandbox version replaces the parameter value with an error message and adds the article to Category:WPSHIPS:Infobox list errors. Error messaging is in flux so there is not much support for them yet at the linked help page. Error messaging, if it is ever enable in the live version, will not be enabled until after task 9 has done its thing.

To see how the sandbox version works, edit USS Iowa (BB-61) and change {{Infobox ship characteristics}} to {{Infobox ship characteristics/sandbox}} and then click show preview.

—Trappist the monk (talk) 10:54, 9 October 2015 (UTC)[reply]

I really don't think it's a good idea to hide the existing list in this case. Why not do something similar to the citation templates, which show an error message alongside the rest of the citation? Or you can stick to the category alone, since I'm not convinced these errors are significant enough that they need in-text warnings. The main problem is that we are elevating a fairly minor issue, mainly of concern to editors, to something that disrupts the page for readers far more than the malformed list could by itself. — Earwig ^talk 20:27, 10 October 2015 (UTC)[reply]

I did write: Error messaging, if it is ever enable[d] in the live version, will not be enabled until after task 9 has done its thing. Is future error messaging an issue in this brfa?

—Trappist the monk (talk) 21:05, 10 October 2015 (UTC)[reply]

I suppose it's not, but rather up to the people who manage the template itself (you included). I'm speaking more as an editor than a bot approver with that comment. We're dealing with a bot that works almost all of the time, but in some cases can leave pages in a "slightly broken" state (loosely defined). That's not a problem per se, since the pages are "slightly broken" to begin with, but I want to ensure that we have a way to later detect those pages and give someone an opportunity to fix them. As long as you can do that (by category or error message) without also hiding content from readers, I'm fine with this. — Earwig ^talk 21:22, 10 October 2015 (UTC)[reply]

Regardless of whether error messages are ever enabled, the categorization is in place and will remain. Error messages do have the significant benefit of notifying editors as they edit that there is something amiss and just what that something is. If I can figure out how to have both content and error messages I'll do that. But later.

—Trappist the monk (talk) 22:11, 10 October 2015 (UTC)[reply]

(←) The reason I mention it is because the error category is lost in examples like Acasta-class destroyer. But, yes; that's a template issue, and you can add error messages later. The bot itself is fine. Approved. — Earwig ^talk 00:29, 11 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.