Template talk:Class

Bold

What's the best way to implement an option for non-bold text? Martin 14:02, 22 January 2009 (UTC)[reply]

File-Class

Can File-Class be given the same colour as Image-Class please, so that it is supported if used in the future. Martin 14:08, 22 January 2009 (UTC)[reply]

Probably best to mention that at MediaWiki talk:Common.css#WP1.0 quality assessment colours, so that it can be added to the css file. -- WOSlinker (talk) 19:39, 22 January 2009 (UTC)[reply]

Colours and icons

There appear to be a few colours missing in the template (Current, Merge & Needed). Also, is it wise to have an image for all classes? It seems rather gratuitous and redundant in most cases. PC78 (talk) 13:16, 15 March 2009 (UTC)[reply]

The obscure ones are not included in MediaWiki:Common.css. I'm not sure whether there would be support for including them or not. So they have to be done manually for now. (For some reason which I can't work out, Future isn't included either but that one works ...) Yes, every class has an image, but they are only displayed if specifically needed (image=yes). — Martin (MSGJ · talk) 15:34, 15 March 2009 (UTC)[reply]

Sure, but it's all or nothing as opposed to just having images for FA/FL, A and GA as we currently do with the individual templates. PC78 (talk) 15:42, 15 March 2009 (UTC)[reply]

I don't follow. Each one is selectable as, for example, in my new version of cat class at Template:Cat class/sandbox. — Martin (MSGJ · talk) 16:04, 15 March 2009 (UTC)[reply]

Ah yes, I see. My mistake. PC78 (talk) 17:51, 15 March 2009 (UTC)[reply]

Purpose?

Is the purpose of this template to eventually supercede all of the many individual class templates? Are there any plans for anything similar for the various importance types? PC78 (talk) 18:55, 18 March 2009 (UTC)[reply]

I think that would be the general idea. Although this one uses html tables and the others use wiki tables and I'm not sure if they can be compatible ... nothing has been done with importance yet as far as I know. — Martin (MSGJ · talk) 21:52, 18 March 2009 (UTC)[reply]

It may make things slightly easier if the Merge, Needed, Future & Current had their style declarations in MediaWiki:Common.css -- WOSlinker (talk) 23:18, 18 March 2009 (UTC)[reply]

I would be strongly against deprecating the individual class templates in favor of this one. The problem with this template is that it adds an unnecessary amount of parser function checks on every transclusion, which would make pages like Wikipedia:Version 1.0 Editorial Team/Tropical meteorology articles by quality render very slowly. I do think that this template is useful, but it is not necessary to replace instances of the existing templates with this one. Titoxd^{(?!? - cool stuff)} 21:23, 14 April 2009 (UTC)[reply]

Last edits...

You spelt redirect wrong! [1] (Feel free to use {{classcol}} as well...) PC78 (talk) 16:10, 5 April 2009 (UTC)[reply]

A couple of requests

If I may, can I request the following parameters which I think may be of value:

|colour= for manually selecting a colour; I know this can be done already using the |style= parameter, but that's a bit long-winded.
|link=no to dislay the text as plain text in situations where a link would be undesirable.

Thoughts? PC78 (talk) 15:49, 8 April 2009 (UTC)[reply]

Proliferation of different parameters for different aspects of an object's style is one of my pet hates on wiki. What situation do you think it would help in?

|link= might be a good idea, but can you think of a way to do it without duplicating a big chunk of code? Happy‑melon 16:02, 8 April 2009 (UTC)[reply]

For the former, I honestly can't say if there is any real demand for such a parameter, but it strikes me that colour is the only aspect of style that you'd really need to muck about with, and {{class|X|style=background: #000000;}} doesn't seem particuarly intuitive. Perhaps I'm just too fussy? :)

For the latter, my feeble attempts in the sandbox would make that a "no". PC78 (talk) 16:25, 8 April 2009 (UTC)[reply]

Hmmm, I was thinking that an option to delink the text would be most useful where a category didn't and/or wasn't likely to exist (Category:B+-Class articles, for example). Instead of a parameter, what about an #ifexist check, or would that be too much for too little gain? PC78 (talk) 15:48, 14 April 2009 (UTC)[reply]

I don't think an #ifexist check is a good idea for a couple of reasons:

It would be adding an expensive parser function to every call of this template
More often than not, a red link highlights the need to create a certain category

I've got a trick to delink without duplicating the code. See the examples in Template:Class/testcases. However it won't work with the bold=no option. — Martin (MSGJ · talk) 06:40, 15 April 2009 (UTC)[reply]

That is genius, MSGJ! Happy‑melon 10:04, 15 April 2009 (UTC)[reply]

Thanks, praise indeed. Is there any way to override the boldness of a link to the current page? — Martin (MSGJ · talk) 11:32, 15 April 2009 (UTC)[reply]

Either by piping a span if you don't want it linked, or by adding an anchor if you do: Template talk:Class & Template talk:Class. I've been using the latter in recent times on my own talk page to keep my signature linked there, but you'll need to find an anchor that works for all skins. Amalthea 21:09, 14 July 2009 (UTC)[reply]

A-Class

The default link to A-Class appears to be broken; see the documentation. PC78 (talk) 14:38, 10 April 2009 (UTC)[reply]

No, it was just the documentation that was broken. PC78 (talk) 14:52, 10 April 2009 (UTC)[reply]

Category name override

Currently, this template automatically builds the linked category's name from provided parameters. However, there are assessment categories which do not fit the naming scheme which it uses - for example, Category:WikiProject Anime and manga categories and Category:WikiProject Anime and manga templates (these are actually the only two I know offhand, but that's mostly because I don't venture into the assessment categories that often). Needless to say, the template currently doesn't support category names such as these, and as a result, they don't display on {{Cat class}}. I proposed a change to {{Cat class}} which would allow it to link to assessment categories with nonstandard names such as these, and was quite pleased with it until *gasp* someone actually tested my changes! (oh the horror!) Needless to say, the best suggestion for how to fix this seems to be an override parameter here for the category name. Thoughts? And just so we're clear, if I had my way, all categories named along the lines of "Template/Category/Image/Redirect/Etc.-class X articles" would immediately be renamed, because none of them *are* articles. =) 「ダイノガイ千？！」^{(Dinoguy1000)} 19:23, 16 April 2009 (UTC)[reply]

I'm in two minds about this. Firstly, I agree with you that the term Category-Class articles is ridiculous. I used to hate them as well, but now I got used to it! I believe that WikiProjects should be able to choose the names of their categories and that the templates should be able to support that. However the XX-Class YYY articles structure has become almost ubiquitous, and I think it is possible that your project would be the only one using this parameter, in which case it would adding a significant level of complexity to the template for little gain. Let's see what others think. — Martin (MSGJ · talk) 21:00, 16 April 2009 (UTC)[reply]

That is certainly a possibility (though admittedly I haven't gone looking for other nonstandardly-named categories), and is part of the reason I didn't just make an editprot request. =) 「ダイノガイ千？！」^{(Dinoguy1000)} 21:11, 16 April 2009 (UTC)[reply]

I'm also not thrilled about using the likes of "Category-Class articles" (I voiced my displeasure at Template talk:WPBannerMeta a while back), but unfortunately it's increasingly becoming the standard as more and more project banners are converted to the meta template. Clearly having nothing better to do, I've skimmed through the Category-Class and Template-Class categories to see what's what. Most use the "Category-Class articles" format, and most of the ones that don't use "Category-Class pages" (which is also supported by {{Class}}). Here are some of the ones I found that use alternate names:

which may give you some indication as to which projects would potentially make use of this feature. PC78 (talk) 21:33, 16 April 2009 (UTC)[reply]

In my mind, the actual name of the category is largely irrelevant. Category:Template-Class Foo articles is no more ridiculous than Category:Disambig-Class Foo articles or even Category:List-Class Foo articles, both of which are largely accepted. Then the question of "why FA-Class but Top-importance?" The semantics of the whole structure are tied up in knots, but who cares? They're not reader-facing. All that matters, to my mind, is that they follow a simple schema that is as machine-readable as possible, and that means consistency. So we can ordain "Category:{{{class}}}-Class {{{PROJECT}}} articles and even if it doesn't make a lot of sense semantically, we can still find the categories and put articles into them with as much ease as possible. Because that's what they're there for. Happy‑melon 21:49, 16 April 2009 (UTC)[reply]

Or, I can be a total dick and send all subcats of Category:Template-Class articles (but not that one itself, since I can't think of a good way to rename it) to CFD for renaming to [[:Category:Wikiproject {{{PROJECT}}} templates]] (and/or send the equivalent cats for categories, images, etc.)... Or would that be disruptive? =) *is immediately buried under an avalanche of beans* Although, maybe one big discussion on the issue wouldn't be a bad idea... Hmm... 「ダイノガイ千？！」^{(Dinoguy1000)} 21:56, 16 April 2009 (UTC)[reply]

I'd oppose that not because it's not an eminently sensible idea, but because it would make it even harder to construct a unified schema. How would you code such a standard category name into a template like this one? The most important thing as far as I'm concerned is that it must be possible (ideally) to write the whole schema with just one example. That's why I'm increasingly annoyed with myself for not clamping down on "Unassessed" vs "Unassessed-Class" way back when when we could actually have done something about it. Because now the schema is "Category:{{{class}}}-Class {{{PROJECT}}} articles EXCEPT Category:Unassessed {{{PROJECT}}} articles. Which is a bit of a pain, although less so because Unassessed needs to be treated differently in things like WPBM anyway (different text, etc). I wouldn't particularly care if the schema was Category:{{{class}}}-Humbug {{{PROJECT}}} snorkels as long as all the categories were consistent. Happy‑melon 09:11, 17 April 2009 (UTC)[reply]

Personally, I'd prefer to use the parallel standards of [[:Category:{{{class}}}-Class {{{WikiProject}}} articles]] for the normal (unassessed through FL) assessment classes, and [[:Category:WikiProject {{{WikiProject}}} {{{class}}}s]] for the non-standard ones (I fail to see why assessments such as "current" and "merge" are any improvement over having separate parameters in the banner, so I would cut those altogether). That being said, I'm not the one writing/updating all the tools, and it's probably a good thing that I don't have my way about it. =) 「ダイノガイ千？！」^{(Dinoguy1000)} 19:22, 17 April 2009 (UTC)[reply]

Ahem, the point I was trying to make above (if indeed I had one) is that there probably aren't enough projects to make such a feature worth pursuing, not least beacause Martin has deleted half of the categories I did manage to find. :) If it's a big enough deal for individual projects, they're probably better off writing their own customised version of {{Cat class}} instead. PC78 (talk) 15:10, 17 April 2009 (UTC)[reply]

BTW, I just discovered the potential source of overlap that is Category:WikiProject templates versus Category:Template-Class articles. 「ダイノガイ千？！」^{(Dinoguy1000)} 19:25, 17 April 2009 (UTC)[reply]

Yes, I'd agree with that. Just make a customised version of cat class. WPFILM could probably do with a customised version inside {{WPFILMS Assessment level category}} by the way. -- WOSlinker (talk) 18:56, 17 April 2009 (UTC)[reply]

Yes, I've just noticed that NA-Class is no longer diplayed for the film articles. What a pain! I specifically asked for Future-Class to be added to {{Cat class}} so that I wouldn't have to create a customised version. PC78 (talk) 20:29, 17 April 2009 (UTC)[reply]

Hmm... considering I was, at some point, considering making a version of Wikipedia:WikiProject Japan/Assessment/Category header for WP:ANIME, that functionality would be easy enough to insert. I can wait until such time as I start on it to have links to our (nonstandard) categories, I suppose. 「ダイノガイ千？！」^{(Dinoguy1000)} 19:22, 17 April 2009 (UTC)[reply]

Alternatively you could create Category:Category-Class anime and manga articles as a category redirect to Category:WikiProject Anime and manga categories. PC78 (talk) 20:29, 17 April 2009 (UTC)[reply]

But... That would be too easy! It would nullify the whole point of this discussion! How could you be so mean? =D 「ダイノガイ千？！」^{(Dinoguy1000)} 20:53, 17 April 2009 (UTC)[reply]

Revisited

Any further thoughts on this? I have added a |fullcategory= parameter in the sandbox which would allow "non-standard" category names in this template. Unless I've missed something, it seems like a fairly simple and straightforward addition.

As there does not appear to be a concensus for converting {{WikiProject Anime and manga}} to use the meta, I had at least hoped to replace usage of the old {{-Class td}} templates with {{Class}}, but that isn't possible without making changes here. So far as I can tell, that is the last banner using those -Class td templates, so it would be nice if we could orphan and delete them. PC78 (talk) 21:13, 12 July 2009 (UTC)[reply]

Looks OK to me. I've changed {{WikiProject Anime and manga}} to use the {{impor}} template and {{Class}} as it currently stands for some of the classes. -- WOSlinker (talk) 21:57, 14 July 2009 (UTC)[reply]

I would oppose, as the preferred solution for me would be for WPAnime to start using, or at least maintain category redirects from, the categories that follow the schema used by 95% of the rest of the projects. That is not a particularly popular position, but it does seem to me to be the most defensible. Zero one infinity principle applies. Happy‑melon 22:41, 14 July 2009 (UTC)[reply]

Zero One Infinity? I'm not familiar with the principle, but if I understand it correctly then what I propose is to allow for an infinite possibility of category names, not to impose an arbitrary restriction on them. ;) In more simple terms, this change would afford the template a greater flexibility, and I think that's a good thing. I'm all for maintaining category redirects, but in practise this can be tricky: in the discussion above I suggested that Dinoguy create Category:Category-Class anime and manga articles and IIRC he did, but it has since been deleted (see also this CfD discussion). In any case, category redirects are less than ideal for the purposes of project banners and {{cat class}}. PC78 (talk) 23:00, 14 July 2009 (UTC)[reply]

Yes, and you are indeed proposing we allow an unbounded set of category names. I don't think that that is a good idea, for the reasons I've set out earlier: the presence of a unified schema for describing these categories is hugely useful for 'horizontal' navigation: both by bots and by humans. Is there a reason other than inertia that WPAnime doesn't want to use the standard category names? Happy‑melon 10:51, 15 July 2009 (UTC)[reply]

Is it really only Anime which uses the non-standard names now? — Martin (MSGJ · talk) 11:04, 15 July 2009 (UTC)[reply]

{{Film}} uses a lot of non-standard names as well. -- WOSlinker (talk) 12:57, 15 July 2009 (UTC)[reply]

Ah, another "obstinate" project ;) — Martin (MSGJ · talk) 13:00, 15 July 2009 (UTC)[reply]

And from a look at the API category listings, those are the only two. There's Category:Hawaii categories, which isn't populated from the standard assessment scale, and there's Category:Category-Class African protected areas pages, but that entire scale doesn't seem to be populated. Anime and Films are the last ones... Happy‑melon 14:49, 15 July 2009 (UTC)[reply]

Ahem! WP:MILHIST and WP:BIOGRAPHY still use "non-standard" categories. I can probably name others if you want... PC78 (talk) 16:21, 15 July 2009 (UTC)[reply]

They're not in Category:Template-Class articles, they don't count... :P Happy‑melon 21:53, 15 July 2009 (UTC)[reply]

I would agree that it would not be worth making the template more complicated for the sake of a very few number of projects. However the change is so simple that I can't see any harm in making this change actually. Deprecating the old class templates would be a good move, I think. — Martin (MSGJ · talk) 08:38, 15 July 2009 (UTC)[reply]

I think the benefit outweighs the perceived drawbacks. Allowing for an unbounded set of category names is not the same as actually having them. Aren't 98% of project banners now converted to WPBM? And does WPBM not enforce the de facto standard naming scheme? We wouldn't be opening the floodgates to projects wanting to use a variety of different category names because they essentially can't, so if that's the primary concern then I don't think it's valid. What we would be doing is extending the full functionality of this template (and any dependent templates) to all projects, and no longer disadvantaging a minority of projects that do not wish to conform to another's standard. That's a tangible benefit IMO, and I don't see the harm. PC78 (talk) 16:21, 15 July 2009 (UTC)[reply]

I'm inclined to agree. There are certainly good reasons to encourage editors to use a standard naming scheme but, at the end of the day, if a WikiProject decides that it wants to use a non-standard scheme, then that is their right. I am a little uneasy about using a template to try to stop editors doing what they want to do! It should be the other way around. — Martin (MSGJ · talk) 06:39, 16 July 2009 (UTC)[reply]

I agree that it's not appropriate to use the protected or high-visibility nature of this template to 'prevent' editors or projects from doing something they want to do. Although that's not quite what's happening here because they can still achieve the desired functionality through the {{-Class td}} templates; we're just trying to tidy up behind the scenes. Martin, what would "using an editor to try to stop templates doing what they want to do" entail, then?? :D Happy‑melon 10:52, 16 July 2009 (UTC)[reply]

I could give a cheeky response to this. — Martin (MSGJ · talk) 11:30, 17 July 2009 (UTC)[reply]

*insert whining about hitting Wikipedia:Template limits on WP:1.0/I pages here* Titoxd^{(?!? - cool stuff)} 20:11, 15 July 2009 (UTC)[reply]

After the above discussion (and a handful of others), I was actually seriously considering working on an RfC regarding the assessment/importance cat names. Someone (H-M?) commented on my joke suggestion of a mass CfD nom that people would oppose on the basis of it being makework, but that only spurred me to really think about it. =D Amongst us are several admins and at least one bot op, so we could handle all the work resulting from an RfC ourselves, and if none of you are against the idea, I can start working on a draft RfC. Thoughts? Obviously, this isn't directly related to changing {{class}} to support nonstandard cat names, but it *is* a far more "permanent" solution to the whole entire issue... 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 20:45, 15 July 2009 (UTC)[reply]

Please, you'll just make me depressed when the horde of "unnecessary work" drive-bys turn up to oppose in complete disregard for the fact that the very existence of the RfC demonstrates that someone cares about it enough to do the work, all they're looking for is for no one to turn up and say "you shouldn't do it because of this genuine reason". That people will oppose on the basis of "makework" despite the fact that we'd be making work only for ourselves is a certainty, not a guess; take a look at Wikipedia:WikiProject Council/Banner standardisation for a similar proposal, and the reaction to it. If you can come up with a schema that is both uniform and logical, I will support it to the hilt, but I fear it might be quite a demoralising experience. Happy‑melon 21:51, 15 July 2009 (UTC)[reply]

My thought has always been an {{mbox}} notice at the very top of the RfC explicitly stating that any such !votes would be disregarded, since we'd already have any necessary work covered. I figure that this way, if someone complains that such comments *are* ignored, we can just come back with a "told you so" and a pointer to the notice. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 22:17, 15 July 2009 (UTC)[reply]

What naming scheme would you propose Dino? Can you think of one which is "uniform"? — Martin (MSGJ · talk) 06:37, 16 July 2009 (UTC)[reply]

I've got some random, disparate thoughts bouncing around in my head, but I have yet to start writing them down and giving the entire thing some serious consideration. More than likely, though, it won't stray too far from the current practices, but be more eliminating inconsistencies (e.g. capitalization in C-Class versus Mid-importance) and making the whole thing make more sense (I still say categories, templates and the like aren't articles, and it's nonsensical to categorize them as such). I'll try to get some thoughts written down after a bit, at which point I'll drop a link here to get some first impressions. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 19:07, 16 July 2009 (UTC)[reply]

I've got a draft (well, an organized group of notes more than anything) started at User:Dinoguy1000/notepad#Assessment/importance cat RfC. Thoughts? 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 21:35, 16 July 2009 (UTC)[reply]

It would be easier to organise on a separate page with a dedicated talk. You seem to have identified the key issues. Happy‑melon 11:17, 17 July 2009 (UTC)[reply]

Ditto that (but without the first two paragraphs I suggest). I'd like to start commenting on those ideas, but I don't know where. — Martin (MSGJ · talk) 11:27, 17 July 2009 (UTC)[reply]

Yes, yes, a separate page... I was merely using my notepad as such, to collect my thoughts. I'll move it to a separate page in my userspace in a moment. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 18:45, 17 July 2009 (UTC)[reply]

Okay, have a look at User:Dinoguy1000/Assessment category RfC - discussion to the talk page, please. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 19:07, 17 July 2009 (UTC)[reply]

I was wondering why no-one had responded since my last comment, and it's because the damn page had somehow removed itself from my watchlist. Weird. I'll post a proper comment after I read through what's been said. PC78 (talk) 15:39, 17 July 2009 (UTC)[reply]

OK then. While I would be more than happy to discuss a standardised category scheme, I think it's really a side issue to what I was initially proposing. HM is correct that a change here is more of a convenience than a necessity with regards to {{WikiProject Anime and manga}}; the existing {{-Class td}} templates work just fine for that purpose, and can always be orphaned by other means (hard-coding their functionality into the banner, for example). But it would still be a benefit to templates such as {{cat class}} and {{grading scheme}}, particuarly {{cat class}} which no longer recognises certain categories since it was recoded to use {{class}}. I have to disagree with my own comment elsewhere on this page that projects could always create their own versions of these templates if need be (and now feel like a bit of a noob for saying it). Expecting projects to create their own forks of existing templates is simply unreasonable when the path of least resistance is to make a trivial change here. Even if it would be a seldom-used feature of this template, even if it was to ultimately become obsolete, I still think it's worth doing. PC78 (talk) 01:25, 18 July 2009 (UTC)[reply]

I'm planning to implement this soon unless there are further comments. — Martin (MSGJ · talk) 23:52, 22 July 2009 (UTC)[reply]

*nudge* Any progress with this, Martin? PC78 (talk) 19:18, 5 August 2009 (UTC)[reply]

{{editprotected}} Please update with the revised code at {{Class/sandbox}}. Cheers! PC78 (talk) 18:41, 14 August 2009 (UTC)[reply]

Done Could you update the documentation? Let me know if there are any problems. Plastikspork (talk) 00:02, 15 August 2009 (UTC)[reply]

Template:Class and non-WPBannerMeta banners

Would it be possible to get non-WPBannerMeta banners to use this template, or would they need to be converted to HTML first? PC78 (talk) 23:53, 29 October 2009 (UTC)[reply]

Bump. Would it be possible or not? PC78 (talk) 16:50, 8 November 2009 (UTC)[reply]

white-space:nowrap;

Just wondered why this is needed, as all the class names are just one word anyway. I just had to override it, to stop a sortable table from taking up too much room (example - the clicky things were all on the same line as the classes and the table was far too wide). — Martin (MSGJ · talk) 09:51, 8 November 2009 (UTC)[reply]

IIRC, if a WPBM banner doesn't have a left image (or has a really small one), then the cell gets squashed such that the image and text are broken onto separate lines. Happy‑melon 11:56, 8 November 2009 (UTC)[reply]

Ah, I had forgotten about the images. In that case we could put a nowrap span around the image and the text? It's not particularly important though. — Martin (MSGJ · talk) 12:13, 8 November 2009 (UTC)[reply]

topic parameter

How about adding support for a topic parameter which would act the same way as category except that "articles" is not required. I think we are moving in this direction. — Martin (MSGJ · talk) 12:19, 8 November 2009 (UTC)[reply]

Why not just use |fullcategory=? PC78 (talk) 16:51, 8 November 2009 (UTC)[reply]

Because that would be more to type in, not less! Compare

{{class|C|topic=Egypt}}
{{class|C|category=Egypt articles}}
{{class|C|fullcategory=C-Class Egypt articles}}

— Martin (MSGJ · talk) 17:21, 8 November 2009 (UTC)[reply]

I got an edit conflict on my previous comment, which is good because it was totally wrong, I misunderstood what you meant entirely. You mean that we (ultimately) replace {{{category}}} with {{{topic}}} articles?? I definitely support that; it's something I've wanted to do to |ASSESSMENT_CAT= in WPBM for ages. I'd even prefer to change the functionality of the |category= parameter here; I can think of clever ways (albeit ones that will have Domas chasing after us with a baseball bat) of using the string functions to make the transition without using an intermediary parameter. Happy‑melon 17:33, 8 November 2009 (UTC)[reply]

Yes, I also misunderstood what you meant. But I'm not so sure that we're "moving in this direction" with regard to category naming. I've never been happy using "articles" for categories that contain non-articles, and I know I'm not the only one; I seem to recall Dinoguy being interested in exploring possible alternatives. The change you propose would make category naming more rigid, and I'm not sure that's desirable in the long term. PC78 (talk) 19:01, 8 November 2009 (UTC)[reply]

Not really, if we change this template and WPBM to receive only the general topic, we're actually in a better position to change the category schema at a later stage if we want to; as the logic for what to stick around the part that is genuinely bespoke to each project will be centralised rather than spread over a thousand banners. Happy‑melon 20:11, 8 November 2009 (UTC)[reply]

You're right, PC78, I don't like "articles" for non-article categories at all, but HM raises a really good point in favor of it; because of this, I would support this change (speaking of generalization, just having been over that way, I'm curious as to whether there's any reason {{Film}} hasn't been converted to WPBM yet). 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 20:33, 9 November 2009 (UTC)[reply]

Same reason the Anime and Manga banner hasn't? ;) Fair enough I suppose, but won't this mean having to edit a thousand banners for no discernable short term benefit? If this is leading up to something then great, but otherwise I'm not sure I see the point. PC78 (talk) 21:59, 9 November 2009 (UTC)[reply]

This particular change will only require changes here, at WPBM, and wherever this template is used directly. The reason I haven't already pushed for a change at WPBM is because, as you say, there's little short-term benefit. Happy‑melon 23:45, 9 November 2009 (UTC)[reply]

Would it not require |ASSESSMENT_CAT= to be changed in individual banners? PC78 (talk) 02:21, 10 November 2009 (UTC)[reply]

Correct, this change would be necessary for any kind of change to the assessment naming scheme and would give us more flexibility not less. I'm not sure I can see the advantages of using the same parameter for this purpose though - it is almost as easy to change |category=physics articles to |topic=physics as it is to just remove "articles". And if it would save Domas from picking up his baseball bat, then that is probably better ... :) — Martin (MSGJ · talk) 17:57, 11 November 2009 (UTC)[reply]

Proposed code in /sandbox. — Martin (MSGJ · talk) 12:46, 19 November 2009 (UTC)[reply]

As I asked above, will this change not require |ASSESSMENT_CAT= to be updated in individual banners? I don't really oppose the change, but I am mildly concerned that it's going to create a lot of work for only a hypothetical benefit. PC78 (talk) 16:05, 19 November 2009 (UTC)[reply]

At this stage the category parameter is still supported and so no existing uses will be affected. It will just allow a more convenient and flexible syntax for any new uses of this template. Whether we will bother to take this approach with {{WPBM}} is debatable and a good topic for discussion over there. Personally I agree that it would have made more sense to do it that way to start with but, like you, will need convincing that the effort to achieve it is worthwhile. I said much the same when it was brought up at Template talk:WPBannerMeta/Archive 5#ASSESSMENT CAT. However if someone is willing to put the work in, then I would certainly support it. — Martin (MSGJ · talk) 17:40, 19 November 2009 (UTC)[reply]

Added — Martin (MSGJ · talk) 22:22, 23 November 2009 (UTC)[reply]

Use as column heading

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

See WP:VPT#Related: No sort arrows; I have determined that the problem described is a result of {{class}}, which generates a <td>...</td> element, being used as a column heading. I have sandboxed an amendment to allow <th>...</th> to be used instead, this is tested at Template:Class/testcases as working, so please copy Template:Class/sandbox over Template:Class. --Redrose64 (talk) 16:44, 12 October 2011 (UTC)[reply]

Can you not wait one more day to do this yourself? :P

Done — Martin (MSGJ · talk) 16:57, 12 October 2011 (UTC)[reply]

Thank you 1 days, 20 hours according to User:X!/RfX Report. --Redrose64 (talk) 17:09, 12 October 2011 (UTC)[reply]

You may then want to do the same to {{importance}} just for consistency. -- WOSlinker (talk) 17:49, 12 October 2011 (UTC)[reply]

Sure, that makes sense. — Martin (MSGJ · talk) 18:34, 12 October 2011 (UTC)[reply]

User-Class, Deferred-Class and AL-Class icons

User-Class and Deferred-Class should not display icons by default, but currently display a rather unhelpful question mark icon. I'm guessing that this is because these classes are undefined at {{Class/icon}}?

By the same token, AL-Class should display an icon as per A-Class, but does not. Is someone able to make the necessary changes? PC78 (talk) 19:05, 5 June 2016 (UTC)[reply]

I also proposed this at Template talk:Class/icon#Icon for non-existent class. If you know what the necessary change is I can do it. Regards — Martin (MSGJ · talk) 20:17, 5 June 2016 (UTC)[reply]

I'm a bit rusty, but I expect AL-Class can be fixed here by changing this line

   |fa|fl|fm|a|ga

to

   |fa|fl|fm|a|al|ga

I agree with your comment on the other page, I'll have a proper look later. PC78 (talk) 20:32, 5 June 2016 (UTC)[reply]

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

The above change for AL-Class is sandboxed at Template:Class/sandbox with testcases at Template:Grading scheme/doc/table/sandbox. PC78 (talk) 23:22, 6 June 2016 (UTC)[reply]

~~The code at Template:Class/icon/sandbox will stop an icon being displayed for those classes that don't have one, i.e. Current/Deferred/Future/Merge/Needed/User.~~ PC78 (talk) 23:41, 5 June 2016 (UTC)[reply]

This other part of the problem needs a bit more thought. PC78 (talk) 23:22, 6 June 2016 (UTC)[reply]

Done Synced sandbox to main. — xaosflux ^Talk 00:58, 7 June 2016 (UTC)[reply]

New icons

I've proposed some new icons over at Template talk:Class/icon#Proposed class icons. Cheers! PC78 (talk) 03:37, 2 July 2016 (UTC)[reply]

Idea: define classes in JSON

This is probably at least impractical and might be impossible or wildly inefficient, but I figure it's worth musing about publicly … what if we created a core definition of classes in JSON, and migrated {{class}} to use that via Lua?

In particular, this would have the significant advantage that it would be simultaneously usable in both templates and in Gadgets and external tools. Making class definitions central in that way would also have the advantage of allowing us to bundle data: we'd be able to put various labels, colours, and icons all in the same resource. For that matter, it'd be trivial from there to extend the class definitions with new properties, perhaps Wikidata mappings or something, or alternate class colours suitable for different situations, whatever. As a bonus, it'd let us separate content from code which is generally desirable.

This would be a little technically awkward, but it's definitely possible. MediaWiki supports JSON as a content model, and Scribunto allows us to transclude pages in Lua and import JSON as a Lua table. It's a bit awkward: we'd have a dedicated module to do the transcluding and JSON-decoding steps that could be loaded only once per page with mw.loadData(), through a module that'd construct the relevant table cells or whatever. I've done a basic proof-of-concept already, but given that {{Class}} has over six million translusions, the performance implications are non-trivial and I'd want a developer to confirm it's viable, plus confirmation here that other people think it's worthwhile to pursue.

Here's a 30-second mockup of a potential JSON object, with a single "fa" item that includes colour, icon, labels, and a target page for the quality class:

{
    "fa": {
        "category": "Category:FA-class articles",
        "colour": "#6699ff",
        "icon": "Featured_article_star.svg",
        "iconDefault": true,
        "labelAdjective": "featured",
        "labelFull": "featured article",
        "labelShort": "FA",
        "page": "Wikipedia:Featured articles"
    }
}

I'm a little biased, because this would solve a specific problem for me, which is that a Gadget I maintain, MediaWiki:Gadget-metadata.js (and .css) duplicates and tweaks (darker colours suitable for text) class content. Today it scrapes and munges the talk page for class values; I'm hoping to eventually update it to use the PageAssessments API and, well, this proposal or similar.

Thoughts? Is this workable, desirable, crazy? {{Nihiltres |talk |edits}} 22:57, 6 December 2016 (UTC)[reply]

Addendum: I've started a prototype definition at Template:Class/definition.json, and added quick values for each of the standard classes (FA, FL, FM, GA, A, B, C, Start, Stub, NA, and Unassessed). I also added "category" and "iconDefault" properties both there and in my example above. I expect the properties to need some work—these are basically placeholders, with a minimum of thought behind them—but this should be enough to get prototypes going. {{Nihiltres |talk |edits}} 18:52, 7 December 2016 (UTC)[reply]

The benefits seem abtract and vague, but I would not oppose if others see advantages. What would the downsides be, if any? — Martin (MSGJ · talk) 20:46, 7 December 2016 (UTC)[reply]

The one concrete downside is that this approach requires Lua, so we need to rewrite the template as an invocation of a Lua module. Some of that work appears to have been done already: Mr. Stradivarius wrote Module:Class, which from a quick skim seems like a decent starting point.

There's also a more abstract risk, which is performance. I want to be cautious about performance for templates with more than six million transclusions, and I'd like to double-check with a developer about the performance implications of the way that I load the data. I'm guessing it should be fine, but … six million transclusions.

Aside from that, it does work: see prototypes at Template:Class/definition.json for the JSON, ~~Module:Sandbox/Nihiltres/Import~~ Module:Class/importDefinitions for the import module, and finally Module:Sandbox/Nihiltres/Testing to quickly approximate an output; there's example output from that at User:Nihiltres/Sandbox#Lua testing. {{Nihiltres |talk |edits}} 22:23, 7 December 2016 (UTC)[reply]

As well as storing the data in JSON, it is also possible to store it as a Lua table and then convert it to JSON on the fly using mw.text.jsonEncode or a third-party module like Module:jf-JSON. That's the approach I have taken with Module:Sensitive IP addresses/API and the data at Module:Sensitive IP addresses/list. There is also MediaWiki:Gadget-libLua.js, which you can use to convert JSON outputted from Lua into a JavaScript object with minimal fuss. Performance-wise, I don't think the difference will be appreciable unless you are dealing with big data sets, which this isn't. You can always do some performance benchmarks if you are worried. One other thing which you should take into account is that there is a project to replace WikiProject banner templates with a MediaWiki extension. I don't know the details or what the extent of the plans are there, but I'll try and dig up the link when I have a moment. — Mr. Stradivarius ^{♪ talk ♪} 00:48, 8 December 2016 (UTC)[reply]

Hm, I can't find the link, but I know that it's something that Harej was doing with Wikipedia:WikiProject X. — Mr. Stradivarius ^{♪ talk ♪} 04:45, 8 December 2016 (UTC)[reply]

I think User:Mr. Stradivarius is referring to Wikipedia:WikiProject X/wikiproject.json, which is the configuration file used for User:Reports bot. My own thought is that in the long run, I would like to get assessment templates out of the talk page altogether, instead having it be a page property edited through a specialized interface. But that's a long term thing. If representing the classes in JSON makes maintenance easier in the interim, I say go for it. Personally I am a big fan of separating code from content; you have the abstract code that processes the structured data it's given, and then you have a separate file that contains the actual data. It results in code that is cleaner, more consistent, and easier to maintain. Harej (talk) 20:37, 8 December 2016 (UTC)[reply]

Great input, thanks Mr. Stradivarius & Harej. I'm inclined to leave JSON as the native format, rather than using a Lua→JSON setup; the use of action=scribunto-console doesn't feel right. JSON's portability also plays well with long-term hopes of moving assessment metadata out of talk page content. A quick test with Module:Timing suggests that the performance isn't too bad—the importing step is somewhat expensive, but as that'll only be done once per page, it shouldn't be an issue. I'll be moving things forward to work on a sandbox version—I've started by doing some work to try and eliminate the attr parameter, whose presence prevents using mw.html. {{Nihiltres |talk |edits}} 04:55, 12 December 2016 (UTC)[reply]

@Nihiltres: That sounds like a good plan, actually. If there is ever some kind of official MediaWiki tool to define classes, then the data is very likely to be in JSON, and having this data in JSON now would make it easier to migrate. While I'm thinking about it, let me also add some more background about Module:Class. I wrote the module to be an exact one-to-one replacement to Template:Class, and the code itself is finished, although it still needs test cases. The only reason I didn't write the test cases and deploy it was that I tested its performance against the original template, and it turned out to be slightly slower due to Scribunto's initialisation time. If you add test cases and edit it to incorporate recent changes to the template, it should be ready to use. — Mr. Stradivarius ^{♪ talk ♪} 06:01, 12 December 2016 (UTC)[reply]

Actually, sorry, I was thinking about Module:Class mask, not Module:Class. (And Module:Class mask does have test cases.) I don't remember whether I considered Module:Class as finished after I last edited it, but glancing over the code it does look like it is probably done. The test cases are often the hard part, though, so that might not be saying much. — Mr. Stradivarius ^{♪ talk ♪} 07:05, 12 December 2016 (UTC)[reply]

It looks like it's mostly done but … I stopped checking on realizing its makeCSStext() function is unused. That bit gives me the impression that it implements most of the functionality but stops short of matching the details—the level where test cases start being relevant. I'll take it one step at a time, starting with deprecating attr so that we don't have that headache over our heads. {{Nihiltres |talk |edits}} 16:28, 12 December 2016 (UTC)[reply]

Lua/JSON rewrite: an update

Checking back in with a progress update:

Wikipedia:Categories for discussion/Log/2016 December 20#Category:Unassessed-Class articles is still unresolved. A consensus to rename that category could simplify code a bit.
Template:Class/definition.json is more fleshed out, and I've documented its basic design at Template talk:Class/definition.json.
Module:Class is functionally complete.
I've got some testcases going at Template:Class/testcases to manually compare the output. There are some known differences:
- The module strongly normalizes input, standardizing the case of known classes and normalizing unrecognized input to "DEFAULT", which is currently defined as an alias to "unassessed".
- The module does not force icons for unrecognized input (see input row "blargh")
- The module does not support code "no", supported by {{class/icon}} but not {{class}}.
- The module produces correct labels for icons in cases where an icon is forced but not defined, whereas the template produces "Unrated" for those labels.
- The module uses cases labels for icons more consistently; {{class/icon}} uses different capitalization for the title of the icon wrapper span ("A-class Article") and the image itself ("A-Class article")
A few label strings might still be slightly off; I could use some review to find anything I might have missed.

As far as I know, all the known differences are improvements; if anyone thinks otherwise, please speak up. I'm eager to move things forward, but—as always—cautious given the huge scope of the template. {{Nihiltres |talk |edits}} 19:52, 17 January 2017 (UTC)[reply]

The above discussion is over my head, but will these changes resolve or create a maintenance category for the problem of templates with values of |class= that do not match anything in the list of valid values? I recently came across an invalid parameter value that caused a buggy bot edit, discussed here. Thanks. – Jonesey95 (talk) 00:58, 28 January 2017 (UTC)[reply]

@Jonesey95: The module doesn't currently implement that, but it wouldn't be hard to add: if canonicalCode resolves to nil but args.class or args[1] doesn't normalize to nil, then add a tracking category. I'll prototype this soon. Got a name for the category in mind? {{Nihiltres |talk |edits}} 07:54, 28 January 2017 (UTC)[reply]

The {{class}} template, as it stands, does not "validate" classes - it converts class codes into a table cell, providing for that cell a background colour, an icon, and text in the form of a category link. The subtemplates used for the colour and icon also do not validate - they recognise a certain broad set of values, returning defaults for unknown values: but an unknown value is not necessarily "invalid".

Class validation in WikiProject banners is largely performed by {{class mask}}; this takes an input value which may vary in case, or be an alias, and harmonises it to one of a small set of known values (for example, it alters "file", "FILE", "image", "Image" etc. to "File"), returning "NA" if it can't handle the input value; but {{class mask}} also allows values to be treated differently than normal, or for extra values to be treated as valid. This allows a certain amount of customisation with "normal" values being added or suppressed (see Template:Class mask#The lowercase parameter syntax) or even unusual values added (see Template:Class mask#The UPPERCASE parameter syntax) with the result that what is valid for one WikiProject is not necessarily valid for others. This means that if ((tlx|class}} is to consider the "validity" of a class value, it would need to be provided with the same data that {{class mask}} is provided with. I think that is taking it well beyond its intended scope. --Redrose64 🌹 (talk) 10:30, 28 January 2017 (UTC)[reply]

@Redrose64: It's my understanding that {{class mask}}'s function is to let input be normed before it hits {{class}}, i.e. {{class}} gets {{class mask}}'s output as its input. For example, {{class}} will happily render both NA-Class and Template-Class ratings, even though the expectation's that WikiProjects will usually implement either one or the other but not both. Similarly, {{class mask}} might change a B rating to a C if set up by a WikiProject to require specific B-class criteria.

I'm open to the argument that {{class}} should recognize entirely custom classes, e.g. the "CheeseCake-Class" mentioned in the {{class mask}} documentation you linked. The module as written aggressively normalizes unrecognized values to default, i.e. "unassessed", and I'm open to the argument that that's incorrect behaviour, and that'd in turn make it obviously undesirable to flag unrecognized input as Jonesey95 suggested. However, as written in the current template, unrecognized input's already treated like garbage: see e.g. the "blargh" rows in the tables at Template:Class/testcases, which I added as explicit examples of unrecognized input. The template can't provide colours or icons for these without edits to highly transcluded pages, anyway: my reading's that {{class}} ought not be treated as supporting custom classes per se.*

The "normalize unrecognized input to unassessed" behaviour aside, I think all the aliasing and case-norming behaviours present in the module are all harmless, positive, or reflect the current template. {{Nihiltres |talk |edits}} 17:23, 28 January 2017 (UTC)[reply]

(*More broadly, there's an expectation set in the structures here that classes are relatively universal, that even the "nonstandard" classes are worth implementing in templates that are extremely transcluded. Defining all classes in a JSON file, accessible to external code, furthers this assumption by implying that loading that file will let code recognize all extant classes. There's a risk here in that it this assumption makes it hard to create new classes at the single-WikiProject level, but it seems like this is mostly the case already.)

Over my head again, but I was asked about a potential category name. Something like "Pages using class template with invalid value" would probably work, with a parent category of Category:Wikipedia template parameter issues. I do a lot of work with pages in Category:Unknown parameters, and we have been working on standardizing category names and descriptions over there. – Jonesey95 (talk) 17:42, 28 January 2017 (UTC)[reply]

(←) I've been pondering how to handle the issue of normalization and custom classes. It's bad to do just partial normalization, it's bad to exclude custom classes entirely, but recognizing "bad" values is also valuable and I'd like to enable that.

One idea is to integrate {{class}} and {{class mask}} features. Some thoughts:

{{class mask}} would benefit from integration with definition.json; in particular adding a property letting classes be defined as either global or "full quality scale" (FQS) would simplify away a lot of the work that {{class mask}} does.
definition.json could benefit quite a bit from ordering somehow, i.e. some system that asserts that "FA" is a higher quality than "GA", or "C" the immediate step down from "B". This would need to be able to handle custom classes, that is: the scale needs to be adaptable to cases like adding a B+ rating between GA and B.
A potential approach to support for custom classes might be to support importing project-specific JSON files that extend and/or override the Wikipedia-wide quality scale object. The catch there's making sure that that performs well, since we might have to load several project-specific scale extensions on a single page, and custom importing means mw.loadData() might be impractical.
{{class}} and {{class mask}} are usually used somewhat separately, insofar as this approach implies largely merging them; in the bigger picture this implies tweaks to {{WPBannerMeta}}.

My broad idea would be to add {{class mask}} functions into Module:Class, implement {{class mask}} through the added function(s), and offer an easy way to implement class masks more directly. I bet it'd work really well to define class masks in JSON, since they usually cover a) toggling boolean presets, b) defining custom aliases, and c) defining custom classes. That implies a pretty straightforward pattern for use: something like "{{class|…|mask=Wikipedia:WikiProject Whatever/classMask.json}}" could work well. As an extension of that idea… filtering for Module-namespace pages in a mask parameter would let "write your completely custom class mask code in Lua" be a fallback for projects that really need extra flexibility.

I'm not sure what the best approach is here—I'm just thinking out loud and advocating for clean code that prefers using Lua/JSON, with separation of code from data, over the rat's nest of wikitext we've currently got. Thoughts? {{Nihiltres |talk |edits}} 20:47, 12 February 2017 (UTC)[reply]

Replacing `attr` parameter with `rowspan` and `colspan`

As part of moving forward with the earlier-discussed changes (moving to Lua code with JSON class definitions), I'm doing some cleanup to make the transition easier. One annoyance in transitioning is that the current code has an attr parameter that adds raw wikitext into the outputted element to allow custom attributes, which is messy and would prevent us from cleanly using mw.html in the Lua module when copying the wikitext version's functionality.

The attr parameter was little-used, and I've already fixed most of the cases I found in the wild, mostly replacing |attr=width=7% with |style=width: 7%; or similar changes. I used the search hastemplate:class insource:/\| *attr *=/ to find them, and double-checked the regex search afterwards against the broader search hastemplate:class insource:"attr". Unless my searching is faulty, there's exactly one use of attr left in the wild, at Template:Class mask/templatepage/row.

This last use applies a rowspan attribute, so to deprecate attr I've added rowspan and colspan parameters in the sandbox. My next moves are as follows:

Apply that change to the live template
Move Template:Class mask/templatepage/row to the new parameter
Remove the attr parameter entirely

Am I missing anything? Any objections or concerns? This seems trivial, but I figure review's always worth it on a template so widely-transcluded. {{Nihiltres |talk |edits}} 16:09, 12 December 2016 (UTC)[reply]

@Nihiltres: I wouldn't bother with a |colspan= parameter. If the attr parameter is only being used for rowspans, then I think that's all we should implement. We don't want to encourage people to use this template in even more complicated ways than it is being used at the moment. (Ideally I would want to get rid of the rowspan parameter too, but it looks like that would be difficult given how {{class mask/templatepage}} works and the amount of banner templates it is used in.) — Mr. Stradivarius ^{♪ talk ♪} 00:49, 14 December 2016 (UTC)[reply]

@Mr. Stradivarius: Fair point—no more complexity than we absolutely need. I do think colspan is relevant—the template produces a table cell, after all—but I suppose if it's needed we can add it later. I'll go ahead and add just rowspan now. {{Nihiltres |talk |edits}} 23:26, 14 December 2016 (UTC)[reply]

Done {{Nihiltres |talk |edits}} 23:38, 14 December 2016 (UTC)[reply]

Given the usage of this template, do take care not to make any unnecessary additional and non-urgent edits! Cheers — Martin (MSGJ · talk) 10:36, 15 December 2016 (UTC)[reply]

Renaming Category:Unassessed-Class articles

As part of working on Module:Class as discussed above, I've proposed that Category:Unassessed-Class articles be renamed to Category:Unassessed articles. This would make its root phrase ("Unassessed-Class") be consistent with the root phrase of its child categories ("Unassessed"), and therefore in simpler code.

In the current template, that would mean changing

  -->{{#switch:{{lc:{{{1|¬}}}}}
       |unassessed||¬={{#if:{{{topic|{{{category|}}}}}}|Unassessed|Unassessed-Class}}
       |#default={{{1}}}-Class
     }}<!--

to

  -->{{#switch:{{lc:{{{1|¬}}}}}
       |unassessed||¬=Unassessed
       |#default={{{1}}}-Class
     }}<!--

In the module, that would mean simplifying out special-casing:

	local categoryRoot = (
		(
			classCode ~= 'unassessed' and
			classDef and classDef.categoryRoot
		) or
		(
			(args.category or args.topic) and 'Unassessed'
		) or
		'Unassessed-Class'
	)

could become something more like

local categoryRoot = classDef and classDef.categoryRoot or default.categoryRoot

…with the caveat, of course, that I'm still working on the code and "better defaulting" is on my to-do list.

You can participate in the discussion at Wikipedia:Categories for discussion/Log/2016 December 20#Category:Unassessed-Class articles. {{Nihiltres |talk |edits}} 21:39, 20 December 2016 (UTC)[reply]

The CfD has closed in favour of the rename, since there was very little input and no opposition. Since Cydebot's already moved the categories around, I'll make the change to this template around midnight locally (I'm near DC; UTC -5). Making it around midnight should minimize the server impact. {{Nihiltres |talk |edits}} 15:39, 11 February 2017 (UTC)[reply]
- Done {{Nihiltres |talk |edits}} 05:33, 12 February 2017 (UTC)[reply]

Delisted good articles

@Nihiltres: Could you add a parameter for delisted good articles perhaps with this icon? Thanks.--TriiipleThreat (talk) 13:59, 9 December 2019 (UTC)[reply]

Isn't that already in the Icon template? <code>{{icon|DGA}}</code>

? -- WOSlinker (talk) 16:04, 9 December 2019 (UTC)[reply]

It doesn't appear to be included here in the Class template though.--TriiipleThreat (talk) 16:10, 9 December 2019 (UTC)[reply]

Correct, because it's not a class. If a GA is delisted, it's clearly no longer GA-class - but needs to be reassessed to see if it is now B-Class, C-class, or lower. --Redrose64 🌹 (talk) 19:46, 9 December 2019 (UTC)[reply]

Removal of book entry at Template:Class/definition.json

The book entry from Template:Class/definition.json needs to be removed. I would do it my self, but editing a sub-page of a page with over 9 minion transclusions which I no nothing about is a bit intimidating. Hopefully one of the regulars here can help out. Gonnym (talk) 11:41, 14 July 2021 (UTC)[reply]

That sub-page only has 5 transclusions, so you would be safe to update it yourself. -- WOSlinker (talk) 11:46, 14 July 2021 (UTC)[reply]

Protected edit request on 1 November 2021

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Error rate inverse function §→directed by virtue of its system atom programming interfaces syndicate data optimization. 50.40.239.119 (talk) 02:23, 2 December 2021 (UTC)[reply]

50.40.239.119 (talk) 02:23, 2 December 2021 (UTC)[reply]

Not done I have no idea what change you want to make to this template. — xaosflux ^Talk 14:45, 2 December 2021 (UTC)[reply]

Move to Lua/JSON version

After dropping the project for … five years (see old discussions above) … I'm looking at re-implementing this template in Lua and JSON again. The basic details are thus:

The template (and its subtemplates {{class/colour}} and {{class/icon}}) become implemented by Module:Class.
All definitions for classes are defined in JSON at Template:Class/definition.json. I documented the (mildly tentative) schema at Template talk:Class/definition.json. This definition could ultimately serve as a central, portable, definition for classes, allowing other applications (including user-side JavaScript like the Wikipedia:Metadata gadget) to pull from it rather than redundantly define quality classes.

Given the absolutely bonkers usage of this template (~17% of all pages) it's quite important that I check regarding updates. You can see a live comparison of this update to the live version at Template:Class/testcases. The new version operates slightly differently than the old one:

Class codes are case-insensitive and canonically lowercase, with the single exception of the special "DEFAULT" code that aliases to "unassessed" in the definition. Previously classes were case-sensitive.
Classes are aggressively normalized; unrecognized class codes will not be passed through but will resolve to the "DEFAULT" code, i.e. "unassessed". Previously unrecognized class codes were passed through.
Where data is missing from any class definition, it will pull required data from the "DEFAULT" class, i.e. "unassessed". Previously this behaviour was less strict, inconsistent, sometimes pulling from elsewhere like {{icon}}; most of the differences are for obsolete classes like "B+" or "Book" or non-classes like "no".

I'd like some eyes to help double- and triple-check that everything works. There are a couple of known edge cases currently to resolve:

The partially-supported "FPo" class, retaining ratings for the defunct "featured portal" status, is not supported currently. Should it be added? Do we need to tweak the schema to handle its unusual alt text, and if so, how ought we?
The "merge", "needed", and "user" classes have no defined icons, and so default to the unassessed "?" icon if an image is forced. Should these have icon images defined, and if so, which? Icons to be used will need to be reuploaded locally from Commons and fully-protected.

Thank you for your time helping to review this change. If to be implemented, I'll try to schedule the update so that it coincides with a period of lower site traffic to minimize the impact of updating so many pages. {{Nihiltres |talk |edits}} 17:35, 21 May 2022 (UTC)[reply]

Looks ok but I did notice one slight difference that could be fixed. The current version sets alt to blank for all images. The lua version is currently only setting alt to blank on some images. -- WOSlinker (talk) 19:33, 21 May 2022 (UTC)[reply]

Good catch, thanks! I fixed it. {{Nihiltres |talk |edits}} 20:29, 21 May 2022 (UTC)[reply]

Quick addendum: I'm still working on polishing the code, and one tentative update is a move to use TemplateStyles instead of inline CSS for most stuff, with the stylesheet currently at ~~Template:Class/styles.css~~ Module:Class/styles.css. Some to-do items, largely courtesy Izno via Discord, include:

Expand data import sub-module to a module-namespace config page that contains all translateable strings as well as the JSON import
Move data pages like styles and JSON to module-namespace pages for namespace consistency
Change .assess- CSS class so that .assess-default is used instead where applicable
Consider using mw.text.nowiki instead of an extension tag in p._colour

I'll tackle most of these in the near future. {{Nihiltres |talk |edits}} 20:29, 21 May 2022 (UTC)[reply]

Shouldn't the "font-weight:bold" style be moved into the CSS as well? Oh, and the header=yes option isn't working. -- WOSlinker (talk) 21:07, 21 May 2022 (UTC)[reply]

The "font-weight:bold" style is conditional, so it should stay on the generated element. The "header=yes" option wasn't working because it was accidentally renamed "heading"; it's otherwise functional and I'll fix it shortly. {{Nihiltres |talk |edits}} 23:00, 21 May 2022 (UTC)[reply]

Minor update: I looked more closely at the bolding issue and remembered that bolding is default, so I reversed the logic: bolding is enabled by default in the stylesheet and the bolding can be disabled with inline CSS if so selected. I've also fixed the "header" naming. {{Nihiltres |talk |edits}} 23:18, 21 May 2022 (UTC)[reply]

Just wondering, what are you going to do with the WikProject Portals classes? -- WOSlinker (talk) 23:31, 21 May 2022 (UTC)[reply]

I've mostly added support for those, but I still need to handle the unusual icon text for FPo-Class for full support. {{Nihiltres |talk |edits}} 17:59, 22 May 2022 (UTC)[reply]

(←) I think I've resolved all the important issues, and I've updated the test tables with rows for the portal classes. As far as I can tell, the module is now strictly superior to its template counterpart. The remaining issue I see would be whether to add icon values where they're missing, but that applies to the template as well, so it's strictly an enhancement and not a problem with the module. At this point, if I don't hear any blockers in a week or so, I'll schedule and implement the change. {{Nihiltres |talk |edits}} 18:57, 25 May 2022 (UTC)[reply]

The module looks great. Some small things I noticed:

In Module:Class/configuration, you've created a table called "messages" yet there are many non-message things there such as "Module:Class/styles.css" (which then gives us something like "msg.stylesLocation"). The name of the table can be made more clear here.
Regarding Module:Class#L-182 and The "font-weight:bold" style is conditional, it can still be conditional, and instead of adding the CSS, add a class (that is if we want to move all CSS outside the module). Gonnym (talk) 04:49, 27 May 2022 (UTC)[reply]

Thanks for your input, Gonnym. I named the table "messages" because its focus is on localizable messages, and to some degree that's still accurate even as it's drifted to all localizable configuration values. I'm not sure what else to call it, but I'm open to suggestions. I'd prefer to not use the term "configuration" as that refers to the greater configuration file rather than the specific sub-table, but other than that … I agree the naming could be better. Regarding the bolding, I've just moved that to a class, given that's been raised as an issue by multiple people. {{Nihiltres |talk |edits}} 20:33, 1 June 2022 (UTC)[reply]

Done; now we wait for any bug reports or feature requests to come in. Please ping me as needed. {{Nihiltres |talk |edits}} 17:57, 11 June 2022 (UTC)[reply]

Inline style block not being interpreted

I'm not sure if this template is the root cause, but for me (using Brave browser on Linux) the inline <style>...</style> block generated as part of this template does not render as adding styles, but instead as an unknown element which dumps the text of the CSS into the <td>...</td>. This causes the whole project banner to be distorted. Is this happening to anyone else, and is it a known issue? Happy‑melon 15:54, 22 November 2022 (UTC)[reply]

@Happy-melon: On which page is this occurring? --Redrose64 🌹 (talk) 17:26, 22 November 2022 (UTC)[reply]

Every talk page which has at least one WikiProject banner. Happy‑melon 09:35, 23 November 2022 (UTC)[reply]

It's the line .wpb .assess * { display: inline !important; } in your vector.css page that is causing the issue. -- WOSlinker (talk) 10:40, 23 November 2022 (UTC)[reply]

Well spotted! Thanks. Happy‑melon 11:41, 23 November 2022 (UTC)[reply]

Symbol change request

There is a request open at Module_talk:Class/definition.json#Protected_edit_request_on_15_February_2023 to change one of the symbols used in the related module, if you have input on that please reply to that discussion. — xaosflux ^Talk 13:38, 16 February 2023 (UTC)[reply]

Edit request

This edit request to Module:Class/definition.json has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Change the icon from (File:Symbol_redirect_vote2.svg) to (File:Symbol_redirect_class.svg), because it better matches the color used for redirects at WP:NONSTANDARDCLASS. —pythoncoder (talk | contribs) 01:43, 15 February 2023 (UTC)[reply]

Administrator note should do local shadow copy and protect like the former file if this is going to happen. — xaosflux ^Talk 13:36, 16 February 2023 (UTC)[reply]

Administrator note local file prepped and ready. — xaosflux ^Talk 16:36, 23 February 2023 (UTC)[reply]

On hold advertised this to Template talk:Class, a week should be sufficient unless it becomes an active discussion here. — xaosflux ^Talk 13:38, 16 February 2023 (UTC)[reply]
Talk pages merged for convenience — Martin (MSGJ · talk) 22:12, 21 February 2023 (UTC)[reply]

Done — xaosflux ^Talk 13:48, 24 February 2023 (UTC)[reply]

Width

I would like to add a parameter to set a minimum width for the table cell. Is there any issue with this? — Martin (MSGJ · talk) 13:45, 19 February 2023 (UTC)[reply]

I have added |width= to Module:Class/sandbox and there is a test at Template:Class/testcases#Single cell — Martin (MSGJ · talk) 21:27, 21 February 2023 (UTC)[reply]

I would not support this. We should use TemplateStyles downstream to set the width expected. Izno (talk) 22:06, 21 February 2023 (UTC)[reply]

Can you tell me how I would do this? I am going to call it from Template:WikiProject banner shell — Martin (MSGJ · talk) 22:10, 21 February 2023 (UTC)[reply]

Each table cell emits two HTML classes by default. One is assess and the other is assess-CLASS. Template:WikiProject banner shell/styles.css exists (though for your purposes you will want to work in Template:WikiProject banner shell/sandbox/styles.css). In that page, besides copying the current live version, you would add something along the lines of .wpbs-sandbox /* for sandboxing purposes you should probably change that one also */ .assess { width: X; }. I would further recommend putting it inside a media query for minimum width so that it doesn't take effect except above certain monitor resolutions, but that is of course optional. Izno (talk) 23:37, 21 February 2023 (UTC)[reply]

Didn't work. Please could you check Template:WikiProject banner shell/sandbox/styles.css and Template:WikiProject banner shell/sandbox? My test case is at Template:WikiProject banner shell/testcases#Inherited global class — Martin (MSGJ · talk) 12:30, 22 February 2023 (UTC)[reply]

Adding inline styles here also doesn't work, just so you know. :) Izno (talk) 17:37, 22 February 2023 (UTC)[reply]

It's because the header of the table has mbox-text class, which has width: 100%. The hackery on line 9 that has been added in WPBS/sandbox to support a second cell here rather than the expected 1 and only cell is the cause of the issue. Removal of mbox-text here and using another class with CSS definition or "tacking on" to the definitions of banner-shell-header in WPBS/styles.css will work. You will need to add a width for the whole banner in WPBS/styles.css as well, similarly to how Module:Article_history/styles.css appears. Izno (talk) 17:44, 22 February 2023 (UTC)[reply]

Sorry but I can't understand much of this. Somehow I thought this would be more complicated than you made it sound! Would you mind getting it to work in the sandbox for me? (Or withdrawing your opposition to a width parameter, which I can actually understand ...) — Martin (MSGJ · talk) 12:41, 23 February 2023 (UTC)[reply]

Should be working now. Izno (talk) 22:07, 23 February 2023 (UTC)[reply]

Looks good - thanks Izno — Martin (MSGJ · talk) 22:16, 23 February 2023 (UTC)[reply]

Protected edit request on 25 February 2023

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

While this template is still fresh in my mind, we should also change the set index icon from the current File:Symbol list class.svg to the actual File:Symbol sia class.svg . —pythoncoder (talk | contribs) 04:08, 25 February 2023 (UTC) —pythoncoder (talk | contribs) 04:08, 25 February 2023 (UTC)[reply]

I'm not in favour, it's not so clear. --Redrose64 🌹 (talk) 10:08, 25 February 2023 (UTC)[reply]

Not done for now: please establish a consensus for this alteration before using the {{Edit protected}} template. Izno (talk) 02:15, 1 March 2023 (UTC)[reply]

Add Help class to json file

Over at template:class mask, we've added support for a Help class for WikiProjects to use. As such, I think we should add it to the list of classes in the module:Class/definition.json file so that it displays properly in the documentation. I don't have access to the right kind of software to make an svg, so there isn't an icon for it and I request that someone else create that, and I don't know how the color scheme works so I've marked the color as white, but otherwise, I think it would be as follows?

    "help": {
        "categoryRoot": "Help-Class",
        "colour": {
            "base": "#ffffff"
        },
        "icon": {
            "file": "Symbol_help_class.svg",
            "default": false,
            "requiresAttribution": false
        },
        "labels": {
            "adjective": "help",
            "full": "help page",
            "short": "Help"
        }
    },

Indigopari (talk) 02:29, 1 May 2023 (UTC)[reply]

Additionally, I think the help class would also have to be added to the module:Class/styles.css file. Also, I realised my question here is not quite clear, so: I'm asking whether there is support or opposition to my suggested change, I'm requesting that someone create the icon needed for the help class, and I'm wondering if there's anything I've missed in terms of what other changes are necessary to implement documentation for the help class. Indigopari (talk) 02:59, 1 May 2023 (UTC)[reply]

For requests for images/icons, you could try Wikipedia:Graphics Lab — Martin (MSGJ · talk) 19:00, 3 May 2023 (UTC)[reply]

Change colour of unassessed

There is a proposal at Template talk:WikiProject banner shell to change the colour of unassessed class from transparent to #dcdcdc (see diff ) — Martin (MSGJ · talk) 17:36, 3 May 2023 (UTC)[reply]

Done — Martin (MSGJ · talk) 11:40, 9 May 2023 (UTC)[reply]

Merge with Module:WikiProject banner

I believe that 99.99% of uses of this module are via Module:WikiProject banner. It may be used independently on a few documentation pages. Would it make sense to merge the functionality into that module? — Martin (MSGJ · talk) 15:47, 9 November 2023 (UTC)[reply]

Change of colours

Please see proposal at Module talk:WikiProject banner#Class colours to use a paler set of colours — Martin (MSGJ · talk) 20:04, 17 December 2023 (UTC)[reply]

Fix broken link for FM

Recently there was a CfD where Category:FM-Class articles was moved to Category:FM-Class pages. This promptly broke the link on FM related templates. To address this, it appears that the hardcoded categoryRoot would have to be modified somehow, but I lack the coding expertise to identify the exact changes necessary. Therefore, I'm hoping that someone familiar with the template might be able to take a look. Thanks VolatileAnomaly (talk) 01:58, 2 December 2024 (UTC)[reply]

Related: Template:Category class has this line:

 -->[[Category:{{{class|}}}{{#ifeq:{{lc:{{{class|}}}}}|unassessed||-Class}} articles|{{{sort|{{ucfirst:{{{topic|}}}}}}}}]]<!--

which puts cat pages like Category:FM-Class Abkhazia articles into Category:FM-Class articles. --Redrose64 🌹 (talk) 17:36, 2 December 2024 (UTC)[reply]

Bold

File-Class

Colours and icons

Purpose?

Last edits...

A couple of requests

A-Class

Category name override

Revisited

Template:Class and non-WPBannerMeta banners

white-space:nowrap;

topic parameter

Use as column heading

User-Class, Deferred-Class and AL-Class icons

New icons

Idea: define classes in JSON

Lua/JSON rewrite: an update

Replacing attr parameter with rowspan and colspan

Renaming Category:Unassessed-Class articles

Delisted good articles

Removal of book entry at Template:Class/definition.json

Protected edit request on 1 November 2021

Move to Lua/JSON version

Inline style block not being interpreted

Symbol change request

Edit request

Width

Protected edit request on 25 February 2023

Add Help class to json file

Change colour of unassessed

Merge with Module:WikiProject banner

Change of colours

Fix broken link for FM

Replacing `attr` parameter with `rowspan` and `colspan`