This section is for the script's maintainer to request that an admin update the gadget to the latest version.
If the above editprotected template is expanded, please update the gadget with the current version of User:Pyrospirit/metadata.js, then replace the template with {{tlx|editprotected}}. No need to add {{done}} or anything; I'd like to avoid cluttering up this page with update requests. Thanks, Pyrospirit (talk·contribs)
I would have appreciated a ping that my script had been modified and placed in the MediaWiki namespace (which looks awfully official, I never see it). I see this page is newer than I realized, but still. –Outriggr§01:16, 15 March 2008 (UTC)[reply]
Sorry about that. Pyrospirit version (which assesses diff links as well as articles) was put in consideration as gadget back in January, but just a week ago I turned it into a gadget. Somehow I thought you did already know about this, sorry for assuming. You can add yourself to the list of maintainers of the script, since you were the original creator and will likely know how to fix problems when they appear. -- ReyBrujo (talk) 17:25, 15 March 2008 (UTC)[reply]
This gadget marks List-Class articles as unassessed, but now that WP:1.0/I allows List-Class in their parameters, many more articles will use this assessment, so can the gadget be changed to show it? --Arctic Gnome (talk • contribs) 21:00, 20 March 2008 (UTC)[reply]
I'm working on overhauling the script a bit. I've got a couple questions:
Does anyone actually use the hook system currently in place? It's awkward, and I've removed it in my draft—but if someone is attached to it, I can add something similar in its place, and even update relevant on-wiki code.
Pyrospirit, the current maintainer, last edited in June 2012. Would anyone object were I to take over as maintainer?
I'll post my draft code for review once I polish it up a bit; it seems to provide virtual identical functionality so far, but a) I've not tested it to my satisfaction and b) I'm not happy with some of the flow. {{Nihiltres |talk |edits}}04:10, 13 August 2015 (UTC)[reply]
@Christian75: I mean code like this.callHooks('init_before');, and the callHooks() and addHook() functions near the bottom of the gadget. In theory, they'd let someone insert custom code at particular points in the execution. They're awkward and not particularly useful in the context of a gadget, but might make sense in a user-script. {{Nihiltres |talk |edits}}17:40, 13 August 2015 (UTC)[reply]
I've posted my draft at User:Nihiltres/Gadget-metadata.js. Please review it and suggest improvements where applicable. There's a decent chance I've broken something along the way, so testing it as well as reviewing it is also helpful. Keep in mind that using the JavaScript draft on its own won't apply the CSS styles included in the gadget, which are unmodified. {{Nihiltres |talk |edits}}16:49, 15 August 2015 (UTC)[reply]
Thanks for doing this, the code is much cleaner now. However, there's one problem that's keeping me from testing it further. If you use the preference to format links to stub pages with a different color (Preferences > Appearance > Advanced options), the links unfortunately use the same stub class as the stub templates, so every article that has a link to a stub is being assessed as a stub for me. This is easy to fix, by changing the selector on line 76 from .stub to table.stub. Thanks, /~huesatlum/ 18:06, 16 August 2015 (UTC)[reply]
However, I have determined that the script looks for certain key words, one of which is currentstatus, and does not check whether those are inside <!--...--> comments or not. In the {{Article history}} on Talk:Briarcliff Manor, New York there were both <!--|currentstatus=GA--> and |currentstatus=FA in that order, and the script doesn't look beyond the first one. So it assumed that the article was GA. This edit should fix it. --Redrose64 (talk) 11:13, 20 August 2015 (UTC)[reply]
No. This has nothing to do with the infoboxes. The title of the article is supposed to be in a color representing the class of the article. Hawkeye7 (talk) 21:11, 22 August 2015 (UTC)[reply]
I guess you refer to the gadget "Display an assessment of an article's quality as part of the page header for each article" at Special:Preferences#mw-prefsection-gadgets. Do you have it enabled? What is your skin and browser? When I enable it, Atomic bombings of Hiroshima and Nagasaki gets a green heading and this text below the heading: "A good article from Wikipedia, the free encyclopedia. A former featured article candidate." Oppenheimer security hearing is black for me with no added text (just displays the default "From Wikipedia, the free encyclopedia") so something appears to be up with the gadget. I have Vector and Firefox and do get coloring on most tested articles. User:Nihiltres who made this edit may be able to say something. PrimeHunter (talk) 21:47, 22 August 2015 (UTC)[reply]
(ec) Normally, the titles are not colored. Bt there is a gadget that does ("Display an assessment of an article's quality as part of the page header for each article", see also User:Pyrospirit/metadata). Check to see if that is enabled in your preferences. -- [[User:Edokter]] {{talk}}21:47, 22 August 2015 (UTC)[reply]
The bolding and multiple posts is getting a bit much. Just wait for somebody qualified to examine it. It's only an opt-in gadget for registered users at the English Wikipedia, and it doesn't seem to do any harm apart from possibly giving inaccurate information to some editors. Software often needs maintenance. Some things might be easier if no features had been added to Wikipedia since it opened, and it only had to work in browsers and operating systems which existed then. PrimeHunter (talk) 22:23, 22 August 2015 (UTC)[reply]
Hawkeye7, I get the same thing you get on that specific article. I tried changing everything to A-class on the talk page, except the GA template. I think it's the GA template that is confusing it. All other articles I see have the correct color - it's just that one. Back in Dec 2013, when this one received the AL rating, it also never showed that on the article. I think the conflict is something on the talk page banners. — Maile (talk) 23:25, 22 August 2015 (UTC)[reply]
Don't bother fiddling with the talk pages; I already tried all that. The bug is in the script. ratingList contains the ones that are not working. typeList ones are working. I'll @Nick-D: and see if he can revert the page. Hawkeye7 (talk) 23:53, 22 August 2015 (UTC)[reply]
@Hawkeye7: sorry, which page do you want me to revert? Are you referring to this change? If so, I'm a bit nervous about reverting it given a) the warning and b) the scope for knock-on effects which I don't know much about. Nick-D (talk) 23:58, 22 August 2015 (UTC) (also @Nihiltres: )[reply]
It will just put it back to what it was from October 2014 until a couple of days ago. I would submit an edit request, but that normally requires a working code fragment and I don't have one. Hawkeye7 (talk) 00:10, 23 August 2015 (UTC)[reply]
I understand. I am often called away suddenly. How do you test the new userspace version Gadget? And can you tell me why the line six lines above that one returns false instead of rating? Hawkeye7 (talk) 20:38, 23 August 2015 (UTC)[reply]
We are only half-way there. The new widget now correctly displays the assessment line underneath the title like "A B-class article from Wikipedia, the free encyclopedia. Currently a good article nominee. A former good article nominee." but it is not correctly colouring the heading. Hawkeye7 (talk) 21:42, 23 August 2015 (UTC)[reply]
Maybe I missed it being addressed somewhere else on this page, but there seems to be a bug with the assessment of articles containing stub tags. If an article contains a stub tag, the article title and color reflect that it is a stub class-article, regardless of the article's classification on the talk page. Even if the talk page is updated to Start-class or higher, the widget still says that it is stub-class until the stub tag is removed. Shouldn't the widget reflect the classification on the talk page, regardless of the presence of stub templates? Fortdj33 (talk) 14:45, 25 August 2015 (UTC)[reply]
I considered this, but came to the conclusion that when a talk page and article are out of sync on stub status, the mistake is on the article or its talk page, not in the script. Start-class (or better) articles should have their stub templates removed. Of course, if enough others disagree, it would be simple enough to remove the table.stub check from the checkArticle function.
The behaviour of assuming stub status based on the presence of a stub template saves the script from needing to make any AJAX calls on a page including one, thereby making the script more efficient. {{Nihiltres |talk |edits}}21:01, 25 August 2015 (UTC)[reply]
I'm not sure. It has always worked this way. I have always felt that if you reclassify an article as higher than stub, then the stub tags should be removed too, thereby removing the article from the stub categories. So the colour warns me that I have overlooked the stub tag. Hawkeye7 (talk) 21:16, 25 August 2015 (UTC)[reply]
Yes, the version prior to 19 August ignored the stub templates on the article itself, which aided me a lot when deciding whether to undo good-faith edits by newbies who were adding stub templates to every article, presumably under the impression that these templates are used for general categorisation. I simply went through their contribs, looked for diffs that added a stub template, and if it didn't say either "A stub-class article from Wikipedia, the free encyclopedia" or "An unassessed article from ..." at the top, I would revert, as I did here (n.b. that guy isn't a newbie, he's a pain in the a**). However, whilst the pre-revert version of that article would have shown "A C-class article from ...", it now shows "A stub-class article from ..." so if that same case came up again (which is not unlikely) I would now need to click through to the talk page to check. --Redrose64 (talk) 23:42, 25 August 2015 (UTC)[reply]
Exactly. I agree that if an article has been upgraded, the stub tag should be removed. But if someone updates the talk page and does not remove the stub tag, the widget still displays that article as a stub, which is misleading. The color should reflect the status of the talk page, not the presence of a stub tag. Using the color to indicate the status of the talk page, allows editors to check the classification of articles at a glance, without having to add the extra step of checking the talk page. Fortdj33 (talk) 14:19, 26 August 2015 (UTC)[reply]
Another reason is that if someone adds a stub tag to an article which has not yet been assessed or has a blank talk page, the widget still displays the article as a stub-class article, giving no indication that the talk page needs to be updated. Fortdj33 (talk) 16:17, 26 August 2015 (UTC)[reply]
Sorry to keep harping on this, but IMO a widget that is supposed to display an assessment of an article's quality, is no good if it doesn't portray the quality assessment on the talk page. Is there a script that we can add, so that the color accurately reflects the talk page status, regardless of whether the article has a stub tag or not? Fortdj33 (talk) 12:54, 28 August 2015 (UTC)[reply]
Thank you. That seems to have solved part of the problem, as the assessment is now showing up correctly, but even after purging an article, the corresponding color is still off. An example is Singh Is Bliing, which now states that it is a start-class article, but still shows the color of being stub-class (presumably because the stub tag has not yet been removed). Fortdj33 (talk) 13:25, 28 August 2015 (UTC)[reply]
No, the test of stub template was entirely disabled, the presence of a stub template can no longer affect the colour of the page title. The CSS rule that sets the colour of the title at Singh Is Bliing is
.assess-start-text{color:#B60;}
which is . By contrast, a true stub-class article like Iffley Halt railway station has its title coloured by the rule
Not sure what I'm missing, but when I double checked Singh Is Bliing just now, it stated that it was a start-class article, but the color was still the darker red color. When I removed the stub tag from the article, the color changed to the expected orange for start-class articles. Fortdj33 (talk) 14:01, 28 August 2015 (UTC)[reply]
Another example of an article where I updated the talk page, but have not yet removed the stub tag because of this glitch, is Sultanat (2014 film). Again, I purged the page, and the assessment updated to show that it is a start-class article, but the title is still showing up in my browser with the darker red color for stub-class. Additionally, the article Boulder Dam (film) is currently unassessed, but is also showing the darker red color for stub-class. Clearly the presence of a stub tag on these articles, is still affecting the color of the title somehow. Fortdj33 (talk) 14:58, 28 August 2015 (UTC)[reply]
@Finnusertop: It shouldn't take too long: my overhaul of this script made it significantly easier to add rating-classes, and I'm most of the way through writing it (rather relaxedly). I have thought about adding importance metrics, but I haven't done it for a few reasons: First, because importance is far more likely to be variable between WikiProjects, whereas quality tends to be judged the same among all WikiProjects. That makes it technically difficult and harder to cleanly represent. Second, I find importance metrics to be somewhat subjective, and thus undesirable to highlight. Third, it wasn't implemented in this script before I overhauled it and started maintaining it, so I feel that adding it would change the scope of the gadget. {{Nihiltres |talk |edits}}17:58, 20 October 2015 (UTC)[reply]
@Nihiltres: Yeah, sounds like you have thought of it through. I agree with your reasons of not including importance metrics. They are supposed to vary by project. Although perhaps by their nature Vital and Core articles are a bit different in this respect (they seem to be rather consistently Top-importance, and Version 1.0 Editorial Team makes it a bit less subjective). Finnusertop (talk | guestbook | contribs) 18:13, 20 October 2015 (UTC)[reply]
Done. AFAICT the ratings are only fully implemented and documented by the military history WikiProject, so all of them link to that project's scale information, though it looks like WikiProject Highways might also implement AL. The changes should show up fairly soon; if my cotton-ball-stuffed head has managed to mess something up, poke me again and I'll fix it. {{Nihiltres |talk |edits}}18:17, 20 October 2015 (UTC)[reply]
@Nihiltres: Sorry to bother you again, but I'm getting spotty results. Some articles show the correct new class (Camoufleurs), some don't (Force in Egypt). In most cases the new classes are superseded by old ones from other Wikiprojects' templates. This happens regardless of which class is higher. But List-class seems to creep in even if eg. C-list is the only rating (see the examples above). If whatever it is that is broken will be fixed, I'm sure you've earned your place in The Bulge. Finnusertop (talk | guestbook | contribs) 02:18, 22 October 2015 (UTC)[reply]
I see. On those pages, it looks like there's implicit rating, i.e. on Talk:Force in Egypt the code appears like so:
{{WPMILHIST|class=List|list=yes
| B1 <!-- Referencing and citations --> = y
| B2 <!-- Coverage and accuracy --> = n
| B3 <!-- Structure --> = y
| B4 <!-- Grammar and style --> = y
| B5 <!-- Supporting materials --> = y
|ANZSP=yes
|British=yes
|WWI=yes
}}
In this example, CL-class is deduced in the template by finding that the list meets certain, but not all, B-class criteria. The code of this gadget assumes that ratings are actually present in the source of the top section of the talk page; it specifically looks for class=class abbreviation in virtually all cases, hence picking up the class=List there. This is problematic, since "List" is also a valid rating-class in the MILHIST system. I could in theory write code that specifically picked up {{WPMILHIST}} (and all of its redirects…) and evaluated it, but I must object to adding a big chunk of code specific to a single WikiProject—the gadget's loaded on every page, after all. Any ideas? {{Nihiltres |talk |edits}}03:39, 22 October 2015 (UTC)[reply]
I had no idea those checklists are used to dynamically give ratings; I thought they are there just to remind of the class criteria. Sounds like a complex thing to implement. I don't think you should trade slick code for this feature. I don't want you to break existing functionality; I've never known Wikipedia without this script and wouldn't cope without it Finnusertop (talk | guestbook | contribs) 04:02, 22 October 2015 (UTC)[reply]
I went through and researched its behaviour: it doesn't seem practical to emulate, though I'll play around with it for a bit. Some ratings respect the class parameter, and some fall back to lower ratings unless other parameters have certain values—not to mention the article–list split. I'll add a note to the documentation acknowledging this as a known issue; for now the solution for any given article is to fix the class parameter in the template on the talk page to reflect the displayed value. {{Nihiltres |talk |edits}}06:03, 22 October 2015 (UTC)[reply]
There are quite a few WikiProjects that have a B-class checklist, for example {{WikiProject Mountains}}. This usually works on the basis that if the page has |class= set to anything other than "b", that class is used without further modification; but if |class=b is explicitly set, then all six of the B-class parameters need to be set to "yes" in order that the page be assessed as B-class - if at least one is blank, omitted, or set to "no", the page is treated as if |class=c were set instead. Most of the code for this is in {{class mask}}. Some WikiProjects with a checklist (e.g. {{WikiProject Maps}}) have provision for only five checklist parameters, and with these, the sixth is implicitly "yes". For the checklist, the parameter names also vary: some WikiProjects use |b1= etc.; others |B-Class-1= etc.; some permit either form. --Redrose64 (talk) 07:42, 22 October 2015 (UTC)[reply]
OK, so the question becomes how those can be better supported in general. A good solution will let us easily grab the rendered rating with a single API call and no special-case code. Parsing specific parameters is only really practical with special-case code given the variety in WikiProject syntax. This might be a question of improving WikiProject banners in general—e.g. adding functionality so that their rating and importance metrics are tagged with CSS classes or something. Alternatively, perhaps categories can be used? Categories would reflect rendered output, but I don't know if detecting rating categories would be reliable. What do relevant bots tend to use? I need ideas. {{Nihiltres |talk |edits}}16:16, 22 October 2015 (UTC)[reply]
@Finnusertop and Redrose64: I've finally gotten around to writing some code that'll theoretically support the WPMILHIST rating scheme. The code grabs the values of the B1–B6 parameters (B6 optional), and if B1's present, it re-evaluates the ratings List, A, AL, B, BL, C, and CL according to the MILHIST scheme, including for A/AL whether |A-Class=pass is set. The code's available at User:Nihiltres/Gadget-metadata.js; please look it over and test it! :) In particular, I'm betting it'll have inconsistent results with respect to other WikiProjects that implement similar schemes with slightly different assessment rules. :/ {{Nihiltres |talk |edits}}03:24, 28 December 2015 (UTC)[reply]
Most WikiProjects that have a B-Class checklist will only test that when |class=b is set - otherwise, the checklist is ignored. When they do test the checklist, and there isn't a full set of six (or five, as the case may be) that have been set to "yes", the class is dropped from B to C, but no further. --Redrose64 (talk) 21:59, 28 December 2015 (UTC)[reply]
I have this gadget turned on in my preferences and the peer review link that it produces at the top of Nelson's Pillar doesn't work. The error message says: "The requested page title contains invalid characters: "%27"." This seems to be the Unicode character for the apostrophe failing in some way. Can this be fixed? Carcharoth (talk) 16:52, 17 March 2016 (UTC)[reply]
Fails for me too. It seems that the URL is being percent encoded twice, so that the apostrophe first becomes %27 (which is correct) and the percent sign is then percent-encoded to %25, which is incorrect behaviour.
I've found the problem and will fix it soon after a quick review. In am.renderAssessment there's the line peerReview = assess.review && mw.util.wikiUrlencode(assess.review) and then in am.addPeerReview there's mw.util.getUrl(peerReview). Each of mw.util.wikiUrlencode() and mw.util.getUrl() is applying percent-encoding. {{Nihiltres |talk |edits}}17:30, 17 March 2016 (UTC)[reply]
Perfect! Can you wave a magic wand and produce peer reviews as well...? Seriously, many thanks for that. It is great to get things like that fixed so quickly. Carcharoth (talk) 17:55, 17 March 2016 (UTC)[reply]
Gadget is misinterpreting the parameters of Template:Article history
You guys have done a great job with making sure that the colors are at least WCAG AA 18+ compliant for large text. I also ran it through Sim Daltonism (a color blindness simulation tool) with some of the more common color blindness. Here are the results in screenshots below. Red / green color blindness is the most common, so as I had suspected, the orange/red/green colors would have posed some issues. This is a link to a really good and short example on what I'm highlighting.
Protanopia
Deuteranopia
Protanomaly
Deuteranomaly
My suggestions are to:
Remove either red or green in the palette. Instead, use graphical elements to distinguish different levels within a grouped grade (good article, B class, C class). So e.g., instead of different shades of green for good article, B class and C class, use the same color but different graphical element to distinguish the three different classes.
Include a tooltip to give more context to remind about what the color/graphical element mean
There are several advantages with the added tooltip:
Giving option to read more about the article class
Ability to add a call-to-action to improve content
I'm also always trying to find ways to humanize Wikipedia articles, so this will give an opportunity to mention that these articles are edited and reviewed by humans (e.g.: this article has been peer-reviewed)
To address the main issue: the additions to the tagline made by the gadget already support colourblind users by literally spelling out the information as text. The colour is just a nice bonus for those who can see it. The tagline format also manages minimalism (less added complexity in the UI) by enhancing an existing feature (the tagline) rather than adding new ones (icons and tooltips), and doesn't require user interaction (hover or tap for the tooltip, with only a cryptic icon until users figure that out). For all that the proposed design's pretty, I oppose moving towards it unless the tagline were planned to be removed.
You mention "ways to humanize Wikipedia articles" and that "this will give an opportunity to mention that these articles are edited and reviewed by humans (e.g.: this article has been peer-reviewed)"; the script already highlights current and former GA-, FA-, and peer-review-related processes noted on the talk page. Are there other things it should capture?
I like the sound of of adding a "call to action", but I'm not sure in what ways I'd implement that, or if the gadget's install base is an appropriate target for those calls. Would you elaborate? {{Nihiltres |talk |edits}}07:36, 24 December 2015 (UTC)[reply]
Oh wow, you’re right. I just looked again for the tagline and found it this time. I’d have to say, it is a very minimal way of tackling this issue for the colorblind. I hope it was just me that I missed the new info added to that line since I typically gaze pass that "From Wikipedia, the free encyclopedia” line. Now that I read your explanation, I'm questioning if I would have noticed the tagline explanation association with the title color change. I don’t think it's compulsory, but when users notice the title color change, they might wonder why. Regarding humanizing Wikipedia articles. I come from the perspective that we should always find an opportunity to humanize our content and inviting knowledgeable humans to improve/edit Wikipedia articles. This perspective comes from our general readers' impression that Wikipedia articles are untouchable or that it’s easily broken once they touch it. But the fact is that humans collectively wrote these articles and so humans can also collectively fix. Sounds simple but our readers somehow do not see their connection between Wikipedia human editors and themselves. The call-to-action for e.g. a stub-class could be as simple as a line like:
This is a stub-class article—bad quality articles fall into this category. You can try adding more meaningful content in this article to improve it!
"Meaningful content” can link to something like that: https://en.wikipedia.org/wiki/Wikipedia:Article_development#Research So.. if you were to entertain an idea like that, I suggest that this info is presented as part of the tagline because a "C-class article" to a previously less familiar user like me means nothing without something else to compare to without having to read or frequently refer to the documentation/talk page. I even wonder if C-class could be substituted with the definition of C-class for a more functional and minimal tagline. Using the same stub-class example above:
This is a bad quality article. You can try adding more meaningful content in this article to improve it!
I’m making these proposals thinking more users would enable this gadget in the future cus I think it’s simple and brilliant.
@Redrose64: According to the documentation, stub-class articles are "A very basic description of the topic. However, all very-bad-quality articles will fall into this category." In the same link, you can find more explanation about the particular grading. However, I'm unaware how the working group of this gadget defines "bad article" though. MGalloway (WMF) (talk) 20:00, 25 December 2015 (UTC)[reply]
My point is that I've bever seen an article described by this gadget as "bad quality". It makes no subjective judgements: it gets its information from the |class= parameters of the WikiProject banners on the associated talk page. No WikiProjects recognise |class=bad: the next one up from stub is start, then c, b etc. Please give an example of an article where the word "bad" is displayed by this gadget. --Redrose64 (talk) 23:02, 25 December 2015 (UTC)[reply]
I was thinking out loud to see if there could be any benefit in helping users understand more about what a stub-class is beyond the label "stub-class" and then displaying how a simple call-to-action could work. MGalloway (WMF) (talk) 15:48, 26 December 2015 (UTC)[reply]
@MGalloway (WMF): I suppose there's a valid point that the colour change is the most obvious change the gadget makes, and that perhaps more could be done to highlight the currently text-based information added by the gadget. I'll keep it in mind and perhaps play around with some ideas/code for a more graphical version—I need to eventually do some restructuring anyway to better separate code from messages, and that restructuring will make alternate interfaces easier. I'll keep you updated.
On the topic of stubs being "bad quality", I agree with Redrose64. "Bad" is vague and unhelpful. An article can be, for example, short, unstructured, or unreferenced, and those are concrete and, importantly, implicitly addressable problems. More broadly, it's way out of the scope of this gadget to do any definition of article quality that isn't simply stating the defined rating—ratings which are purposely vague because quality is difficult to quantify, let alone consistently across many subject areas. That's not to say I don't support better surfacing of quality ratings—I do—but that this isn't the place to do it. {{Nihiltres |talk |edits}}19:33, 27 December 2015 (UTC)[reply]
Since I haven't worked on this in a while, I might as well jot down some notes on the next things to work on with this script:
Review status of PageAssessments, in particular its implementation in {{WPBannerMeta}} (talk). Once implemented widely via the template, the script can be switched over to pull from the assessments API, which should be far more reliable than munging the talk-page source by regex (the current approach). We still need to pull the page source to check for various active/former quality reviews, but reducing reliance on wikitext munging is highly desirable, even at the cost of more API requests.
If PageAssessments is implemented widely, then the script should be rewritten to pull from its API rather than the talk page, whenever possible.
Review status of moving {{class}} to Lua/JSON. In particular, the idea's to store class data (colour, icon, labels, etc.) in a JSON file (currently Template:Class/definition.json), then render from that (using Module:Class to implement {{class}}). This has the advantage that class definition data will exist in a single code-independent file and can be updated in one step—scripts and templates will stay synchronized to the same class definitions.
For the purpose of this script, we should add values to the JSON file to support text colours used in this script: i.e. the darkened class-colour variants used in MediaWiki:Gadget-metadata.css.
For the purpose of this script, we should look into adding other values to the JSON file that are reasonably universal.
If the previous items are covered, then the script should be rewritten to pull data from the JSON file rather than hardcoded values, whenever possible.
Improve core code. In particular:
Clean up quality review detection. I'm not happy with where things are on detecting current or old quality reviews; while the code works, it's inelegant and hard to read. There's a lot of potential for improvement there. am.getGARLink is a particular offender, and am.getAssessment() literally has a TODO: Add code for old peer reviews comment.
Separate evaluation and rendering steps as much as possible. In particular, untangling the way "extras" (quality review notes, or the A/GA special case) are added to the rendering would be nice.
@Izno: Thanks for pointing me to that discussion; I've commented there. My first thought is that Wikidata descriptions are currently out of scope for this gadget; that said, I definitely want to maintain compatibility if they're implemented as a gadget, beta, or default feature. In particular, I'll keep that in mind when I get around to addressing the "separate evaluation and rendering steps" above, since the possibility of using alternative renderers would offer lots of flexibility for addressing compatibility issues. {{Nihiltres |talk |edits}}16:37, 19 January 2017 (UTC)[reply]
Has something changed with regards to the spacing between articles proper and the assessment? They've become much closer for me, and I can't see where I've done anything to cause this. — fourthords | =Λ= |03:14, 1 June 2018 (UTC)[reply]
What I'm seeing at Tuvix (and all other pages). Sure, sorry! I assumed that if it was happening to me, it was a widespread problem and most would see it, too. — fourthords | =Λ= |01:49, 2 June 2018 (UTC)[reply]
I get a gap. I can make the gap disappear by means of this CSS:
Set index article are currently given the same colour as disambiguation pages, which is confusing as these are two different things. Some WikiProjects have started using SIA-Class which has its own colour defined at {{Class/colour}}. Perhaps this gadget could follow suit? PC78 (talk) 20:07, 5 June 2016 (UTC)[reply]
I'm aware of the request but probably won't have a chance to fulfill it for a while.
The current situation is a result of the evolution of set index articles away from disambiguation pages (they used to be treated the same, hence the behaviour here). There's some support in am.checkArticle and am.renderAssessment, so anyone else who wants to work on this should double-check and/or update those definitions. am.getRating is missing an item to recognize the class from a rating value in the template, and MediaWiki:Gadget-metadata.css will need a separate colour definition (and the colour will probably need to be tweaked a bit away from the one in {{Class/colour}} to meet WCAG's recommendations for text on white). {{Nihiltres |talk |edits}}02:47, 6 June 2016 (UTC)[reply]
@Nihiltres: I know it's been a while, but is there any chance you can have another look at this? The gadget can distinguish between dab pages and SIAs in the text it displays, and per WP:SIANOTDAB I still think it should make that distinction in colour as well. If the colour used by {{class}} is a problem it could always be tweaked. PC78 (talk) 13:30, 8 August 2019 (UTC)[reply]
When I'm logged into Wikipedia, the line of text directly below the page title that normally says From Wikipedia, the free encyclopedia is replaced by an augmented version such as A C-class article from Wikipedia, the free encyclopedia or A disambiguation page from Wikipedia, the free encyclopedia. This is a feature I turned on so many years ago that I can't remember if it's standalone thing or part of some multi-featured plug-in like META:MoreMenu, and I've had no luck searching for it due to lack of terminology. Does anyone know what this is and who I would contact about fixing an error? (The link used for set index pages is going to Wikipedia:Disambiguation#Set index articles, which no longer exists.) Thanks —jameslucas▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄18:44, 27 August 2019 (UTC)[reply]
I just tried again, same issue. I dunno whether it's a systemic problem or a one-off, but whoever fixes this sort of problem probably should look into it... ♦ Lingzhi2(talk)20:39, 20 September 2019 (UTC)[reply]
b-text and dab-text colours appear to fail the accessibility requirements of MOS:COLOUR and should ideally be at least WCAG AA compliant for large text on a white background. Check: b-text, dab-text
A distinct colour should be defined for set index articles to distinguish them from dab pages, per WP:SIANOTDAB
Suggest the following remedies:
Use colour #490 for b-text (check) and #0A6 for dab-text (check)
@Anomie: Since Nihiltres hasn't been around for a bit, do you have a recommendation as to whether the gadget should import the templatestyles page (if that's even possible) or whether vice versa. I know templatestyles pages don't allow the scary parts of CSS, and I think these colors probably could/should be editable more generally than I-admins, so it should be safe to go the one way. Or perhaps neither is a good option for some reason? :) --Izno (talk) 22:41, 23 September 2019 (UTC)[reply]
I've had some ideas on ways to modernize this and solve the underlying problems—I'm thinking big, more along the lines of "make all WikiProjects register their configuration and custom descriptors in a portable JSON form rather than an arcane wikitext one"—but that's a whole other project. I've been relatively inactive because life's gotten in the way and I've been inhibited from making drop-by changes by the new need to pick up the interface-admin permission to edit this gadget myself—which in turn I'd jump for if I were active, but can't justify without activity.
I haven't used TemplateStyles yet; my impression from initial peeks has been that it's optimized enough for templates that it would be difficult or impossible to use here. In particular, this gadget styles the title and tagline, while styles added by TemplateStyles are scoped to the main parsed content. That limit, assuming it applies (perhaps it can affect the title/tagline?) is the biggest barrier for this gadget, while elsewhere TemplateStyles is great. I'm relatively apathetic to specific colour suggestions, but WCAG accessibility is important; I'll take a proper look at the code part of this eventually. Feel free to do stuff without me; I'll be back eventually, but … 2019 has not been a good year. {{Nihiltres |talk |edits}}23:42, 25 September 2019 (UTC)[reply]
A further observation: using the "Modern" skin the article title is usually displayed in white text on a dark blue background, so the gadget produces some unfortunate colour combinations such as this. I note that the gadget doesn't appear to work with the "MinervaNeue" skin at all (intentionally?); perhaps it could/should be disabled for Modern as well? PC78 (talk) 20:25, 26 September 2019 (UTC)[reply]
Not working with Minerva is not intentional, I think--Minerva just does fun stuff with not loading things. Modern OTOH would need to be a deliberate change in the script. OTOH it is neither the default nor any of the most-used skins (which I expect will be Monobook and Vector). --Izno (talk) 21:48, 26 September 2019 (UTC)[reply]
Interface-protected edit request on 7 October 2019
This gadget currently uses "wgPageName" to find out if a page is "Main Page". In other wikis, "Main Page" is not necessarily the address of the main page. For example, in mediawiki.org, mw:Mediawiki is the main page. It should use wgIsMainPage config. Replace mw.config.get("wgPageName") === "Main_Page" with mw.config.get('wgIsMainPage') == true. Thanks. Masum Reza📞04:26, 7 October 2019 (UTC)[reply]
Sure, but this is noted as a global gadget file, so we should be good stewards. I'd support making this change, although I think all we need is just mw.config.get("wgPageName") === "Main_Page" to simple mw.config.get('wgIsMainPage'). ~ Amory(u • t • c)21:31, 7 October 2019 (UTC)[reply]
I recommend mw.config.get("wgIsMainPage") === true, the identity operator with three equals, because that alone avoids truthy values that are not true. If the behaviour of wgIsMainPage.were to change, an identity operator would be less likely to break badly than the others. Still, the core change is a good idea: replace a hacky check with a purpose-built one. Xaosflux, would you please implement that, changing line 38 of the script? {{Nihiltres |talk |edits}}20:37, 9 October 2019 (UTC)[reply]
Pinging @Nihiltres for visibility. Currently the behavior for non-existent pages is showing "An unassessed article from Wikipedia, the free encyclopedia". I think that the message should simply be hidden for non-existent articles, it's unnecessary IMO. 🐶 EpicPupper(he/him | talk)05:16, 7 January 2022 (UTC)[reply]
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Good idea. This can be easily implemented with an extra condition in the checks at the start of assessmentObj.init. Would an interface editor please add the line mw.config.get("wgArticleId") === 0 || //nonexistent page after line 35 of the script (matching indentation with the preceding and succeeding lines)? One day, I should apply for the interface-editor permission. :/ {{Nihiltres |talk |edits}}17:48, 7 January 2022 (UTC)[reply]
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
@Nihiltres: For some reason, the article about the 'Black Death' is missing some information about its quality assessment in the tagline below its header. I'm currently using the latest version of Mozilla Firefox on a 64-bit Windows 10 Home laptop. -- PK2 (talk) 11:08, 11 March 2022 (UTC)[reply]
Not done (as to the immediate edit request) as this is not an edit request. Discussion of trouble can certainly continue below. — xaosfluxTalk21:37, 11 March 2022 (UTC)[reply]
@PK2: the edit request system is an important check against the protection system. If you have a complete and specific edit to propose, please do so (such as in User:PK2/sandbox.js), test it, then reactivate the edit request. If you just want to talk about this and how someone might one day improve it, this is the right place - but the page shouldn't be enqueued for patrolling administrators to process a request that isn't ready to go. — xaosfluxTalk23:41, 11 March 2022 (UTC)[reply]
Working… the script currently assumes that a GAR must have taken place for a delisted good article, and that assumption leads to an error on Black Death which doesn't have a GAR listed while being marked as a delisted good article. This suggests that I need to fix some fragility in the detection of former statuses, and I'll look into that. On the other hand, it begs the question why no GAR is listed; I found a GAR listed at revision 241065973 that isn't present in the current article history; re-adding that might solve the proximate issue until I write a fix for the underlying bug. {{Nihiltres |talk |edits}}20:53, 12 March 2022 (UTC)[reply]
I really liked the idea of this gadget, but the whole colourful font thing didn't agree with me. So I didn't use it. Today I found a way for it to work for me:
If an article belongs to 2 or more projects and each of them gives a different rating, how does it determine which one to display? E.G Wiki Project X has given Article Bla an a-class rating, but Wiki Project Y has rated it c-class? KaraLG84 (talk) 13:19, 2 June 2022 (UTC)[reply]
Is there any update on the title colour of set-index articles? (as originally raised at MediaWiki talk:Gadget-metadata.js/Archive 1, set-index articles are not disambiguation articles, so shouldn't be marked in the same colour). If it isn't possible or desirable to have a dedicated colour for set-index articles, I would suggest that List purple would be much better than Disambig green. --Jameboy (talk) 15:15, 16 January 2023 (UTC)[reply]
This gadget doesn't work with the page description gadget. On line 674, a check should be added in the event a user is using the page description gadget to combine the output of it and this gadget:
Look good to me. I encountered an issue where "undefined" was added before the "A blank-class article", but I refreshed and it was gone. Haven't had it since. elijahpepe@wikipedia (he/him)23:47, 19 January 2023 (UTC)[reply]
I've gone and undone this, cc ElijahPepe. The issue is that jquery returns an object, so even when nonexistent it isn't falsey, so the whole thing executes regardless of the other gadget's existence. The proper way to do it would be something like first().html() or [0].innerText, but it's a school night so I won't act further atm. ~ Amory(u • t • c)03:39, 20 January 2023 (UTC)[reply]
I should add, too, that I'm not wild about a gadget inserting something external into .html(). ~ Amory(u • t • c)03:46, 20 January 2023 (UTC)[reply]
Not sure if this is the right place to mention it, but it's linked at the "Display an assessment of an article's quality in its page header" part of preferences; all class definitions now show up with "undefined" in front of it, such as "undefinedA C-class article from Wikipedia, the free encyclopedia". I am running Vector 2010, but the issue also appears in 2022. Testing reveals that user scripts appear to be unrelated. IazygesConsermonorOpus meum01:54, 20 January 2023 (UTC)[reply]
Interface-protected edit request on 20 January 2023
Done Thanks. I'll comment above to keep the discussion more connected, but appreciate the ping via ER. ~ Amory(u • t • c)03:31, 20 January 2023 (UTC)[reply]
Done. The script now detects disambiguation pages, lists, and redirect pages. Pyrospirit (talk · contribs) 17:10, 21 March 2008 (UTC)
Thank you working now --Redrose64 (talk) 20:00, 5 September 2015 (UTC)
Done — Martin (MSGJ · talk) 06:42, 16 April 2018 (UTC)
Moved from WP:VPT
On hold Ping to currently listed maintainer, Nihiltres for review. Nihiltres, please ping or reactivate the ER following review. As far as what some other project may do Masumrezarock100 that isn't really our problem. — xaosflux Talk 11:02, 7 October 2019 (UTC)
Not done (as to the immediate edit request) as this is not an edit request. Discussion of trouble can certainly continue below. — xaosflux Talk 21:37, 11 March 2022 (UTC)
Working… the script currently assumes that a GAR must have taken place for a delisted good article, and that assumption leads to an error on Black Death which doesn't have a GAR listed while being marked as a delisted good article. This suggests that I need to fix some fragility in the detection of former statuses, and I'll look into that. On the other hand, it begs the question why no GAR is listed; I found a GAR listed at revision 241065973 that isn't present in the current article history; re-adding that might solve the proximate issue until I write a fix for the underlying bug. {{Nihiltres |talk |edits}} 20:53, 12 March 2022 (UTC)
Undone - before resuggesting this, fork both scripts to personal scripts and try them there next. — xaosflux Talk 01:27, 20 January 2023 (UTC)
