On a technical level, I am also doubtful that any NPOV assessment could be successful without at the very least grounding the suggestions to reliable sources through some form of retrieval-augmented generation.

Being discussed on the English Wikipedia's village pump. Consensus is pretty clear that the current version is far from desirable, and shouldn't be rolled out as a usable product in the immediate future, although from my understanding this is not what is currently being planned.

@DLynch it's not browser scaling (my browser is at regular 100% scale), just screen scaling (physical pixels per virtual pixel).

And that's how I got so laser-focused on the student newspaper that I missed the broader academia one!

Thanks a lot for the feedback @SuperHamster ! For the government icon, I toyed with a dome version, alongside a flag atop either, but the resolution of the icon made it nigh-unreadable.

Now, the awaited icon proposals. They all have a codex-base version as they can and should stand as generic icons. Cite Unseen maintainers are free to pick add Codex-friendly colors that will carry relevant semantic meaning, with this reference for color tokens.

@DTorsani-WMF (sorry for the bother again), which font is used for the question mark in icons? I'm trying to make one that's slightly smaller to have enough clearance around the outlines of the speech bubble, but want to keep it consistent!

Struggling to attach the files to the comment, sorry!

I'll note that we currently have 24 Cite Unseen icons, some of which have acceptable Codex substitutes. I am relying on this demo as the most up-to-date icon set available.

@Soda, I don't think so, more reasonable ways of distinguishing them would be generative vs non-generative or automated ("bot"/"agent") vs human assistance. Also the level of autonomy, an OpenClaw agent and ClueBot NG are both technically "AI bots" but with very different expectations and capabilities (although that might fall under the "generative" aspect). Lots of constructive AI uses also have LLMs under the hood, and whether a small thing like BERT or a larger model is being used is less of a relevant consideration for the end user than what it does.

Noting that the Codex icons are being redesigned in T399175 / T427868, and I'm waiting for a stable version of the Robot icon to go back to this. I really like @itsmoon's proposal, and simplifying it for small sizes could be very doable.

Well I'm definitely interested now! Thinking of the more recent additions to CiteUnseen as a concrete example, I know that there have been multiple proposals for the "robot" icon and it isn't really clear which one is going to be used in T427868, so that's a baseline to consider. For example, the latest demo uses a top-heavy version not too dissimilar to the "umbrella" version previously replaced by the head-first one in T399175.

Should another task be created for this specific behavior?

Maybe the "Watch" text could be hidden by default but show up below the star when hovering on it? It might be a good compromise between the harder-to-reach hover text (which only appears after hovering on it for some time, and is less conspicuous) and permanently displayed text that takes a lot of real estate on screens.

Would there be a way to highlight (perhaps in a different way) words that were partially matched?

In T427868#12056314, @Novem_Linguae wrote:

Thanks for being flexible to feedback. I love how you're taking people's feedback into account and trying to release compromise versions of icons. I think this is great for community relations. Looking forward to further refinements.

Also, maybe I'm being too finnicky with details, but I realized userPages still has the "landscape" aspect ratio, would it make sense to have it fit with the other page icons or would it make the user silhouette too hard to decipher?

@DTorsani-WMF, thanks for the latest demo! Please tell me if any other task is created for this!

Bringing this up again, but the bold icon for Arabic (ayn) isn't in the same font as the other Arabic script icons (Persian and Urdu bold, and Arabic, Persian and Urdu italic), which are all constant width.

Yet another thing I'm noticing (sorry!), the userAvatarOutline has the head touching the body (as the outline makes them thicker), is that intentional? I notice it isn't the case in userGroup which uses both side-by-side.

Thanks a lot! Had completely forgotten that the old calendar was slightly more square than other versions!

@DTorsani-WMF, thanks a lot for all of these updates! Small detail, is there a reason for why articlesSearch/diffs have a different aspect ratio from articles/specialPages?

Really liking the perspective! I believe it can very much be adapted to the outline-first design language being used here.

This should have all of my icons in SVG format if anyone needs them, I think I'll stop there!

Adding a few more, including two proposed designs for the keyboard icon, with and without an outline. First one is admittedly a bit busy, although it can be seen as more consistent with the rest of the icons. Funnily enough, the T399175 keyboard icon doesn't actually fit the Codex design guidelines (being only 18 pixels wide despite being rectangular), so I had to adapt it and tried to simplify the design a bit by removing odd-shaped keys for readability.

Newspaper and Die coming in:

In T427868#12038550, @Hakimi97 wrote:

Or maybe just draw an outline version (https://commons.wikimedia.org/wiki/File:Setting_icon.png) like the following one:

Sadly, this one wouldn't work as the outlines try to be 2px thick (to be readable enough at 20px scale), which would prevent us from fitting that much detail. Something like a cogwheel is already hollow enough that the extra weight from it being filled isn't much of an issue (especially as readers will be used to seeing it in that state, and might be more confused by a hollow one). Best, in my opinion, to return to the previous version.

Using gaps to convey perspective for the tray while keeping the outline. Two versions, either square like the current one, or slightly more rectangular to account for the perspective. Not sure which one fits better.

@aliu: how do these look?

In T427868#12036052, @Soda wrote:

Can we have the ArticlesSearch and ArticleSearch icons have some separation between the magnifier stem and the article icon itself? Currently, it looks like a box with an attached crank/lever.

And here are my takes on them!

Also realizing I forgot PageSettings and SpecialPages in the "page icon series". Admittedly, the shift to an asterisk for SpecialPages makes it harder to distinguish the two (the asterisk being a cogwheel stand-in for icons such as UserRights), so that's to take into consideration.

Thanks a lot! Here's my SVG file if needed:

Tried to adapt a few of the old icons to the new outline style. For the Article, Articles, ArticleDisambiguation and ArticleRedirect ones, I made both a version that allows a bit more freedom to match the old style, and a version that follows the new style's guidelines more strictly.

In T399175#12035222, @Nemoralis wrote:

ArticleSearch (and ArticlesSearch) is very bad. Why is the magnifying glass so small?

The brutalist style of many of the new icons (mentioned as an intentional design choice in T399175#12035047) gives an impression of being strict and firm to the point of being off-putting. This goes against the efforts by both the community and the WMF to make Wikipedia a more welcoming and comfortable space for newer editors and readers. Here, we lose the human in Interfaces for Human Knowledge.

I was curious what the old set's speech bubble series would look like with the new set's 2px outlines. Here's my take on it!

Looking back since my last comments, I genuinely expected a lot more refinement for the final version, but it looks like most of it kept this very blunt, constant-thickness style. I can see the advantages for readability at small scales, but not every icon needs to be a pure outline, and not everything needs to keep this same thickness, which leads to many of the awkwardness pointed above.

Thanks a lot! To be honest, at the same time, I'm afraid that newcomers might get discouraged by seeing their edits be tagged for something they have already fixed, which is why incorporating this into edit filter logic (which could allow us to decide when to log vs tag vs do more) could be even more helpful.

Nevermind, I had just mixed up section and section-h. Looks like it works now, sorry for the bother!

@Pppery Sorry for missing your comment! Doing this still returns empty text for some reason, see here (using this code).

A bit late, but I notice we don't have a warning icon (e.g. hand/exclamation point in triangle or octagon). Is it too late to implement one?

Thanks a lot! Adding that this would allow us to compare LLM Paste Check with other AI detection tools (I've recently been in talks with Pangram about providing us support for T383590, which I'll hopefully be able to get back at after so long!) to see how strong correlations are between edits triggering Paste Check and edits flagged as LLM-generated by other means.

This might be because they're not properly a nested hierarchy, with "Fossil taxon" being a subclass of "Taxon" (Q16521) and "Animal" being an instance of "Taxon". This kind of makes sense, as fossil taxa can also include plants, fungi, god-knows-what, etc. However, given that what we can say about a fossil organism is very different from what we can say about an extant one, it makes sense to have different outlines structured that way (I consulted with folks from WikiProject Palaeontology to make sure).

Noting an English Wikipedia VPT discussion that might be related to this. Does being logged in through SUL count for the purpose of this timer, or are users expected to manually login separately on each wiki?

Is it possible to increase the timeout to something like an hour on test instances such as test.wikipedia.org or meta.wikimedia.beta.wmflabs.org? Elevated security is critical on production wikis, but on a testing ground where you may be expected to continuously work on the interface files and debug them before deployment, it can prove to be a much bigger hurdle compared to the (less critical) security benefits.

For added context, I encountered the issue earlier today while testing SecurePoll there. Not sure if granting should be crat-specific or available to all admins, I'm open to both as I can't see much potential for disruption from creating polls.

Checking in, I really like these! I especially like the ability to intentionally balance the weight of the icons. The only worry I'm having is regarding the more detailed icons, such as the "references" one, which in the current style might be a bit hard to maintain as separate filled and outlined icons. All in all, really great work, keep it up!

Great to know! Is there an open task for that?

Looks great! A few hours late, but I wonder if it could be possible to integrate regular expressions to the rules? For example, we currently have:

The current icon for regular bots is the robot face that is integrated here as a design component. The worry with "LLM" is that it isn't translingual, and we would need a translated version of the acronym in every language to avoid Anglophone bias, while icon combinations such as "robot" + "speaker" or "robot" + "text bubble" convey this more universally.

Thanks a lot! Making sure I understand correctly, does that mean some icons will, in the future, have both an outline version and a filled version depending on the user's needs?

Agree that multiple to-do lists could be helpful, especially if we can set each to public vs private, or just want to sort them by theme. Having reminders might be less of a necessity (although I wouldn't be opposed to it), but something that could be great would be the ability to set a priority for each list element. I also like the aforementioned idea of making it checkbox-based for intuitiveness!

More general comment: the "After" overrelies on thin outlines and might be worse for accessibility (and from a design standpoint) comparing to the bolder, filled shapes we currently have. I'd be down for a redesign of some of the current shapes (such as the fixes I outlined above) for more consistency and readability, but a change of this magnitude is not necessary or helpful in my opinion.

Two other (small) issues that could be fixed:

• SpeechBubbleAdd has inconsistent proportions compared to other speech bubbles (namely, it doesn't fill the whole icon space). That inconsistency is pretty visible when used side-by-side or when one switches to the other, and should be an easy fix.
• While most letters are not in the above list, Bold Arab Ain is currently in a different style compared to other bold Arab characters, being more calligraphic and with tapered instead of squared ends.

A few icons I've been having in mind:

Thanks for the explanation, that does make sense!

In T395166#10900382, @DLynch wrote:

If we wanted to, we could make some sort of additional on-wiki logging system akin to the AbuseFilter logs. We should talk about that as a generic system for all checks, though.

In T395712#10872592, @Pppery wrote:

I would think the discussion should have been formally closed before filing here.

And, in any event, the next time a config change could be deployed is June 2, since this sort of change isn't done on Fridays or Weekends.

I used to have this bug until yesterday. Now, the references display with the correct number, but in black instead of blue. Might this be related to the latest fixes?

From what I understand, the search engine searches the "UBX/GALLERY" string in Wikipedia: namespace pages, but the title string itself (which is used to generate the redlink) doesn't include Wikipedia. A bugfix might involve adding the namespace in which the search is made to the redlink. However we should bear in mind that it is possible to search in several namespaces at the same time, and how to generalize our bugfix to this case is not obvious.

Something to have in mind: some articles can be created from splitting other larger articles, and, more generally, content about a given subject can be available on a broader Wikipedia article before the specific article is written. Since this content can also show up in training data, should this be taken into consideration? To use the example of Maria Trubnikova, the first mention of her in the en:Feminism in Russia page dates back from June 2012, before either the English or Russian Wikipedias had an article on her.

Looking at the hits of Special:AbuseFilter/1346, it looks like only ChatGPT-generated links are getting caught here. @DLynch already looked into ChatGPT's behavior earlier today, finding that it would only generate UTM links through its web-search tool, but not through a regular "ask to write an article" query.

Thanks for adding the task, I'd be happy to go for it!

Thanks a lot for putting me in the loop! Enabling it for drafts does make a lot of sense.

Personally interested in this, especially with respect to WikiProject AI Cleanup. I was in talks with GPTZero for a similar project adapted to Wikipedia (beyond just using their default model), although that didn't work out in the end. Would be interesting if we could work on our own, open-source version.