Content deleted Content added
m Archiving 1 discussion(s) from Template talk:WPBannerMeta) (bot |
m Archiving 1 discussion(s) from Template talk:WPBannerMeta) (bot |
||
Line 169:
:::You'd need to be careful how you did that, so that {{para|category|no}} would still be honoured. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] 🌹 ([[User talk:Redrose64|talk]]) 23:39, 9 December 2017 (UTC)
::::True. <code><nowiki><includeonly>{{#ifeq:{{lc:{{{category|}}}}}|no||[[Category:Disambig-Class Disambiguation articles]]}}</includeonly></nowiki></code> -- [[User:WOSlinker|WOSlinker]] ([[User talk:WOSlinker|talk]]) 13:28, 10 December 2017 (UTC)
== Overhaul: moving to Lua & JSON ==
I'm planning to rewrite this template's functionality as a Lua module. As part of that, the plan will be to incorporate some design tweaks (as suggested earlier/above by Headbomb) and move class definitions and class masks to a JSON-file model. I've already prototyped a JSON file covering the "standard" set of classes over at [[Template:Class/definition.json]], and there's Lua covering the functionality of {{tl|class}} and related over at [[Module:Class]]. I never pushed those live because they are bad at supporting custom classes; this upgrade will get us around that problem. Individual WikiProjects will be able to define their own JSON files to extend or override the default set.
Besides Lua generally producing faster, cleaner, and more maintainable code, the upgrade to use JSON files in place of class masks has a very specific advantage: it'll be very easy for other tools to "discover" custom classes defined by individual projects. For example, I maintain the [[Wikipedia:Metadata gadget|metadata gadget]] that brings assessments from the talk page to the title and tagline of the article namespace. That gadget currently must hardcode every custom class used by every WikiProject in order to support it, and that's not practical. By moving to JSON, both wiki-side Lua scripts and external (whether client-side gadgets in JavaScript or third-party code like bots) can access the same definitions without the need for one central file containing ''every'' custom definition used on the wiki. This will also make practical some future tools I'd like to develop, specifically focusing on exposing data about article quality over time and [[mw:ORES|ORES]].
I'm only human, so I'm probably missing some details here and there. Specifically, I'd appreciate input into the schema used for the JSON: for example, am I missing details that should be supplied in class definitions? More broadly, are there issues that this change would cause in places? I'd like to preempt problems as much as possible. <span style="white-space:nowrap;">{{[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]] |[[User talk:Nihiltres|talk]] |[[Special:Contributions/Nihiltres|edits]]}}</span> 23:54, 28 August 2017 (UTC)
:'''Highest support''' from me. This is a long term project, which will need a lot of testing and collaboration with other project/bots, but the goals are excellent and desirable. <span style="font-variant:small-caps; whitespace:nowrap;">[[User:Headbomb|Headbomb]] {[[User talk:Headbomb|t]] · [[Special:Contributions/Headbomb|c]] · [[WP:PHYS|p]] · [[WP:WBOOKS|b]]}</span> 00:29, 29 August 2017 (UTC)
: Would the format used by the parameters in {{tl|ReleaseVersionParameters}} be a good starting point for the schema? [[User:Titoxd|Tito<span style="color:#008000;">xd</span>]]<sup>([[User talk:Titoxd|?!?]])</sup> 00:45, 29 August 2017 (UTC)
::Indeed, ReleaseVersionParameters already had this goal in mind: the WP 1.0 bot does not hard code any custom quality or importance classes, but is able to parse them directly from the info in this "template". Really, it is not a template, just a way to format information in a way that can be parsed by a bot and hidden on the wiki. The main theoretical issues is if different projects have different custom classes on the same article, in which case there may be no easy way to tell the single "authoritative" rating for the article. It is necessary to have information on the relative position of each custom class with respect to the standard classes, which the template achieves with a numerical parameter. — Carl <small>([[User:CBM|CBM]] · [[User talk:CBM|talk]])</small> 01:24, 29 August 2017 (UTC)
:::My thought on "multiple custom classes" was that if there's more than one WikiProject involved in an article, the "authoritative", "standard" rating should be picked strictly from the standard set. We'd accomplish that not with numerical ratings—those are best for ''ranking'' qualities, rather than picking from them—but with a "maps to" property. For example, a WikiProject that implemented a "B+" rating could give it a property mapping that rating to the ordinary B-class rating for standardization purposes. If the mapping property wasn't provided, then by default we could map to the quality rating with the nearest lower numeric quality rating … which might mean having to be tricky about list-type ratings, but that's manageable. <span style="white-space:nowrap;">{{[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]] |[[User talk:Nihiltres|talk]] |[[Special:Contributions/Nihiltres|edits]]}}</span> 14:04, 29 August 2017 (UTC)
::That's great; I wasn't aware of that. Where bits overlap, it'd definitely be worth using the same patterns or values. For example, I've been thinking that a numerical value should be added to the class definition schema so that tools can insert custom classes into an overall order, and so that the "overall rating" of the page can be selected sanely—we can use the same scale as ReleaseVersionParameters. As mentioned, I started [[Template:Class/definition.json]] as the prototype schema; my current thinking is that it might make sense to expand the schema to use two inner objects ("quality" and "importance") or even three ("quality", "importance", and "WikiProject definition") so that we can put everything in the same place. <span style="white-space:nowrap;">{{[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]] |[[User talk:Nihiltres|talk]] |[[Special:Contributions/Nihiltres|edits]]}}</span> 14:04, 29 August 2017 (UTC)
*'''Oppose''' Moving to Lua will make my long-term project (adding documentation to all WikiProject banners, ensuring that existing docs are accurate and up to date) much more difficult. It's OK when a banner uses one of the standard parameters in a standard way, but several use weird fiddles, and for these I need to trace through the code to see exactly what happens when a given permutation of parameters is in use. Lua code is untracable. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] 🌹 ([[User talk:Redrose64|talk]]) 20:10, 29 August 2017 (UTC)
*:Could you be more specific with the problem, or give examples, please? I'd like to think that this project will help us smooth out "weird fiddles" somewhat, and I'm willing to write a variety of debug/testing tools into the code if that's something that you need. <span style="white-space:nowrap;">{{[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]] |[[User talk:Nihiltres|talk]] |[[Special:Contributions/Nihiltres|edits]]}}</span> 03:41, 30 August 2017 (UTC)
*::Couldn't a Lua version possibly auto-generate the documentation page as well? -- [[User:WOSlinker|WOSlinker]] ([[User talk:WOSlinker|talk]]) 07:57, 30 August 2017 (UTC)
*:::It may be possible to autogenerate some documentation in Lua, I don't know. Don't expect me to do it: Lua is a total enigma to me (when templates get converted to Lua, this is against the spirit of "the free encyclopedia that anyone can edit"). I have been documenting WikiProject banners since April 2010 and have developed a set of templates (see for example {{tlx|WPBannerDoc}}) that cope with ''most'' cases of standard parameters used in standard ways; examples include
*:::{{WPBannerDoc|small}}
*:::{{WPBannerDoc|category}}
*:::and some cases of standard parameters used in non-standard ways, also some cases of non-standard parameters. My task is not complete: for example, I have not yet fully worked out the code for {{para|A-Class}} used by some banners (e.g. {{tlx|WikiProject Cricket}} used it {{diff|Template:WikiProject Cricket|prev|729920935|until July 2016}}). --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] 🌹 ([[User talk:Redrose64|talk]]) 09:43, 30 August 2017 (UTC)
:::::I don't really see why LUA code in the background would prevent any of this working as is, or with small modifications. Not an expert on LUA, but to my understanding how you create specific instance of a banner like {{tl|WP Physics}} should very much look the same as they do now, with a bit of streamlining for the class/importance code. <span style="font-variant:small-caps; whitespace:nowrap;">[[User:Headbomb|Headbomb]] {[[User talk:Headbomb|t]] · [[Special:Contributions/Headbomb|c]] · [[WP:PHYS|p]] · [[WP:WBOOKS|b]]}</span> 12:21, 30 August 2017 (UTC)
:::::{{re|Redrose64}} There are (at least) two different ways we could roll this Lua/JSON update out:
:::::#Include a superset of existing functionality, move the new code into place in a single edit, then migrate deprecated functionality ("weird fiddles") to new functionality (i.e. the WikiProject-specific JSON file). Remove deprecated functionality as it's eliminated in the wild.
:::::#Write a new, cleaner template that significantly cleans things up but has a few breaking changes, then migrate project banners individually. Strictly speaking, we can write the JSON files that allow external-tool support for projects before migrating the project banners—just then we need to update things in two places any time a project wants to change its assessment system at all, with the risk that the two places become out of sync. This does have the advantage that it can be done even if the project members are cranky and don't want their project banner updated for whatever reason.
:::::Either way, a focus will be on straightforward, single-document configuration for WikiProject assessment systems, and getting rid of complex multi-template systems (like A-class review hooks) in favour of integrated code that produces stuff that's more standard across WikiProjects. Either way, we'll have dozens of edge cases to resolve, and people that resist change for no good reason.
:::::I understand the concern of Lua being opaque to you, but either way—multilevel-transclusion conditional wikitext or Lua—we've got complexity that's excluding ''someone''. We should work on making it so that ''most people'' don't have to deal with the complicated stuff, of course, and I think that this project is in line with that through its design goal of moving "adding support for custom processes" (like A-class reviews) away from weird systems and so on into "just specify some extra properties for the class definition".
:::::I think that our goals synergize well: we both want these systems to be easy to use and well-documented. My approach is just more dramatic, mostly by pushing things from "implement stuff yourself in wikitext" to "use the standard systems the banner module offers". My ''personal'' preference would be that we just force every WikiProject to use only a single standard set of classes and processes—that would give us site-wide consistency at a stroke—but I know that that's not politically feasible. As an alternative, I'm trying to make a system that offers support for custom classes and processes but ''makes them machine-readable'' so that we can deal with them (and yes, presumably ''document'' them) mostly automatically. <span style="white-space:nowrap;">{{[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]] |[[User talk:Nihiltres|talk]] |[[Special:Contributions/Nihiltres|edits]]}}</span> 17:32, 30 August 2017 (UTC)
::::::OK, here's an example. I've just improved [[Template:WikiProject Libraries/doc]]; whilst doing so, I found an unusual line in [[Template:WikiProject Libraries]]: <source lang=moin>|INFOBOX = yes</source> Wondering what the effect of that might be, I looked in the source of [[Template:WPBannerMeta]] for the sequence <code><nowiki>{{{INFOBOX</nowiki></code> and not finding it, I knew straightaway that the parameter was unrecognised, and I could safely ignore it. If [[Template:WPBannerMeta]] had been converted to a module, there would have been ''no way'' for me to find out whether that parameter is recognised or not, regardless of the difficulty in determining (if recognised) exactly what it does. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] 🌹 ([[User talk:Redrose64|talk]]) 08:47, 3 September 2017 (UTC)
:::::::If that's a desired feature, we could easily implement a parameter check like several templates do, and put out an error message when previewing the results. <span style="font-variant:small-caps; whitespace:nowrap;">[[User:Headbomb|Headbomb]] {[[User talk:Headbomb|t]] · [[Special:Contributions/Headbomb|c]] · [[WP:PHYS|p]] · [[WP:WBOOKS|b]]}</span> 12:20, 3 September 2017 (UTC)
::::::::Parameter checks which display error messages on preview - such as the one that I {{diff|Template:Infobox London station|prev|796859992|recently added}} to {{tlx|Infobox London station}} - are fine if the person adding that check knows what the valid parameters actually are. Once a template has become a module, you no longer know this. You are then dependent upon the module writer to keep the valid parameter list up to date, something which we cannot guarantee will be done, just as we cannot guarantee that those who amend templates will also amend the documentation. Any computer programmer will tell you that fully-documented functions are an ideal that is never achieved. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] 🌹 ([[User talk:Redrose64|talk]]) 12:48, 3 September 2017 (UTC)
:{{undent}} [[Module:Citation/CS1/Whitelist]] is updated each time a parameter is added or removed. You can also inspect Lua code in the same way as you inspected the template code for banner meta--it only seems opaque to you because you are unfamiliar with the language, not because it is impossible to do so. To any programmer, or anyone not versed in arcane template syntax programming language (and it is arcane, for a number of reasons), your use case is just as opaque. If you don't want to learn Lua, that's your prerogative. But right now, I personally find the current template completely opaque, and would much prefer a Lua representation. --[[User:Izno|Izno]] ([[User talk:Izno|talk]]) 14:09, 3 September 2017 (UTC)
::Agreed. I've started in on the work of converting the module, but almost all of my work so far has been ''assembling personal notes'' on how the template works to make sure I match functionality reasonably well (for example, I need to look more into how the hook system is used in practice). The wikitext-vs.-Lua concerns are not a sufficient counterargument to my plan. That said, I do appreciate Redrose64's concern of documentation quality, and we can keep it in mind moving forward. <span style="white-space:nowrap;">{{[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]] |[[User talk:Nihiltres|talk]] |[[Special:Contributions/Nihiltres|edits]]}}</span> 20:43, 7 September 2017 (UTC)
* The vast majority of WikiProjects use the simple/base banner, right? So I'd be less concerned about fitting the edge cases (let them continue to use the old banner innards, if necessary, if those projects even still actively use those extra features) than making the majority more efficient <span style="background:#F0F0FF; padding:3px 9px 4px">[[User talk:Czar|<span style='font:bold small-caps 1.2em Avenir;color:#B048B5'>czar</span>]]</span> 05:58, 10 September 2017 (UTC)
**<p>Handling the edge cases is one of the ''goals'' of this change, though. I'm already maintaining a gadget that needs to be able to handle custom classes—that was a big inspiration for this—and right now it has to have extra styles, strings, etc. hardcoded into the gadget to support custom classes, which is untenable. I'm ''planning'' to make some tools that help surface progression of quality metrics over time and highlight [[mw:ORES|ORES]] data for comparison, and for those tools it'll also be highly desirable to ''at minimum'' be able to automatically normalize custom classes to values from the standard set—let alone the portability and maintenance benefits of not hard-coding quality/importance classes in general. Handling edge cases well is one of the key benefits here. We can offer partial support by creating project configuration files for projects before they're properly updated, but that trick increases maintenance costs because it requires that any updates be mirrored in two places (the actual project banner, and the configuration file).</p><p>The fact that most WikiProjects use "simple" options does offer us an easy migration path, though: once the code's in a usable state we can start migrating "simple" banners and whittle the problem down to the tricky projects. <span style="white-space:nowrap;">{{[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]] |[[User talk:Nihiltres|talk]] |[[Special:Contributions/Nihiltres|edits]]}}</span> 19:55, 12 September 2017 (UTC)</p>
**: Sounds good. Just wanted to note that it's possible that some edge-case projects are no longer even active and therefore might not care if their edges are preserved. Perhaps someone can generate a list of edge cases and the rest of us can help by investigating <span style="background:#F0F0FF; padding:3px 9px 4px">[[User talk:Czar|<span style='font:bold small-caps 1.2em Avenir;color:#B048B5'>czar</span>]]</span> 20:34, 12 September 2017 (UTC)
**::Right, good call! I figure that we can proactively update most projects assuming there are no breaking changes. Few projects should have breaking changes; the nature of Lua means that it should be easy to cover most of the custom stuff with native functionality. Most of the edge cases should be easy to detect: they'll be using a class mask and/or the hook system, so they'll have non-empty values defined in relevant parameters. Many of those will be simple cases like "supporting extra parameters" that Lua can handle with negligible effort; a few might be more complicated. First things first, though: I've got to rewrite most of the core functionality. I'm planning to deprecate the hook system entirely: people who want that level of flexibility can instead just <code>require()</code> the main Lua module and reuse its functions in their own module. <span style="white-space:nowrap;">{{[[User:Nihiltres|<span style="color:#233D7A;">Nihiltres</span>]] |[[User talk:Nihiltres|talk]] |[[Special:Contributions/Nihiltres|edits]]}}</span> 21:31, 12 September 2017 (UTC)
*'''Support'''. WikiProject banners are a contentious area for many historical reasons, but I'm committed to moving the technology forward in a way which doesn't step on anyone's toes too much. {{ping|Nihiltres}} Feel free to reach out if you'd like to collaborate. {{ping|Redrose64}} Your documentation goals are extremely important, and we should make sure they are supported throughout this process as much as possible. [[User:TheDragonFire|TheDragonFire]] ([[User talk:TheDragonFire|talk]]) 10:45, 11 February 2018 (UTC)
| |||