Wikipedia:Templates for discussion/Log/2023 January 22

{{cob}}

• Oppose - The current scheme, using this box in conjunction with the other boxes as noted, was devised many years ago as a technical solution to a series of issues that occurred with the previous "merged" boxes, which looks like what you are proposing to return us to. This template is used on over 15,000 pages, so we cannot afford to have it not work perfectly, which it does right now. I cannot support any changes to this unless you can detail the exact technical changes you are proposing to make and we have seen them properly tested and trialled to ensure they work across a wide range of articles and situations. This is a highly technical issue and not one that can be addressed by people casually dropping by this discussion and leaving an opinion. We really need to hear from the technical experts who devised this solution in the first place, in particular {{ping|Rlandmann}} who was instrumental in creating this. As we have seen already today, getting even one item of syntax wrong instantly breaks 15,000 articles. So please please either propose your exact technical changes in detail and subject them to an appropriate level of review and testing or withdraw this. - Ahunt (talk) 16:14, 22 January 2023 (UTC)
• :What precise issues are you referring to with {{tq|a technical solution to a series of issues that occurred with the previous "merged" boxes}}?
• :{{tq|getting even one item of syntax wrong instantly breaks 15,000 articles.}} This is not itself a reason not to merge templates.
• :{{tq|This is a highly technical issue and not one that can be addressed by people casually dropping by this discussion and leaving an opinion.}}, TFD is such a place, and even were it not, the implementers of complex changes at WP:TFDH know what they're doing. Izno (talk) 22:27, 22 January 2023 (UTC)
• ::There is no need for you to try to refute every post in this discussion. Wikipedia:Don't bludgeon the process. - Ahunt (talk) 00:33, 23 January 2023 (UTC)
• :::BLUDGEON is an appropriate citation when either a) we're going in circles or b) the points one is making (or responding to) are all the same. All 4 responses I made responded to something different, and were unique to those comments. You are welcome to refute all or none of them at your leisure. Izno (talk) 00:54, 23 January 2023 (UTC)
• Oppose per {{u|Ahunt}}. We could probably do something more technically elegant in a single template, but my long experience of web coding is that tables are robust, and that breaking a semantically complex presentation into chunks is also more robust and easier to maintain than trying to be clever. I did actually try once, on another aviation template for aircraft specs, and ran into conflicts between wikitext's and html's treatment of, as I recall, bulleted lists in certain circumstances. Semi-manual identifying and fixing of thousands of articles would have been necessary, so the makeover was canned. I would caution against wasting your time the way I wasted mine. — Cheers, Steelpillow (Talk) 16:57, 22 January 2023 (UTC)
• :{{tl|infobox}} supports lists fine. It also supports chunking fine if that's really seen to be necessary, but in most cases it's not, and can be implemented by use of reasonable whitespace in the template's documentation. Izno (talk) 22:27, 22 January 2023 (UTC)
• ::I am sure you know what you mean, but I fail to see how it relates to the points I made. — Cheers, Steelpillow (Talk) 05:47, 24 January 2023 (UTC)
• :::Oh, I just realized I responded to your own non sequitur. :) It's totally irrelevant the issues you had with another template, but even if they somehow weren't, lists aren't broken in this circumstance. Izno (talk) 07:57, 24 January 2023 (UTC)
• ::::Like I actually said, the problem was incompatibilities. Lists coded for one template version may not come our right when the template code is changed. This especially applies to indented lists-of-lists. There can be a lot of funny lists in these aircraft articles, and breaking an arbitrary bunch of them is not helpful. But hey, if you can get away with it then maybe I'll be allowed to revisit my old scheme too. Yeah, I should back off and leave you the field. ;-) — Cheers, Steelpillow (Talk) 09:01, 24 January 2023 (UTC)
• Oppose. If it ain't broke, don't fix it. — Red-tailed hawk _(nest) 17:10, 22 January 2023 (UTC)
• :It is broke. Please ensure you engage fruitfully with the nomination. Izno (talk) 22:18, 22 January 2023 (UTC)
• ::Define "broke". It works for me. — Cheers, Steelpillow (Talk) 05:48, 24 January 2023 (UTC)
• :::BilCat lists one. I list another below. In general though, it also doesn't fit the general expectations for interaction with an infobox, which is what causes the specific issues that BilCat identifies. Izno (talk) 07:56, 24 January 2023 (UTC)
• ::::Well, I am not clear that little-used and can be broken are the same thing as actually broke. OTOH BilCat does highlight that the parallel ships reworking has not found it all plain sailing (sic). — Cheers, Steelpillow (Talk) 08:51, 24 January 2023 (UTC)
• Oppose The different subjects need different parameters. If a single infobox template was created with all the parameters needed for all the different cases many editors would feel compelled to complete all the fields even if there were template instructions to only use the parameters needed, it happens all the time in templates. The editors that do this are the same ones that enter 'none' in fields that if left blank have the same effect. With all the fields completed the infobox would be longer than most articles/pages, we see this in motorcycle articles with Template:Infobox motorcycle, in this article the infobox is longer than the article text, creating large areas of white space, and that is with eight fields left blank. I see no problems at all with the current system, I've used it to create 20 aircraft articles and approx. 120 aircraft engine articles. Nimbus (Cumulus nimbus floats by) 21:08, 22 January 2023 (UTC)
• :"All the fields will get filled out" happens with all templates, even templates that don't look like a singular template. There's no fundamental solution to that except to remove parameters from templates, regardless. Hiding them away where people don't know to use them is not appropriate. Izno (talk) 22:27, 22 January 2023 (UTC)
• Merge per nom. This also supports my my TemplateStyles mission (as does the {{tl|infobox ship}} merge). Izno (talk) 22:27, 22 January 2023 (UTC)
• Oppose single infobox - The table format is outdated, and need to be updated to a current infobox system. As such, I personally asked Primefac to look at updating this. He prefers a single infobox over modules, as that is the current trend on Wikipedia. He also preferred to go the TFD route to get wider community input, rather than directly approaching WPAIR as I had requested. However, IIRC, the infoboxes can still be updated to use a modular template approach, scrapping the now-rare table system. This would at least bring our infoboxes up to date, and allow easier maintenance. Right now, the table format can easily be broken in an article, often. by a single space, as many editors aren't familiar with the table coding. BilCat (talk) 22:34, 22 January 2023 (UTC)
• Support merge as the current approach is outdated and can easily be broken. Perhaps a description of the proposed solution can be presented including how it would be implemented would help with any concerns. Gusfriend (talk) 00:17, 23 January 2023 (UTC)
• support merge votes to keep seem to miss the point... All infoboxes should be standardized. IF this can be done so that there is ONE infobox template needed (not a series of them) without any loss of information, there is no reason not to. To be clear, my udnerstanding is that once merged no info would be lost. STRONGLY support this work being done! Plus, as noted above, there is already WP:PRECEDENT: infobox ship discussion --Zackmann (^{Talk to me}/_{What I been doing}) 19:08, 23 January 2023 (UTC)
• :The ships infobox hasn't been done yet either, as it's stalled for several reasons, lack of support by the major project that uses it being the main factor. BilCat (talk) 02:18, 24 January 2023 (UTC)
• ::Templates are merged all the time without support of a major project (and in a few cases, with some venom by that major project). WikiProjects don't make the decisions around here. I do think there are some things that are different about infobox ship that don't precisely fit the standard infobox mold, but those should be workable; the items I'm thinking about are similar to this template, so what is done here will probably have an analog there. Izno (talk) 19:51, 24 January 2023 (UTC)
• :::Projects do a lot of work in maintaining articles within their purview, and being hostile towards any of them is not beneficial in the long run. Not everything on Wikipedia has to be the same. And please stop badgering. Your hostile attitude.here is not helping in an already tense situation. BilCat (talk) 22:17, 24 January 2023 (UTC)
• ::::The ships template isn't done because it hasn't been done, not because it can't be done. One editor started working on it, then stopped. I have not yet stepped in because I was unsure of whether that editor was going to restart their work (and nothing is more annoying than edit-conflicting with someone on a template merger). I suspect others are in the same boat as me. The holding cell is not a graveyard where template mergers go to die, it is (as the name suggests) a holding cell, where we list the to-do list from projects that are not simple fixes. Primefac (talk) 09:53, 25 January 2023 (UTC)
• ::::I'd second the observation by {{u|BilCat}} that apparent hostility is unhelpful here. WikiProjects generally understand the subject-matter layout issues of a given template better than the template specialists do, and can bring a lot of practical experience to them. Project members participate in consensus-building every bit as much as template experts do. WP:OTHERSTUFF cuts both ways; just because a solution is theoretical flavour of the month and politically correct for many templates, does not mean it is the best answer for all of them. Nobody owns template design, any more than we own page content. We need to stay cool. One or two folks have suggested that prototyping the proposed change, before seeking consensus on its rollout, would be a smart move. I would agree. This discussion could therefore be canned, and a new one await the appearance of the proposed replacement. — Cheers, Steelpillow (Talk) 10:46, 25 January 2023 (UTC)
• :::::And I second the proposal to put this on hold until a replacement can be presented. BilCat (talk) 11:26, 25 January 2023 (UTC)
• ::::::As has been said every damn time this terrible argument comes up, no one is going to come up with a replacement before nominating a template, unless the outcome is exceedingly trivial. A template merger like this would probably take me at least four hours to accomplish, let alone the time spent testing to make sure everything was working as intended. I can guarantee you no template editor is going to put in that much effort only to be told "oh, sorry, we don't want this change". I have been working TFD for almost a decade now, and I have yet to see a template merger that wasn't (eventually) successfully completed, with all the bells and whistles and zero loss of functionality. We don't do a half-assed job here. I'm not trying to be unhelpful or hostile, I'm just telling the truth. "Give us the finished product first" needs to be added to WP:AATFD because it is simply a nonsensical argument. Primefac (talk) 13:12, 25 January 2023 (UTC)
• :::::::I have seen plenty of wiki code rolled back or abandoned because it was not fit for purpose. I have seen plenty of commercial and F/LOSS software/web designs etc. grind to a halt for the same reason. A few of the wiki templates I have offered over the years suffered exactly this fate (the majority have been well received). Don't get me wrong, I am in favour of this merger if it makes the editors' and maintainers' lives easier (ideological "best practice" leaves me cold). But, like any use case, that is a big "if". User bases need to be reassured. "Go ahead and break things" is autocratic, not consensual. I suppose we could agree something like yes, go ahead in dev space, but do not roll it out until there is a consensus that it has passed testing and really does make everybody's life easier (which IMHO will take an awful lot longer than it took to write it). But since that requires a post-testing consensus discussion anyway, there is really nothing gained; either way you just have to accept that a wider community consensus can veto what it doesn't like. If nobody can be arsed to take the trouble on spec, then frankly it is probably not worth taking. — Cheers, Steelpillow (Talk) 14:21, 25 January 2023 (UTC)
• ::::::::I agree with User:Steelpillow and User:BilCat here, I am not in favour of anything that has not been properly designed, fully tested and shown to work over all cases, including the unusual and corner cases, before it is implemented. Right now you are seeking consensus for a blank cheque on what is nothing more than a vague concept, not an actual replacement template. There has been nothing concrete here presented that can be agreed to. Like Steelpillow, I have seen too much in the way of large scale changes rolled out and have had to be all undone because it was not properly tested and broke a lot of articles. You are not going to get a consensus here to just go and do this without knowing if it works or not. With over 15,000 articles relying on this template, it is just too important to get it even a little bit wrong. If you are confident that a new template can be built and made to work well in all cases, then there should be no problem with prototyping it and testing it. If it works then it will easily gain support for implementation and if not it won't break 15,000 articles. - Ahunt (talk) 18:34, 25 January 2023 (UTC)
• :::::::::If you want proof-of-concept, look at my tenure at TFD, and look at the hundreds of template mergers I have enacted over the years. I know the merger will work, because I have done this type of merger. I will sandbox it, test it, do small-scale conversion tests, and if necessary repeat until the end product is the same as the original, barring the inevitable minor changes in format and input code.
• :::::::::As I said before, I am not going to spend 4-5 hours of my life coding something on the off chance that it makes you happy, because it might not sway your opinion and I will have wasted my time, much like me saying the same thing over and over in this discussion and you repeating the same thing over and over. If I'm not going to change your mind, then stop posting and let others discuss. This is certainly the last I'm going to say about it. Primefac (talk) 20:45, 25 January 2023 (UTC)
• ::::::::::I am happy to support a proposal for a template that exists and has been shown to work, but templates do not function on reputation and I am not seeing any new template proposed here, just some "trust me" promises. Personally I am not going to support a proposal to switch to using a template that doesn't exist and there seems to be a number of other long-term editors here with that same concern, because we have all been bitten too many times before. Unless you can show us the new template and we can see if it works, then, with currently four in favour (including yourself as nominator) and five opposed, I think you will find we are at a "no consensus to proceed" impasse here and we can probably close this discussion. - Ahunt (talk) 21:09, 25 January 2023 (UTC)
• ::::::::::Agreed. Those without the courage of their convictions are best out of it. Like I said earlier, these aviation templates can have some odd quirky instances and we will need time to work through a representative test sample of those 14,000-odd. — Cheers, Steelpillow (Talk) 09:42, 26 January 2023 (UTC)
• :::::::::::{{yo|Primefac}}, obviously our table-based system needs updating, which is why I approached you in the first place. It's my hope that whatever infobox you develop will be the basis of a future infobox for aircraft, whether that be a single infobox, or one with multiple modules. So you won't be wasting your time, even if the outcome isn't exactly what you want. Also, my comments about hostility were never directed towards you. You been entirely civil through this in my opinion. BilCat (talk) 10:48, 26 January 2023 (UTC)
• ::::::::::::I'll second that. — Cheers, Steelpillow (Talk) 11:34, 26 January 2023 (UTC)
• Comment: Aero engines. I do wonder whether the Template:Infobox aircraft engine would be better refactored as a standalone template. It is not a viable use case to mix'n'match it with the aircraft-specific templates. Also, in engineering generally there are multiple applications for engines, such as vehicles and industrial plant; for two more of these we have Template:Infobox engine (internal combustion) and Template:Infobox rocket engine (spacecraft), while there is none for say marine engines or industrial gas turbines. There is clearly scope for template rationalisation there (IMHO time far better spent than questionable tinkering with what is not even broken). So whether or not anyone wants to have a go at the present merge, I'd suggest breaking out the aero engine articles by, say, cloning Template:Infobox aircraft begin, then merging the clone with Template:Infobox aircraft engine. This leaves a cleaner path to whatever future we go for. — Cheers, Steelpillow (Talk) 09:42, 26 January 2023 (UTC)
• :That's a very interesting proposal. However, WPAIR has long preferred to have the specs separate from the infobox. Do we really want to change that for aeroengines? However, it's definitely worth dicussing, but probably not here. The aeroengine coding can easily be taken out of a unified aircraft infobox in the future if need be, so we don't have to make a final decision on that now. BilCat (talk) 10:34, 26 January 2023 (UTC)
• ::Maybe in the first instance it would be a decision for the template coder, then. — Cheers, Steelpillow (Talk) 11:34, 26 January 2023 (UTC)
• Support I was actually looking into doing this a few years ago when I was involved with the aircraft specification mergers. My conclusion then was that this could be done and done well but require quite a lot of work which I wasn't excited to do at that point. If Primefac (which is arguably the best person there is at performing complex template mergers) wants to do this I'm all for it. They will almost certainly be able to implement it more smoothly then I did the {{tl|Aircraft specs}} merger and I think the benefits will be of a similar magnitude as for that merger which I believe are considered substantial. I also want to encourage the involvement of subject matter editors in the merger. You know the subject best and will likely have suggestions on how to make things even better. Most of the editors who were involved with {{tl|Aircraft specs}} have already commented here, but I believe {{u|ZLEA}} could use a ping as well. --Trialpears (talk) 03:47, 27 January 2023 (UTC)
• Merge per nom. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:11, 27 January 2023 (UTC)
• Neutral for now - I don't agree with the proposer's statement that the aviation infobox system "is not an infobox but a series of tables masquerading as an infobox." Per MOS:INFOBOX, "An infobox is a panel ... that summarizes key features of the page's subject." Although unusual, the aviation infobox system performs this task very well. While it would be nice to have a more traditional infobox, the current system is not broken. As Ahunt pointed out, a revamped infobox with broken syntax would affect thousands of articles, which may or may not be easily fixed. I don't know what the issues were which led to the use of the current system, so if anyone could explain it or point me to a relevant discussion, that would be great. Overall, I see some small benefits to having a more traditional infobox, but I don't know if they out way the risks. - ZLEA _T\^C 16:33, 27 January 2023 (UTC)
• support merge, or at the very least, use "child infoboxes" to place the sections inside of a parent infobox. the requirement to wrap the entire thing in {| and