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 Symbol keep vote.svg Approved

Monkbot 9
Operator:

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 lists and  and  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)
 * 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  which is required to be present in every ship-article infobox.  That number defines the upper bound.  At the time of this writing,  has about 20500 articles.
 * Articles get into Category:WPSHIPS:Infobox list errors through Module:WPSHIPS utilities for one or more of four reasons:
 * a parameter value has
 * excepting white space, the first characters following the parameter's assignment operator is two or more asterisks (**)
 * when a line in a standard unordered list does not begin with one or more asterisks
 * when the number of asterisks at the start of a line is more than one more than for the preceding line (from  to   for example)
 * Though it can, Module:WPSHIPS utilities does not currently detect and 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  so there are articles where only plainlists were converted.
 * Because task 9 converts to ordinary unordered lists, where it can, it also converts  and  for consistency in the whole of the infobox.
 * —Trappist the monk (talk) 11:00, 6 October 2015 (UTC)
 * 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)
 * Because task 9 converts to ordinary unordered lists, where it can, it also converts  and  for consistency in the whole of the infobox.
 * —Trappist the monk (talk) 11:00, 6 October 2015 (UTC)
 * 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)
 * 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)

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)
 * 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)
 * 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)
 * 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)

1a. 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:

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:

In the broken example,  are closing tags from the previous (submerged speed) list. It is no wonder then that Ship complement renders poorly.

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

2. at Ship armament was a parameter with both  and unordered list mark up so not at all technically correct.

3. is a misuse of one  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 is an example).

4. is broken for the same reasons as. When (if) this bot task is approved and after it has run and presumably cleared the majority of articles from, 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. has a pipe left over from the conversion of a  template. I agree that such leavings are harmless.

—Trappist the monk (talk) 12:30, 7 October 2015 (UTC)
 * 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)
 * Beyond mishandling of unordered lists over which the infobox templates, Module:WPSHIPS utilities, and task 9 have no control (the broken html ), lists like that in the Ship speed parameter in  are probably best done as description lists which markup is semantically correct when compared to followed by an .  In wikimarkup, description lists are the semicolon (term) and colon (description).


 * —Trappist the monk (talk) 10:54, 8 October 2015 (UTC)
 * 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)
 * I've added a check to the Module:WPSHIPS utilities/sandbox that looks for:


 * =some text
 * list item
 * When found, the sandbox version replaces the parameter value with an error message and adds the article to . 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 to  and then click show preview.


 * —Trappist the monk (talk) 10:54, 9 October 2015 (UTC)
 * 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)
 * 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)
 * 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)
 * 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)

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